On May 6, 2008, at 2:37 AM, Donal K. Fellows wrote:
>  Ah, the "public vs private" state issue. Other languages get  
>  themselves
>  in a proper tangle over this, so I know we have to treat carefully.
> 
>  As a matter of principle, I don't want to have state that the object
>  can't inspect on itself; I think that that would be un-Tclish.

This I agree with; and Snit doesn't implement "private" state as such.
(Of course, you don't get inheritance, either, so in a sense all
instance variables are private by default; but that's happenstance.)

>  That in
>  turn means that I'm inclined to say that if two classes use the same
>  variable name, they get the same variable (which greatly reduces the
>  complexity of the implementation).

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?

Itcl has a solution that allows public variables defined by a class
and its ancestors to be shared without name collisions; and Arnulf
has already written a variable resolver for TclOO that implements it.
I suggest we adopt it for TclOO in general.

Will

> 

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills



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