On traits composition
Locked
123
123
Re: Re: How about... something completely different? (Re: Re: On traits composition)
 
|
Hey, while we're at it: what if we threw out classes and used
prototypes instead? </snark> P.S. (sorry!) :P On Tuesday, December 8, 2009, K. K. Subramaniam <[hidden email]> wrote: > On Wednesday 09 December 2009 07:38:31 am Josh Gargus wrote: >> n Dec 8, 2009, at 4:08 PM, Andreas Raab wrote: >> > Hi Göran - >> > >> > Unbelievable. You basically just described the very idea that started >> > this whole traits thing. When Nathanael worked with us at Disney, the >> > traits direction came out of discussions where we wanted him to think >> > precisely along the lines you're describing. My original thoughts on this >> > matter was that I wanted to have something more like (biological) cells - >> > entities that are made up of smaller things (objects), that have an >> > inside and an outside (made up of other objects instead of abstractions >> > like the interface/implementation distinction), that forward signals >> > (messages) to the appropriate receptors etc. >> >> Ted and Ian at VPRI recently wrote short notes on this topic: >> http://www.vpri.org/pdf/m2009014_membrane.pdf (Ted) > How is this different from a "Bus" (e.g. D-Bus) - an active container where > objects can connect to a receptor, seek other objects, get an object > instantiated (if necessary), communicate with them and disconnect. Objects > retain their autonomy and gain the ability to collaborate with peer objects > across an active container. > > Subbu > > -- Ron |
Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Göran Krampe
2009/12/9 Göran Krampe <[hidden email]>:
> Hi all! > > Andreas Raab wrote: >> >> BTW, I really don't think there is much difference between mixins and >> traits; all forms of MI are fairly equivalent. >> >> Cheers, >> - Andreas > > As most of us I was also very positive when Traits first came to the scene. > Now, I am a lot more jaded and think "well, sure, but are they worth it?". > > Given Andreas' statement above - wouldn't it be *much* cooler to evolve > Smalltalk along the axis of composition instead of the axis of inheritance? > > I have always thought that having better mechanisms for delegation would be > awesome, and would in most ways be much more powerful than inheritance (in > whichever form). > > For example, what if one could declare that for class Foo (having ivars x, > y, z) any message that would result in a DNU would instead be "delegated" to > ivar x (and then y if no lookup is found in x either). > > This would be equivalent to tons of messages in Foo like: > > Foo>>name > ^(x respondsTo: #name) ifTrue: [x name] ifFalse: [y name] > > (well, kinda, you get the picture - but also, taking care of x/y returning > "self" in which case we probably should return the "Foo self" instead etc) > Hmm, how is it different to inheritance? I mean, you can achieve similar effect by making an instance of Foo class superclass to be x, and x superclass to be y. > In many ways the mechanism I am describing is "built into" languages like > self and Slate (I think). > > IMHO the above is very useful and would allow fine grained composition > similar to Traits but in a dynamic more object centric fashion. > > regards, Göran > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Andreas.Raab
On 8-Dec-09, at 12:27 PM, Andreas Raab wrote:
Well, going back to the original Traits paper[1]: Section 3.1, which introduces Traits, says, "Traits bear a superficial resemblance to mixins, with several important differences. Several traits can be applied to a class in a single operation, whereas mixins must be applied one at a time. Trait composition is unordered, thus avoiding problems due to linearization of mixins." And later in the same section (note the third rule): Trait composition respects the following three rules: • Methods defined in the class take precedence over trait methods. This allows the glue methods defined • Flattening property. A non-overridden method in a trait has the same semantics as if it were implemented • Composition order is irrelevant. All the traits have the same precedence, and hence conflicting trait See also section 3.1.3, where Definition 8, proposition 1 includes a proof that Trait composition is both associative and commutative. I don't see any references to XOR operations, so that must have come from some other discussion of Traits. (I'm pretty sure I didn't make that up from thin air!) Instead the paper talks about explicit conflicts which have to be resolved, consistent with the #traitConflict methods the Squeak implementation creates. So I guess "does not show up in the composition" is wrong. It would be better to say "creates a conflict that must be explicitly resolved." But still, I think it's fair to say that this is one of the defining features of Traits, in contrast with Mixins, which do follow a "last one wins" method of resolving conflicts. Colin |
Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Göran Krampe
On 8-Dec-09, at 2:24 PM, Göran Krampe wrote: > I have always thought that having better mechanisms for delegation > would be awesome, and would in most ways be much more powerful than > inheritance (in whichever form). > > For example, what if one could declare that for class Foo (having > ivars x, y, z) any message that would result in a DNU would instead > be "delegated" to ivar x (and then y if no lookup is found in x > either). Lately, I've been thinking that it would be useful to have a delegation operator. For the sake argument, let's use backtick, since it's not used in Smalltalk. The operator could be applied to the receiver in a message send, like this: `anObject doSomething This would cause the #doSomething message to behave like a super send. The selector #doSomething would be dispatched with respect to anObject, but the method would be executed with the sender as the receiver. I'm not sure what patterns of composition would emerge in a langauge that supported it, but it seems like the simplest way to allow one object to delegate to another object without inheriting from it. Colin |
Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In this respect, interesting, how to avoid a pitfal of circular delegation.
x -> y -> x if i send a message to x, and got DNU, it is automatically delegated to y, but in same way as x could delegate to y, y could delegate to another object , and finally some of them in delegation chain could delegate back to x. Circle is closed, and VM will loop forever trying to lookup a method not implemented in any of objects in such delegation chain. 2009/12/9 Colin Putney <[hidden email]>: > > On 8-Dec-09, at 2:24 PM, Göran Krampe wrote: > >> I have always thought that having better mechanisms for delegation would >> be awesome, and would in most ways be much more powerful than inheritance >> (in whichever form). >> >> For example, what if one could declare that for class Foo (having ivars x, >> y, z) any message that would result in a DNU would instead be "delegated" to >> ivar x (and then y if no lookup is found in x either). > > Lately, I've been thinking that it would be useful to have a delegation > operator. For the sake argument, let's use backtick, since it's not used in > Smalltalk. The operator could be applied to the receiver in a message send, > like this: > > `anObject doSomething > > This would cause the #doSomething message to behave like a super send. The > selector #doSomething would be dispatched with respect to anObject, but the > method would be executed with the sender as the receiver. > > I'm not sure what patterns of composition would emerge in a langauge that > supported it, but it seems like the simplest way to allow one object to > delegate to another object without inheriting from it. > > Colin > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Colin Putney
Colin Putney wrote:
> Well, going back to the original Traits paper[1]: Thanks for the quotes. > And later in the same section (note the third rule): > > Trait composition respects the following three rules: > > • Methods defined in the class take precedence over trait methods. > This allows the glue methods defined > in a class to override methods with the same name provided by the > used traits. > > • Flattening property. A non-overridden method in a trait has the > same semantics as if it were implemented > directly in the class using the trait. > > • Composition order is irrelevant. All the traits have the same > precedence, and hence conflicting trait > methods must be explicitly disambiguated. Indeed. It was this talk about "explicit disambiguation" (which I recalled from other discussions) which led me to understand that "self traitConflict" is to be interpreted as "please be explicit about which of the methods you'd like to use" instead of "this method ain't here". > I don't see any references to XOR operations, so that must have come > from some other discussion of Traits. (I'm pretty sure I didn't make > that up from thin air!) Instead the paper talks about explicit conflicts > which have to be resolved, consistent with the #traitConflict methods > the Squeak implementation creates. > > So I guess "does not show up in the composition" is wrong. It would be > better to say "creates a conflict that must be explicitly resolved." But > still, I think it's fair to say that this is one of the defining > features of Traits, in contrast with Mixins, which do follow a "last one > wins" method of resolving conflicts. I suppose. I find it pretty useless but then again, I find MI in general pretty useless so there isn't much difference to me :-) (but rest assured that I'll leave the behavior alone for those people who care) Cheers, - Andreas |
Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Igor Stasenko
Hi!
Igor Stasenko wrote: > 2009/12/9 Göran Krampe <[hidden email]>: >> Given Andreas' statement above - wouldn't it be *much* cooler to evolve >> Smalltalk along the axis of composition instead of the axis of inheritance? >> >> I have always thought that having better mechanisms for delegation would be >> awesome, and would in most ways be much more powerful than inheritance (in >> whichever form). >> >> For example, what if one could declare that for class Foo (having ivars x, >> y, z) any message that would result in a DNU would instead be "delegated" to >> ivar x (and then y if no lookup is found in x either). >> >> This would be equivalent to tons of messages in Foo like: >> >> Foo>>name >> ^(x respondsTo: #name) ifTrue: [x name] ifFalse: [y name] >> >> (well, kinda, you get the picture - but also, taking care of x/y returning >> "self" in which case we probably should return the "Foo self" instead etc) > > > Hmm, how is it different to inheritance? > I mean, you can achieve similar effect by making > an instance of Foo class superclass to be x, and x superclass to be y. There are several differences I think. And do note I only made a "loose" sketch of the idea, not going into details like for example, "should Foo really delegate *everything* it doesn't respond to or just a specified protocol etc?". A few differences off the top of my head: - Since we delegate to ivars it is fully dynamic. We can change x and y dynamically. Sure, you can claim that we can change the class hierarchy dynamically too - but hey. - We have the distinction of "selves". Ted mentions "self" (the part) and "whole" (the composition). - We have encapsulation. Composition is black box reuse, inheritance is glass box :). In other words, x can not touch ivars of Foo and so on. And probably more. regards, Göran |
Re: Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Andreas.Raab
Hi!
Andreas Raab wrote: > Hi Göran - > > Unbelievable. You basically just described the very idea that started > this whole traits thing. When Nathanael worked with us at Disney, the Ah, interesting. Well, it is not *that* unbelievable given that everyone of us probably have had thoughts in these directions over the years. But it *is* interesting that an idea starting in *object* composition ends up being realized as a kind of MI. I wonder how that journey evolved. > traits direction came out of discussions where we wanted him to think > precisely along the lines you're describing. My original thoughts on > this matter was that I wanted to have something more like (biological) > cells - entities that are made up of smaller things (objects), that have > an inside and an outside (made up of other objects instead of > abstractions like the interface/implementation distinction), that > forward signals (messages) to the appropriate receptors etc. Right. I now reread the Membrane thing from Ted btw (I read it a while back) and yes, a lot is similar, but still different... He talks about parts being *very* "aware" of each other (feels slightly odd). He also describes the Membrane to "just be a Dictionary" which also feels odd, why not a full object? But yes, interesting - distinguishing "self" from "whole" is interesting, although I immediately find it questionable from some undefinable "gut feeling". :) regards, Göran |
Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Colin Putney
Hi!
Colin Putney wrote: > Lately, I've been thinking that it would be useful to have a delegation > operator. For the sake argument, let's use backtick, since it's not used > in Smalltalk. The operator could be applied to the receiver in a message > send, like this: > > `anObject doSomething > > This would cause the #doSomething message to behave like a super send. > The selector #doSomething would be dispatched with respect to anObject, > but the method would be executed with the sender as the receiver. > > I'm not sure what patterns of composition would emerge in a langauge > that supported it, but it seems like the simplest way to allow one > object to delegate to another object without inheriting from it. Ehm... so the method doSomething implemented in anObject suddenly can access ivars/self of the *sender*? That feels ... odd. :) regards, Göran |
Re: Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Andreas.Raab
Hi,
>My original thoughts on this matter was that I wanted to have something >more like (biological) cells - entities that are made up of smaller things >(objects), that have an inside and an outside (made up of other objects >instead of abstractions like the interface/implementation distinction), >that forward signals (messages) to the appropriate receptors etc. What >you're describing is very much in line with my thoughts at that point which >also included more actor-like structures (some of which was later realized >in Tweak and once I found E got an even stronger version in Croquet). IMO the main problem is that we[*] continue thinking we have classes in Smalltalk (and some people not updated about smalltalk still think we only use classification, and do not have support for alternative delegation schemas). If we consider we have species (we have an open system, so, classes concept is not correct), and consider the effect of our actions (external actors) through time; we can complement OO techniques with activities in a sustainable open system. imo it was ok in th e80's to say "Object subclass:..." but today, if we recognize/observe evolution in a Smalltalk system, we should stop speaking about classes, and start considering species (the distintion will not come from people talking about closed systems nor dynamic languages). As a sustainable open system, the bigbang of Smalltalk is only an instant in its history (not really important after it has happened); and the "contents of smalltalk" is also irrelevant; in aSmaltalk, anything can change, and it will continue been aSmalltalk "instance". Sometimes we put more attention in "design" and other models because that make us "understand" faster what is inside aSmalltalk; but that reductions (and use of encapsulation) also reveal the limits of OO and the reductionist method. We do not have a choice in technical field, because we are forced today to define object models... also for behavior!!! We are using machines, and we don´t know how to program without writing code [**]. That make us be tempted to decompose any element in smaller parts... going to the basic, the ideal, the abstract, the formula. In industry, the power of decomposition to basic concepts are also irrelevant (smalltalk has been the object ambience most used in software industry); and condensation of experience is always stored as classification based schemas; other forms of delegation are funny/elegant and used in marginal situations, complementing classification based structures. if we consider other forms of delegation and try to surpass the limits of OO instead of forcing the globe down to the waters of (oo) languages; imo we contribute to what make Smalltalk something unique from it birth up today. Returning to te topic "How about... something completelly diferent?" we are not doing something diferent; we are doing something complementary. Activities in an open system complements the use of OO techniques. The result of that activities are cristalized in classification based structures. cheers, Ale. [*] we= who call himself a Smalltalker. [**] hiding evidence of change of behavior in object systems without canges of code. In contrary to our convenience, because that way, code oriented people continue speaking about a "better language for all the world"; stoping any advance in complementary techniques/activities. ----- Original Message ----- From: "Andreas Raab" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Tuesday, December 08, 2009 9:08 PM Subject: [squeak-dev] Re: How about... something completely different? (Re: Re: On traits composition) > Hi Göran - > > Unbelievable. You basically just described the very idea that started this > whole traits thing. When Nathanael worked with us at Disney, the traits > direction came out of discussions where we wanted him to think precisely > along the lines you're describing. My original thoughts on this matter was > that I wanted to have something more like (biological) cells - entities > that are made up of smaller things (objects), that have an inside and an > outside (made up of other objects instead of abstractions like the > interface/implementation distinction), that forward signals (messages) to > the appropriate receptors etc. What you're describing is very much in line > with my thoughts at that point which also included more actor-like > structures (some of which was later realized in Tweak and once I found E > got an even stronger version in Croquet). > > Cheers, > - Andreas > > Göran Krampe wrote: >> Hi all! >> >> Andreas Raab wrote: >>> BTW, I really don't think there is much difference between mixins and >>> traits; all forms of MI are fairly equivalent. >>> >>> Cheers, >>> - Andreas >> >> As most of us I was also very positive when Traits first came to the >> scene. Now, I am a lot more jaded and think "well, sure, but are they >> worth it?". >> >> Given Andreas' statement above - wouldn't it be *much* cooler to evolve >> Smalltalk along the axis of composition instead of the axis of >> inheritance? >> >> I have always thought that having better mechanisms for delegation would >> be awesome, and would in most ways be much more powerful than inheritance >> (in whichever form). >> >> For example, what if one could declare that for class Foo (having ivars >> x, y, z) any message that would result in a DNU would instead be >> "delegated" to ivar x (and then y if no lookup is found in x either). >> >> This would be equivalent to tons of messages in Foo like: >> >> Foo>>name >> ^(x respondsTo: #name) ifTrue: [x name] ifFalse: [y name] >> >> (well, kinda, you get the picture - but also, taking care of x/y >> returning "self" in which case we probably should return the "Foo self" >> instead etc) >> >> In many ways the mechanism I am describing is "built into" languages like >> self and Slate (I think). >> >> IMHO the above is very useful and would allow fine grained composition >> similar to Traits but in a dynamic more object centric fashion. >> >> regards, Göran >> >> >> > > > |
Re: Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Casey Ransberger
Hi Ronald,
We have another choice. We can complement the use of classification with other delegation schemas. That way we do not need to choose between white and black; and can to use all the colors :-) best, Ale. ----- Original Message ----- From: "Ronald Spengler" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Wednesday, December 09, 2009 2:04 AM Subject: Re: [squeak-dev] Re: How about... something completely different? (Re: Re: On traits composition) Hey, while we're at it: what if we threw out classes and used prototypes instead? </snark> P.S. (sorry!) :P On Tuesday, December 8, 2009, K. K. Subramaniam <[hidden email]> wrote: > On Wednesday 09 December 2009 07:38:31 am Josh Gargus wrote: >> n Dec 8, 2009, at 4:08 PM, Andreas Raab wrote: >> > Hi Göran - >> > >> > Unbelievable. You basically just described the very idea that started >> > this whole traits thing. When Nathanael worked with us at Disney, the >> > traits direction came out of discussions where we wanted him to think >> > precisely along the lines you're describing. My original thoughts on >> > this >> > matter was that I wanted to have something more like (biological) >> > cells - >> > entities that are made up of smaller things (objects), that have an >> > inside and an outside (made up of other objects instead of abstractions >> > like the interface/implementation distinction), that forward signals >> > (messages) to the appropriate receptors etc. >> >> Ted and Ian at VPRI recently wrote short notes on this topic: >> http://www.vpri.org/pdf/m2009014_membrane.pdf (Ted) > How is this different from a "Bus" (e.g. D-Bus) - an active container > where > objects can connect to a receptor, seek other objects, get an object > instantiated (if necessary), communicate with them and disconnect. Objects > retain their autonomy and gain the ability to collaborate with peer > objects > across an active container. > > Subbu > > -- Ron |
Re: Re: How about... something completely different?(Re: Re: On traits composition)
|
|
In reply to this post by Göran Krampe
Hi,
> But yes, interesting - distinguishing "self" from "whole" is interesting, > although I immediately find it questionable from some undefinable "gut > feeling". :) imo the most enlightment fact is that the "whole" is NOT an object, it is not a composition, and it is not it's contents. We have it in Smalltalk and it is not the global Smalltalk, as a school of fishes is not aSet of Fish instances. Agree that we all had that kind of reflections during years... what have we done to promote advances in that direction? (and... more important to me) how we measure the results of our efforts? Ale. ----- Original Message ----- From: "Göran Krampe" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Wednesday, December 09, 2009 7:58 AM Subject: Re: [squeak-dev] Re: How about... something completely different?(Re: Re: On traits composition) > Hi! > > Andreas Raab wrote: >> Hi Göran - >> >> Unbelievable. You basically just described the very idea that started >> this whole traits thing. When Nathanael worked with us at Disney, the > > Ah, interesting. Well, it is not *that* unbelievable given that everyone > of us probably have had thoughts in these directions over the years. > > But it *is* interesting that an idea starting in *object* composition ends > up being realized as a kind of MI. I wonder how that journey evolved. > >> traits direction came out of discussions where we wanted him to think >> precisely along the lines you're describing. My original thoughts on this >> matter was that I wanted to have something more like (biological) cells - >> entities that are made up of smaller things (objects), that have an >> inside and an outside (made up of other objects instead of abstractions >> like the interface/implementation distinction), that forward signals >> (messages) to the appropriate receptors etc. > > Right. I now reread the Membrane thing from Ted btw (I read it a while > back) and yes, a lot is similar, but still different... He talks about > parts being *very* "aware" of each other (feels slightly odd). He also > describes the Membrane to "just be a Dictionary" which also feels odd, why > not a full object? > > But yes, interesting - distinguishing "self" from "whole" is interesting, > although I immediately find it questionable from some undefinable "gut > feeling". :) > > regards, Göran > > > |
Re: How about... something completely different?
|
|
In reply to this post by Igor Stasenko
On 8-Dec-09, at 11:02 PM, Igor Stasenko wrote: > In this respect, interesting, how to avoid a pitfal of circular > delegation. > > x -> y -> x > > if i send a message to x, and got DNU, it is automatically delegated > to y, > but in same way as x could delegate to y, y could delegate to another > object , and finally some of them > in delegation chain could delegate back to x. Circle is closed, and VM > will loop forever trying to lookup a method not implemented in any of > objects in such delegation chain. Yup, that's certainly a possibility. The only remedy is "don't do that." Consider it a bug, in the same way that we currently consider infinite recursion a bug. Colin |
Re: Re: How about... something completely different?(Re: Re: On traits composition)
|
|
In reply to this post by Alejandro F. Reimondo
Hi all!
Alejandro F. Reimondo wrote: > imo the most enlightment fact is that the "whole" is NOT an object, > it is not a composition, and it is not it's contents. > We have it in Smalltalk and it is not the global Smalltalk, > as a school of fishes is not aSet of Fish instances. I admit not entirely grokking what you Alejandro tried to communicate in the previous post, but I do agree that it is about "complementary" schemes, and not something *entirely* different. Anyway, I sat down discussing this thread with Jonas Beckman and others here at MSC and we made lots of interesting connections. At the moment I am looking at a rather trivial little "package" to experiment in this direction. Let's create class Cell, inheriting from Object. Let's give it a DNU implementation so that it can expose its Parts as part of its external protocol. Let's call it's internal objects "Parts" (hey, this word is not that good, suggestions?). Further: "Receptor" = a subset of the protocol of one of the parts of the Cell, being exposed as part of the protocol of the Cell. Thus if a Cell has three parts held as ivars (contrary to Ted's Membrane I want a Cell to be more or less a regular object), it can have 0-3 receptors, one possible receptor per part. Now... we can imagine various ways of defining the receptor for a given part: - Full receptor. This is "handle all messages that I don't handle", in other words full delegation. - Partial receptor. Using either activation/suppression (whitelist or blacklist of selectors) we specify a subset of selectors that we delegete. Ideally we do this late bound. - Delegated receptor. This is "let the part decide". ...anyway, an example would be to define the receptor for a given part as simply a Set of selectors, either a blacklist or a whitelist. And oh, yeah, the receptors probably need to be ordered to avoid conflicts (other ideas?). Summary: We refine the "delegation" concept by being able to delegate only a subset of messages. We call this subset the "Receptor" of the part. Second part: Let's also (as Alan Kay suggested in Ted's Membrane paper) add a TupleSpace-ish communication model inside the Cell that it's "parts" can *optionally* use to loosely communicate with the Cell and with each other. The parts can talk to each other and the Cell using just plain "object references" BUT... in order to more easily make them reusable and loosely coupled we could add an internal "message bus" in the Cell - and the most generic way to do that is probably to mimic a TupleSpace. Ok, sorry for my confused ramblings - but that is about it. I think I will hack this up to play with. And I rejected ideas Ted mentioned like dependencies, "whole" etc. I also think Alan is "right" to propose a loose messaging metaphor inside the Cell, contrary to Ted's idea of very close coupling. At the same time a Cell is meant to offer a spectrum - either you don't use receptors and don't use the tuplespace-thing - and then, tada, it is just a regular Object! All feedback/brainstorming appreciated. ciao, Göran |
Re: Re: On traits composition
|
|
In reply to this post by Andreas.Raab
On Wed, Dec 9, 2009 at 12:46 AM, Andreas Raab <[hidden email]> wrote:
I was so enthused about the Borning-Ingalls multiple inheritance implementation that I spent a lot of time in the BrouHaHa variant of Smalltalk-80 V2 fixing bugs (like making file-outs and class redefinitions work without regenerating spurious conflict methods), and providing an extension to the class definition to specify the resolution of conflicts (*). But after all that work there were precisely three instances of MI in the system; I made ReadWriteStream inherit multiply from ReadStream and WriteStream, DateAndTime inherit multiply from Date and Time and, of course, Queen inherited multiply from Rook and Bishop (**) :)
(*) P.S. e.g. you could say Class named: #ReadWriteStream superclasses: 'WriteStream ReadStream ' inheritanceAnnotation: 'WriteStream overrides: ReadStream'
instanceVariableNames: '' classVariableNames: '' category: 'Collections-Streams'! (**) P.P.S. Queen's MI was entirely spurious. The only method that Bishop and Rook defined was isPotentialMoveTo: position in: board. Since it was faster to reimplement isPotentialMoveTo:in: directly than as ^(Rook. isPotentialMoveTo: position in: board) or: [Bishop isPotentialMoveTo: position in: board] it didn't actually inherit anything from them.
|
Re: Re: How about... something completely different?
|
|
In reply to this post by Colin Putney
On Wed, Dec 9, 2009 at 9:15 AM, Colin Putney <[hidden email]> wrote:
and if the concern is a loop in the VM's lookup then all it has to do is remember the object or class it started the lookup in and abort (go straight to sending DNU) if it meets the same one again.
|
Re: Re: How about... something completely different?
|
|
2009/12/9 Eliot Miranda <[hidden email]>:
> > > On Wed, Dec 9, 2009 at 9:15 AM, Colin Putney <[hidden email]> wrote: >> >> On 8-Dec-09, at 11:02 PM, Igor Stasenko wrote: >> >>> In this respect, interesting, how to avoid a pitfal of circular >>> delegation. >>> >>> x -> y -> x >>> >>> if i send a message to x, and got DNU, it is automatically delegated to >>> y, >>> but in same way as x could delegate to y, y could delegate to another >>> object , and finally some of them >>> in delegation chain could delegate back to x. Circle is closed, and VM >>> will loop forever trying to lookup a method not implemented in any of >>> objects in such delegation chain. >> >> Yup, that's certainly a possibility. The only remedy is "don't do that." >> Consider it a bug, in the same way that we currently consider infinite >> recursion a bug. > > and if the concern is a loop in the VM's lookup then all it has to do is > remember the object or class it started the lookup in and abort (go straight > to sending DNU) if it meets the same one again. Care to add it to Cog as a precaution against future hacks? :) >> >> Colin >> > > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Göran Krampe
2009/12/9 Göran Krampe <[hidden email]> Hi! My understanding of one way to do delegation in Smalltalk is to bind self to the delegator and state to the delegate. So within a delegated send, sends to self are still understood by the delegator. If this doesn't happen then all you're doing is message forwarding, and that happens anyway. This doesn't allow the delegate to access the state of the delegator, nor does it allow the delegator to access the state of the delegate, but it does allow the delegator to inherit behaviour from the delegate.
The implementation of this is quite simple. A context needs a state slot in addition to a self slot. References to self (explicit foo := self, and super sends, explicit references to self) reference the self slot. Accesses to instance variables reference the state slot. A normal send binds the self and state slots to the receiver of the send. A delegating send (a delegation??) binds the new self to current self and state to the receiver. A self send within a delegate binds new self to current self and new state to current state if new self == current self, otherwise self and state are bound to the receiver.
One of the things I've purposely done differently in the Cog closure implementation to VisualWorks is to provide a distinct reference to self, so that within a closure access to self and instance variables is exactly the same as in a method. In VisualWorks self is a copied value of a closure and completely different bytecodes are used to access self and instance variables within a closure as opposed to in a method. I did this with a view to simplifying delegation implementation.
best Eliot
|
Re: Re: How about... something completely different?
|
|
In reply to this post by Igor Stasenko
On Wed, Dec 9, 2009 at 10:36 AM, Igor Stasenko <[hidden email]> wrote: 2009/12/9 Eliot Miranda <[hidden email]>: Good suggestion. <scottish>Now sends are faster this kind of check is much cheaper</scottish>
|
Re: How about... something completely different? (Re: Re: On traits composition)
|
|
In reply to this post by Eliot Miranda-2
On Wed, Dec 9, 2009 at 1:58 PM, Eliot Miranda <[hidden email]> wrote:
Back at the turn of the century (I like saying that), I did exactly this for squeak...there was an unused inst var in the context (receiverMap IIRC) and I used it to separate the receiver from the state holder. I added a delegation bytecode as well as a primitive (but I never modified the compiler to actually produce the bytecode). I also modified message lookup a bit to enable Self style multiple inheritance. Adam Spitz even went so far as to use it to recreate the Self inspectors in squeak.
- Stephen |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |