@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:
function
only collect set words (+ some exception) and [the-path key value] are words.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).@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-local
would'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 test
word 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 SELF
seems 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]
]]]
? db
extend
on objects being reserved for future use (or not yet implemented) it seems having self
in 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?
self
would 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.