@9214
Well, I have tried the SET words-block values-block solution with no success.
test: function
[
action
passed-args-block [block!]
]
[
args-def: [
add
[
the-path [string!]
key [word!]
value [any-type!]
]
del
[
the-path [string!]
key [string!]
]
]
function-words: extract select args-def action 2
set function-words passed-args-block
]
test 'add ["a-path" "a-key" "a-value"]
probe the-path
probe key
probe value"a-path"
"a-key"
"a-value"
>>>Words set into function seems to exists after function exit:
that's because
function only collect set words (+ some exception) and [the-path key value] are words.ps. if you want post simple code snippets that people would run in the repl then avoid unnecessary new lines (e.g. after
function, after first ]. Your code might compile but it won't run correctly in the repl.
-c option to compile as you work. It’s much faster than -r (release mode).You should only need release mode when your ready to distribute the binary. Release mode might take awhile, but it’s a one time thing
@nedzadarek
ps. if you want post simple code snippets that people would run in the repl then avoid unnecessary new lines (e.g. after
function, after first]. Your code might compile but it won't run correctly in the repl.
Those "unnecessary" new lines avoid me being confused. Words are isolated and clear and there are not so many symbols that my mind have to decode.
Bind 'word self with no success. Now I am wondering if SET could have a /current context refinement, to express the context that RED automatically adds to words. Another way would be to have a SET/BIND where you can express one in some way as argument of SET.
function is auto-localising only set-words and using set with a lit-word explicitly bypasses that mechanism, adding should-be-local to the global context. Even if should-be-localwould've been declared in the function's context, bind 'should-be-local 'test would rebind it to the context thetest word is bound to. With the context of the testword being the global context rather than the function's context (as you seem to assume).
@gurzgri Having a lot of functions operating on the the same kind of dataset, usually you have identical or simular arguments block.
I am experimenting a "simpler" approach which let me express in a way like:
db 'add-table [arguments]
db 'delete-table [arguments]
db 'add-row [arguments]This because, as I have written: [arguments] is the same for 2 or more functions. Selecting them from a table let me:
1) Change the argument interface once and for all
2) Save a lot of typing
About this point I have still not show the block of code which maps an arguments to multiple methods.
mapping: [
arguments-block-name-a [method1 method2 method3]
arguments-block-name-b [method4 method5]
]or another one (have to choose)
mapping: [
method1 arguments-block-name-a
method2 arguments-block-name-a
method3 arguments-block-name-a
method4 arguments-block-name-b
method5 arguments-block-name-b
](In my mind I see also function composing built from tables of code but If I won't solve this problem I can't further experiment)
@gurzgri
Even if should-be-localwould've been declared in the function's context, bind 'should-be-local 'test would rebind it to the context thetest word is bound to. With the context of the testword being the global context rather than the function's context (as you seem to assume).
If I had a way to express bind this word to test function inner context and not to the outher (global) one. But SELFseems it doesn't exists and this is now blocking.
spec: [add-table delete-table [db table] add-row [db table row]] ;-- function specs
code: [add-table [a: 1] delete-table [b: 2] add-row [c: 3]] ;-- function bodies
db: object collect [foreach name spec [all [
word? name
keep reduce [to set-word! name 'function first find find spec name block! select code name]
]]]
? dbextend on objects being reserved for future use (or not yet implemented) it seems having selfin functions wouldn't gain you anything for now (I may be missing something here). Why not just have a function local word set to a map! and extend that if you think that's the way to go?
selfwould be available in functions to access a function's context, self would no longer be available to access the context of a function's outer (object) context. Which is an ubiquitous pattern with OOP, and no doubt used in large codebases.
