Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Q: Functions and the visibility of words

From: agem:crosswinds at: 27-Apr-2001 4:24

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 26.04.01, 06:02:32, schrieb [Sanghabum--aol--com] zum Thema [REBOL] Re: Q: Functions and the visibility of words:
> [Al--Bri--xtra--co--nz]: > > When a word is definied inside a function it is visible also outside
> > function (after the invication of the function) unless explicitly
> > 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
> > unwanted side-effects, but what are the advantages this scheme
> The disadvantages are so major, that something needs to be done. It
> 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
> 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
> ways: > 1. My externally callable functions are embedded in objects. So any
> 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
> can use. It saves me having to think up names too...though I will
> name a variable if its usage is not obvious. > Carl S. is obviously aware of this problem, and has recently suggested
> solution similar to my first suggestion.... > Carl Sassenrath: > >On modules, here's a handy way to accomplish a lot of what is
> >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
> ?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