Hi Ladislav
> I feel, that Joel tried to warn us, that the "Poor man's module" is not as
> reliable as some may need it to be:
>
> Rebol []
>
> make object! [
> protected1: 1
> protected2: 2
> if true [
> unprotected1: 3
> ]
> ]
>
> and he is right, because 'protected1 and 'protected2 will not destroy
their
> global context couterparts, but 'unprotected1 can!
>
Your example illustrates that:
1) code in an object definition is executed
2) within an object definition we have access to all parent contexts up to
and including the global context.
It is consistent with my own (perhaps poorly worded) description:
[
There are stages in object creation, and in one of the early stages the
object spec block is scanned for all first-level set-words. A context for
the object is created with these words bound to it.
After this stage, the code in the object spec is executed, in exactly the
same way as a block of code in the global context. The only difference is
that those words which occurred in the spec-block as set-words are bound to
the objects context. Any code can appear and will be executed.
]
UNPROTECTED1 is not a first-level set-word, so it is not in the objects
context and thus no protection of global namespace is implied.
The IF statement is just a piece of code which is executed when the object
is created, it has access to the global context and can define or redefine
any global (or object variable).
It seems to me that we have pretty good control over our contexts. If we
want UNPROTECTED1 to not affect the global context, we just add
UNPROTECTED1: none in our object, making it a first-level word.
REBOL currently is based on a context hierarchy, where nested funcs and objs
have access to words in all the higher levels of the hierarchy, as well as
those in their own context.
Modules, as Carl has described them will allow control of both imported and
exported variables.
-Larry
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
