Am Mittwoch, 7. Mai 2008 10:12:47 schrieb Donal K. Fellows:
>  Will Duquette wrote:
>  > This I think would be a big mistake, as it makes it to easy for changes
>  > to superclass A (possibly written by developer B and included in package
>  > C) to break subclass D, written by application developer E.  Trevor
>  > suggests we protect against this by using a naming convention for
>  > instance variables, to which I can only say "Ugh!"  Isn't that what
>  > namespaces are for?
> 
>  A naming convention that is concealed from scripts (unless they
>  deliberately poke under the covers, of course) is probably the way to do
>  it. I warn that I've not thought about this too hard.
> 
>  Right now, there seems to be a few issues that are intermingled; I'm
>  going to try to separate them from each other.
> 
>    1. Should there better support for state variables? (I'm getting a
>       consensus "yes" here.)
> 
>    2. Should non-standard variables be used, i.e. should they not be just
>       in some namespace, but rather be more magical constructs hanging
>       directly off the class or object? (My intuition is "no".)
> 
>    3. Should variables be restricted by inheritance? (Looks like a
>       qualified "yes").
> 
>    4. Should variables be available "by default" in methods? (Probably
>       "yes". Details need examination of use-cases.)
> 
>    5. Should #257 be delayed while this is worked out?
> 
>  Right now, question 5 is the big one. :-) Myself, I think there's no
>  need for delay, since the TIP says very little about variables. I'd be
>  perfectly happy to work on a separate specification of how variables
>  should be done (it's not like there's actually a lot of code needed, and
>  it is nowhere near as evil to contemplate as the dispatch cache system).
> 
>  Donal.

I think question 5 should not delay the TIP! 

And I agree that the handling of variables can be done with another TIP.

Arnulf


> 
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
> one _______________________________________________
>  Tcl-Core mailing list
>  Tcl-Core@[...].net
>  https://lists.sourceforge.net/lists/listinfo/tcl-core



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core