> Hi Christophe,
> 
> I think your description is incomplete. By privatization do you mean 
> 
> 1. that functions within the object should/should not have access to the
> privatized function? 
> 
> 2. If 1, then that limits how hidden the hidden function is. Recall that
> REBOL functions are editable during runtime. This means that I can use
> any function that accesses the hidden function as an entry point into
> the hidden function. I.e.
> 
> o: make object! [
>  hidden-func: does []
>  exposed-func: does [hidden-func]
> ]
> 
> exposed-hidden-func: get first second get in o 'exposed-func
        [ok, I can also use this]  

> 3. Should the function have access to other functions and words defined
> in the context of the object?
        [yes, it should]  

> 4. Should the object be serializable including hidden functions?
        [I do not understand 'serializable' ?]  

> 5. Should descendants have access to hidden functions?
        [yes they should. Although it should be interressant to me to have a
mean to control this: some sort of 'protected function' which is known to
the ancestor, but not to the child objects...]  

> Without clarifying these questions I can see a long thread of rejected
> proposals.
        [the 'private function' I meant is the opposite of a 'public
function'.
        That is, a private function is a function only known and accessible
from within the context of the object. A public one is part of the public
interface of the object and is therefore accessible from outside the object,
by another object from exemple]  

> Take Care,
> 
> Elan
> 
> > 
> > --
> > 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.
-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.

Reply via email to