On 22 Sep., 02:14, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Kay Schluehr a écrit : > (snip) > > > > > I checked out Io once and I disliked it. I expected Io's prototype OO > > being just a more flexible variant of class based OO but Io couples a > > prototype very closely to its offspring. When A produces B and A.f is > > modified after production of B also B.f is modified. A controls the > > state of B during the whole lifetime of B. I think parents shall not > > do this, not in real life and also not in programming language > > semantics. > > I may totally miss the point, but how is this different from: > > class A(object): > def dothis(self): > print "A.dothis(%s)" % self > > class B(A): > pass > > b = B() > > b.dothis() > > def dothat(self): > print "function dothat(%s)" % self > > A.dothis = dothat > b.dothis()
It's not a big deal because you do not use a class to propagate mutable state unless you are using a class attribute intentionally ( i guess you do not overuse it just to avoid object encapsulation and make everything global ). When using a prototype as in Io you need to protect the state of the child object yourself. You can do this by overwriting the objects slots but then you end up writing your own object constructors and the templates accordingly, also named "classes" by some. Not having dedicated object constructors, member variable initializations and the presumed class definition boilerplate comes at the price of introducing them on your own. Prototypes have a purpose of course when you want to transfer state to a newly created object. Using a prototyping mechanism as a generic form of a copy constructor is the right kind to thinking about them IMO. ------------ I have got the impression that the discussion has drifted away from what Paul Rubin suggested, namely abandone the expression/statement distinction. Instead we are discussing the advantages and disadvantages of object models now. Can we stop here, please?
-- http://mail.python.org/mailman/listinfo/python-list
