Twylite wrote:
>  Say I have a class B that inherits from class A, and B uses a variable 
>  "buffer".  Sometime later class A is upgraded by its maintainer (not me) 
>  who introduces a new private variable called "buffer".  Is there a 
>  distinction between these variables, or is there just one variable 
>  "buffer" belonging to the object, and our classes are going to end up 
>  arguing over it?  I believe the current TclOO implementation gives the 
>  latter situation?

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. 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). I know that this can lead to problems
such as you describe, but this is a real possibility anyway, as some
classes will want to have "public" variables anyway, and if a maintainer
adds one of those, the subclasses will have to just deal with it; since
a third-party subclass of B could be relying on A's state variable being
the one to show, B's buffer could be plain hosed. (This is part of the
tangle that I alluded to above, and can lead to really annoying gnostic
errors in Java for example.) I suppose it would be possible to mitigate
these problems by not exposing class-defined variables to subclasses or
instances at all (e.g. using variable name rewriting rules) but that's
getting grotty, and fails the "is it how we want Tcl to be?" test IMO.

In short, the cheap solution is probably right too. :-)

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