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.

-------------------------------------------------------------------------
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