>>>>>>>>>>>>>>>>>> Urspr�ngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 26.04.01, 06:02:32, schrieb [EMAIL PROTECTED] zum Thema [REBOL] Re:
Q: Functions and the visibility of words:
> [EMAIL PROTECTED]:
> > When a word is definied inside a function it is visible also outside
the
> > function (after the invication of the function) unless explicitly
specified
> > local. This seems to be a different approach to most of the other
> > programming languages (at least that I know :).
> >
> > > The disadvantages are obvious, it is easy for the programmer to
introduce
> > unwanted side-effects, but what are the advantages this scheme
introduces?
> The disadvantages are so major, that something needs to be done. It
don't
> matter so much if I'm the only coder, but what happens if I start
using code
> contributed by others? Unless I can *guarantee* they have not created
global
> variables, then my use of their code could subvert one of my globals,
or vice
> versa.
> I've been trying to avoid the accidental creation of clashing names in
two
> ways:
> 1. My externally callable functions are embedded in objects. So any
globals
> they create (accidentally or otherwise) have two-part names:
> myobject/myvarname. Not perfect, but better than accidentally creating
> myvarname.
> 2. I've gotten into the habit of starting all functions like this:
> myfunc: func [.... /local aa bb cc dd]
> Thus giving me a "pool" of fairly anonymous local variables that the
function
> can use. It saves me having to think up names too...though I will
explicitly
> name a variable if its usage is not obvious.
> Carl S. is obviously aware of this problem, and has recently suggested
a
> solution similar to my first suggestion....
> Carl Sassenrath:
> >On modules, here's a handy way to accomplish a lot of what is
desired.
> >This is how we modularize our code within REBOL products:
> >mod-mycode: context [
> > var1: 1234
> > var2: var3: var4: none
> > func1: does ....
> > func2: does ....
> > set 'external-func1 does ...
> > set 'external-func2 does ...
> >]
> >
> >So, using a one-of-a-kind object allows you to make your code
modular...
> ?at least to the degree that you don't have to worry about stepping on
> >globals, etc.
> >
> >REBOL modules will be added for 3.0. But first, we must sell some
> >products to pay the rent and eat from time to time. ;)
first, automatics have a little problem:
a: does[parse something [copy b (c: copy next b)]]
and similar.
The [copy a] in parse works actually like [a:], the [copy next b] not.
So either you decide to trigger 'copy as making local (because of
parse)
or to ignore it, because of [copy next b] (would trigger 'next to be
local..)
can only be decided at runtime. And then, not on every function call
please..
so carl, where are these modules? ;-)
second, my workaround-commodities:
i turn it around.
If �they� don't use locals, well i do.
i look what i need after some [do %somethign] and put this in _my_
context.
Everything else can be global or thrown away or that.
its very unlikely to get clashes if i put my stuff in some
'ctx-my-stuff.
Depending on debugging-style i can 'protect it to be sure.
Also i run _all_ scripts again instead of relying on something
pre-loaded,
since it can be destroyed by some other script,
or simply not be able to run twice.
So after doing a script i know it has settup everything to use it
fresh,
and my stuff is safe in the context.
This loads some srcipts a lot more often than nessesary
(each of my subscripts calls at least %debug.r),
but that seems not to need more runtime.
And is safer.
(nothing seems to need time in rebol, compared to startup-time.
except of self-programmed big loops.. :)
for me the global space is everyones scratchpad.
Volker
> --Colin.
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
