[vwnc] #isAxxx vs #respondsTo: vs isKindOf:
Locked
[vwnc] #isAxxx vs #respondsTo: vs isKindOf:
 
|
On the squeak mailing list there is some discussion about the proliferation of
#isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: because they operate on the objects. However, recognizing the #isAxxx mess, it occurs to me that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx on Object achieves the same goal and does not cause Object to have all these #isAxxx methods. This also works for classes that support the #isAxxx protocols but may not be in the same inheritance hierarchy, which is needed for #isKindOf:. Furthermore, if #respondsTo: was done in a primitive it could be almost as fast as using #isAxxx. What do you think? Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
If any such code has to be added, I'd rather have the #isBlah methods.
Ideally, however, I'd replace someObject isBlah ifTrue: [someObject this] ifFalse: [someObject that] with Object>>doAsAppropriateForTheSituationAbove ^self that Blah>>doAsAppropriateForTheSituationAbove ^self this In other words, #isBlah, #respondsTo:, #isKindOf: etc reimplement the work the VM is doing when it does class checks before sending messages. No such work should be done by the image, unless it is necessary for the image to reflect on itself. Most of the time, the image doesn't really need to reflect on its own structure when it does #isBlah, #respondsTo: or #isKindOf:, so IME these messages end up being a rug where deficient object design is swept under. Moreover, in as much as these messages prevent objects from using their own identity to drive their behavior (as in the polymorphic approach above), unnecessary use of #isBlah, #respondsTo: and #isKindOf: represents the programmer writing in the first person, i.e.: writing procedural code. Code should be written in the third person instead. Andres. Terry Raymond wrote: > On the squeak mailing list there is some discussion about the proliferation of > #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: because they > operate on the objects. However, recognizing the #isAxxx mess, it occurs to me > that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx on Object > achieves the same goal and does not cause Object to have all these #isAxxx > methods. This also works for classes that support the #isAxxx protocols but > may not be in the same inheritance hierarchy, which is needed for #isKindOf:. > > Furthermore, if #respondsTo: was done in a primitive it could be almost as fast > as using #isAxxx. > > What do you think? > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
In reply to this post by Terry Raymond
On Thu, Jul 2, 2009 at 5:06 PM, Terry Raymond <[hidden email]> wrote: On the squeak mailing list there is some discussion about the proliferation of Um, I doubt it. Compare the performance of perform: with a direct send. That's the performance difference you'd be talking about.
I think isFoo is just fine. If you want to cut down isFoo, implement an isMemberOfMyFramework and implement all the itty bitty isFoo methods specific to your framework in root classes therein. Then you save thing isMemberOfMyFramework and: [thing isFoo]. This works well in e.g. the Squeak Compiler where there is isParseNode and various isFoos in ParseNode and subclasses.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
Eliot et al, I thought I'd bring up that I have an
implementation of the Game of Life that runs faster with polymorphism than with
small integers. In other words, the alternate implementation of the Game
of Life does not use arithmetic of any kind to count neighbors and mutate
cells. In addition, for A Course Mentoring on Smalltalk, I implemented
match: with one class per character. In general, it runs faster than the
heavily optimized version we use today which relies on ==. Sometimes, it
runs up to 2x faster. The key is designing your object network so that the
answers to ifTrue:ifFalse: become known at design time, rather than run
time. If you know the answers, you might as well skip the question
completely. The net result is that your program has less work to do, and
hence, it has to run faster. From: [hidden email] [mailto:[hidden email]] On Behalf Of Eliot Miranda Sent: Thursday, July 02, 2009 6:38 PM To: vwnc NC Subject: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: On Thu, Jul 2, 2009 at 5:06 PM, Terry Raymond <[hidden email]>
wrote: On the squeak mailing list there is some discussion about the proliferation of Um, I doubt it. Compare the performance of perform: with a direct
send. That's the performance difference you'd be talking about.
I think isFoo is just fine. If you want to cut down isFoo, implement
an isMemberOfMyFramework and implement all the itty bitty isFoo methods specific
to your framework in root classes therein. Then you save thing
isMemberOfMyFramework and: [thing isFoo]. This works well in e.g. the
Squeak Compiler where there is isParseNode and various isFoos in ParseNode and
subclasses.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
In reply to this post by Terry Raymond
Terry Raymond schrieb:
> On the squeak mailing list there is some discussion about the proliferation of > #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: because they > operate on the objects. However, recognizing the #isAxxx mess, it occurs to me > that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx on Object > achieves the same goal and does not cause Object to have all these #isAxxx > methods. This also works for classes that support the #isAxxx protocols but > may not be in the same inheritance hierarchy, which is needed for #isKindOf:. It is a mess doing this, but that doesnt invalidate the idea. I think the problem basically is that people simply add their classes below Object. If you add a wrapping class in between where you gather all the #isxxx and so on methods, you have the same reliability and do not clutter Object with testing methods. I.E. Object Car #isFord ^false #isToyota ^false Ford Toyota in a kind of broken example. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Eliot Miranda-2
We have augmented the base classes to define #isOfType<yourClassNameHere> in all classes you define plus Object. It was done to take advantage of the speed difference between polymorphic calls and #isKindOf: Eliot is talking about. And I very much do not like the end result. It encourages programmers to code case statements instead the approach Andres has described.
Another side-effect is that now everybody dreads to open a class browser on Object - it takes ages to build the structs out of the methodDict. And nobody really looked for the performance impact of having 20k+ methods in the method dictionary, which has to looked through in case of any Object level method invocation. Most of those methods never get sent either. In other word a framework idea gone very bad. Now, I can recognise that sometimes it is simpler to use a switch than go implementing polymorphic behaviour all over the system and in those cases I prefer #isKindOf:. It has this appeal of being more "in spirit of" Interface check (or Protocol using Smalltalk vocabulary) rather than being a type check. Nothing's going to be better than decent OO design using polymorphism though. Regards, Jaroslaw. On 3 Jul 2009, at 02:38, Eliot Miranda wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
In reply to this post by Claus Kick
Claus Kick wrote: But where do you put "isCar"??, not in "Car" since you know its a "car".Terry Raymond schrieb: We and others I assume, have cases where a parameter to a method may be either some system class or some custom class. Our example is business object attributes, which might be strings, dates, times, phoneNumbers, ... I need to know what it is sometimes, so "isPhone" is nice, but it might go to a String or a Date etc, so one needs "isPhone" in "Object" to say false. I guess I agree with someone who posted that you might add one method to Object (isMine), then you can say (xxx isMine and: [xxx isPhone]) We used to do that, but it became cumberson, so we gave up and went with isPhone in Object. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@... Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
I would not use this outside rather small sub-hierarchies. In a more
general scope, this indicates a serious lack of polymorphy and therefore results in procedural code (reminds me of the "switch" statement that so many beginners are asking for). In many cases, using a visitor pattern is also appropriate. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
In reply to this post by Dennis smith-4
Dennis Smith schrieb:
> > > Claus Kick wrote: >> Terry Raymond schrieb: >> >>> On the squeak mailing list there is some discussion about the >>> proliferation of >>> #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: >>> because they >>> operate on the objects. However, recognizing the #isAxxx mess, it >>> occurs to me >>> that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx >>> on Object >>> achieves the same goal and does not cause Object to have all these >>> #isAxxx >>> methods. This also works for classes that support the #isAxxx >>> protocols but >>> may not be in the same inheritance hierarchy, which is needed for >>> #isKindOf:. >>> >> >> It is a mess doing this, but that doesnt invalidate the idea. >> I think the problem basically is that people simply add their classes >> below Object. >> If you add a wrapping class in between where you gather all the #isxxx >> and so on methods, you have the same reliability and do not clutter >> Object with testing methods. >> >> I.E. >> >> Object >> Car >> #isFord ^false >> #isToyota ^false >> Ford >> Toyota >> >> in a kind of broken example. >> > But where do you put "isCar"??, not in "Car" since you know its a "car". > > We and others I assume, have cases where a parameter to a method may be > either some > system class or some custom class. Our example is business object > attributes, which might be > strings, dates, times, phoneNumbers, ... > > I need to know what it is sometimes, so "isPhone" is nice, but it might > go to a String or a Date etc, so one > needs "isPhone" in "Object" to say false. There is a school of thought that says, "if you use isXXX methods, then your design is wrong". Not my thoughts completely, as I recognize that there are cases where you have to put a tester into Object, (for instance, if you only have one class below object and no hierarchy), but I tend to agree in most cases. processMe: anArgument anArgument isCar ifTrue:[^self bla]. anArgument isPhone ifTrue:[^self handlePhone]. You have to have stuff like that then somewhere. Someone else said, using a visitor pattern might solve this. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
In reply to this post by Andres Valloud-6
Andres,
As an exercise in good OO design, I would be interested in these examples of polymorphism. It would certainly help me educate my peers in advanced OO design when, for example, you can solve the near-neighbor problem in Life without counting. The same goes for your mentoring course.
Are these materials available?
Cheers!
From:
[hidden email] [mailto:[hidden email]] On Behalf Of Valloud, Andres
Eliot et al, I thought I'd bring up that I have an implementation of the Game of Life that runs faster with polymorphism than with small integers. In other words, the alternate implementation of the Game of Life does not use arithmetic of any kind to count neighbors and mutate cells. In addition, for A Course Mentoring on Smalltalk, I implemented match: with one class per character. In general, it runs faster than the heavily optimized version we use today which relies on ==. Sometimes, it runs up to 2x faster. The key is designing your object network so that the answers to ifTrue:ifFalse: become known at design time, rather than run time. If you know the answers, you might as well skip the question completely. The net result is that your program has less work to do, and hence, it has to run faster.
From:
[hidden email] [mailto:[hidden email]] On Behalf Of Eliot Miranda
On Thu, Jul 2, 2009 at 5:06 PM, Terry Raymond <[hidden email]> wrote: On the squeak mailing list there is some discussion about the
proliferation of
Um, I doubt it. Compare the performance of perform: with a direct send. That's the performance difference you'd be talking about.
I think isFoo is just fine. If you want to cut down isFoo, implement an isMemberOfMyFramework and implement all the itty bitty isFoo methods specific to your framework in root classes therein. Then you save thing isMemberOfMyFramework and: [thing isFoo]. This works well in e.g. the Squeak Compiler where there is isParseNode and various isFoos in ParseNode and subclasses.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|||||||||||||
The Environment:
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
Andres, Tom,
although I am not giving any lessons, I am interested in this implementation too - just to broaden my horizon. Greetings, Steffen Am 06.07.2009, 19:57 Uhr, schrieb <[hidden email]>: > Andres, > > As an exercise in good OO design, I would be interested in these > examples of polymorphism. It would certainly help me educate my peers > in advanced OO design when, for example, you can solve the near-neighbor > problem in Life without counting. The same goes for your mentoring > course. > > Are these materials available? > > Cheers! > > Tom Hawker > > [cid:image001.gif@01C9FE28.931DA3F0] > > Senior Framework Developer > > Home > > +1 (408) 274-4128 > > [cid:image002.gif@01C9FE28.931DA3F0]The Environment: > We take it personally > > Office > > +1 (408) 576-6591 > > Mobile > > +1 (408) 835-3643 > > > ________________________________ > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Valloud, Andres > Sent: Thursday, July 02, 2009 6:49 PM > To: vwnc NC > Subject: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: > > Eliot et al, I thought I'd bring up that I have an implementation of the > Game of Life that runs faster with polymorphism than with small > integers. In other words, the alternate implementation of the Game of > Life does not use arithmetic of any kind to count neighbors and mutate > cells. In addition, for A Course Mentoring on Smalltalk, I implemented > match: with one class per character. In general, it runs faster than > the heavily optimized version we use today which relies on ==. > Sometimes, it runs up to 2x faster. The key is designing your object > network so that the answers to ifTrue:ifFalse: become known at design > time, rather than run time. If you know the answers, you might as well > skip the question completely. The net result is that your program has > less work to do, and hence, it has to run faster. > > ________________________________ > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Eliot Miranda > Sent: Thursday, July 02, 2009 6:38 PM > To: vwnc NC > Subject: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: > > On Thu, Jul 2, 2009 at 5:06 PM, Terry Raymond > <[hidden email]<mailto:[hidden email]>> > wrote: > On the squeak mailing list there is some discussion about the > proliferation of > #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: > because they > operate on the objects. However, recognizing the #isAxxx mess, it occurs > to me > that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx on > Object > achieves the same goal and does not cause Object to have all these > #isAxxx > methods. This also works for classes that support the #isAxxx protocols > but > may not be in the same inheritance hierarchy, which is needed for > #isKindOf:. > > Furthermore, if #respondsTo: was done in a primitive it could be almost > as fast > as using #isAxxx. > > Um, I doubt it. Compare the performance of perform: with a direct > send. That's the performance difference you'd be talking about. > > > > What do you think? > > I think isFoo is just fine. If you want to cut down isFoo, implement an > isMemberOfMyFramework and implement all the itty bitty isFoo methods > specific to your framework in root classes therein. Then you save thing > isMemberOfMyFramework and: [thing isFoo]. This works well in e.g. the > Squeak Compiler where there is isParseNode and various isFoos in > ParseNode and subclasses. > > > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 > [hidden email]<mailto:[hidden email]> > <http://www.craftedsmalltalk.com> > =========================================================== > > > _______________________________________________ > vwnc mailing list > [hidden email]<mailto:[hidden email]> > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > IMPORTANT NOTICE > Email from OOCL is confidential and may be legally privileged. If it is > not > intended for you, please delete it immediately unread. The internet > cannot guarantee that this communication is free of viruses, interception > or interference and anyone who communicates with us by email is taken > to accept the risks in doing so. Without limitation, OOCL and its > affiliates > accept no liability whatsoever and howsoever arising in connection with > the use of this email. Under no circumstances shall this email > constitute > a binding agreement to carry or for provision of carriage services by > OOCL, > which is subject to the availability of carrier's equipment and vessels > and > the terms and conditions of OOCL's standard bill of lading which is also > available at http://www.oocl.com. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
There is a wonderful book by Andrés Valloud called "A Mentoring Course on
Smalltalk" available in http://www.lulu.com/content/2097931 Georg Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812 Tel. +49-3496-214328, Fax +49-3496-214712 > -----Ursprüngliche Nachricht----- > Von: [hidden email] [mailto:[hidden email]] Im Auftrag > von Steffen Märcker > Gesendet: Montag, 6. Juli 2009 21:05 > An: [hidden email]; [hidden email]; [hidden email] > Betreff: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: > > Andres, Tom, > > although I am not giving any lessons, I am interested in this > implementation too - just to broaden my horizon. > > Greetings, > Steffen > > > Am 06.07.2009, 19:57 Uhr, schrieb <[hidden email]>: > > > Andres, > > > > As an exercise in good OO design, I would be interested in these > > examples of polymorphism. It would certainly help me educate my peers > > in advanced OO design when, for example, you can solve the near-neighbor > > problem in Life without counting. The same goes for your mentoring > > course. > > > > Are these materials available? > > > > Cheers! > > > > Tom Hawker > > > > [cid:image001.gif@01C9FE28.931DA3F0] > > > > Senior Framework Developer > > > > Home > > > > +1 (408) 274-4128 > > > > [cid:image002.gif@01C9FE28.931DA3F0]The Environment: > > We take it personally > > > > Office > > > > +1 (408) 576-6591 > > > > Mobile > > > > +1 (408) 835-3643 > > > > > > ________________________________ > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Valloud, Andres > > Sent: Thursday, July 02, 2009 6:49 PM > > To: vwnc NC > > Subject: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: > > > > Eliot et al, I thought I'd bring up that I have an implementation of the > > Game of Life that runs faster with polymorphism than with small > > integers. In other words, the alternate implementation of the Game of > > Life does not use arithmetic of any kind to count neighbors and mutate > > cells. In addition, for A Course Mentoring on Smalltalk, I implemented > > match: with one class per character. In general, it runs faster than > > the heavily optimized version we use today which relies on ==. > > Sometimes, it runs up to 2x faster. The key is designing your object > > network so that the answers to ifTrue:ifFalse: become known at design > > time, rather than run time. If you know the answers, you might as well > > skip the question completely. The net result is that your program has > > less work to do, and hence, it has to run faster. > > > > ________________________________ > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Eliot Miranda > > Sent: Thursday, July 02, 2009 6:38 PM > > To: vwnc NC > > Subject: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: > > > > On Thu, Jul 2, 2009 at 5:06 PM, Terry Raymond > > <[hidden email]<mailto:[hidden email]>> > > wrote: > > On the squeak mailing list there is some discussion about the > > proliferation of > > #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: > > because they > > operate on the objects. However, recognizing the #isAxxx mess, it occurs > > to me > > that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx on > > Object > > achieves the same goal and does not cause Object to have all these > > #isAxxx > > methods. This also works for classes that support the #isAxxx protocols > > but > > may not be in the same inheritance hierarchy, which is needed for > > #isKindOf:. > > > > Furthermore, if #respondsTo: was done in a primitive it could be almost > > as fast > > as using #isAxxx. > > > > Um, I doubt it. Compare the performance of perform: with a direct > > send. That's the performance difference you'd be talking about. > > > > > > > > What do you think? > > > > I think isFoo is just fine. If you want to cut down isFoo, implement an > > isMemberOfMyFramework and implement all the itty bitty isFoo methods > > specific to your framework in root classes therein. Then you save thing > > isMemberOfMyFramework and: [thing isFoo]. This works well in e.g. the > > Squeak Compiler where there is isParseNode and various isFoos in > > ParseNode and subclasses. > > > > > > > > Terry > > > > =========================================================== > > Terry Raymond > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 > > [hidden email]<mailto:[hidden email]> > > <http://www.craftedsmalltalk.com> > > =========================================================== > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email]<mailto:[hidden email]> > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > IMPORTANT NOTICE > > Email from OOCL is confidential and may be legally privileged. If it is > > not > > intended for you, please delete it immediately unread. The internet > > cannot guarantee that this communication is free of viruses, > interception > > or interference and anyone who communicates with us by email is taken > > to accept the risks in doing so. Without limitation, OOCL and its > > affiliates > > accept no liability whatsoever and howsoever arising in connection with > > the use of this email. Under no circumstances shall this email > > constitute > > a binding agreement to carry or for provision of carriage services by > > OOCL, > > which is subject to the availability of carrier's equipment and vessels > > and > > the terms and conditions of OOCL's standard bill of lading which is also > > available at http://www.oocl.com. > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf:
|
|
The Mentoring Course book devotes chapter 3 to the implementation of
match: in about 10 different ways. The Game of Life implemented without small integers was exercise 3.30 in that volume. For the fundamentals book, which I am about to finish, I actually solved exercise 3.30 and wrote about the code at length. I may consider releasing the match: code and its rather extensive tests / benchmarks. The Game of Life code, however, has to wait until the first volume of the Fundamentals book is out at the very least. Georg Heeg wrote: > There is a wonderful book by Andrés Valloud called "A Mentoring Course on > Smalltalk" available in http://www.lulu.com/content/2097931 > > Georg > > Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812 > Tel. +49-3496-214328, Fax +49-3496-214712 > > >> -----Ursprüngliche Nachricht----- >> Von: [hidden email] [mailto:[hidden email]] Im Auftrag >> von Steffen Märcker >> Gesendet: Montag, 6. Juli 2009 21:05 >> An: [hidden email]; [hidden email]; [hidden email] >> Betreff: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: >> >> Andres, Tom, >> >> although I am not giving any lessons, I am interested in this >> implementation too - just to broaden my horizon. >> >> Greetings, >> Steffen >> >> >> Am 06.07.2009, 19:57 Uhr, schrieb <[hidden email]>: >> >> >>> Andres, >>> >>> As an exercise in good OO design, I would be interested in these >>> examples of polymorphism. It would certainly help me educate my peers >>> in advanced OO design when, for example, you can solve the near-neighbor >>> problem in Life without counting. The same goes for your mentoring >>> course. >>> >>> Are these materials available? >>> >>> Cheers! >>> >>> Tom Hawker >>> >>> [cid:image001.gif@01C9FE28.931DA3F0] >>> >>> Senior Framework Developer >>> >>> Home >>> >>> +1 (408) 274-4128 >>> >>> [cid:image002.gif@01C9FE28.931DA3F0]The Environment: >>> We take it personally >>> >>> Office >>> >>> +1 (408) 576-6591 >>> >>> Mobile >>> >>> +1 (408) 835-3643 >>> >>> >>> ________________________________ >>> From: [hidden email] [mailto:[hidden email]] On >>> Behalf Of Valloud, Andres >>> Sent: Thursday, July 02, 2009 6:49 PM >>> To: vwnc NC >>> Subject: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: >>> >>> Eliot et al, I thought I'd bring up that I have an implementation of the >>> Game of Life that runs faster with polymorphism than with small >>> integers. In other words, the alternate implementation of the Game of >>> Life does not use arithmetic of any kind to count neighbors and mutate >>> cells. In addition, for A Course Mentoring on Smalltalk, I implemented >>> match: with one class per character. In general, it runs faster than >>> the heavily optimized version we use today which relies on ==. >>> Sometimes, it runs up to 2x faster. The key is designing your object >>> network so that the answers to ifTrue:ifFalse: become known at design >>> time, rather than run time. If you know the answers, you might as well >>> skip the question completely. The net result is that your program has >>> less work to do, and hence, it has to run faster. >>> >>> ________________________________ >>> From: [hidden email] [mailto:[hidden email]] On >>> Behalf Of Eliot Miranda >>> Sent: Thursday, July 02, 2009 6:38 PM >>> To: vwnc NC >>> Subject: Re: [vwnc] #isAxxx vs #respondsTo: vs isKindOf: >>> >>> On Thu, Jul 2, 2009 at 5:06 PM, Terry Raymond >>> <[hidden email]<mailto:[hidden email]>> >>> wrote: >>> On the squeak mailing list there is some discussion about the >>> proliferation of >>> #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: >>> because they >>> operate on the objects. However, recognizing the #isAxxx mess, it occurs >>> to me >>> that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx on >>> Object >>> achieves the same goal and does not cause Object to have all these >>> #isAxxx >>> methods. This also works for classes that support the #isAxxx protocols >>> but >>> may not be in the same inheritance hierarchy, which is needed for >>> #isKindOf:. >>> >>> Furthermore, if #respondsTo: was done in a primitive it could be almost >>> as fast >>> as using #isAxxx. >>> >>> Um, I doubt it. Compare the performance of perform: with a direct >>> send. That's the performance difference you'd be talking about. >>> >>> >>> >>> What do you think? >>> >>> I think isFoo is just fine. If you want to cut down isFoo, implement an >>> isMemberOfMyFramework and implement all the itty bitty isFoo methods >>> specific to your framework in root classes therein. Then you save thing >>> isMemberOfMyFramework and: [thing isFoo]. This works well in e.g. the >>> Squeak Compiler where there is isParseNode and various isFoos in >>> ParseNode and subclasses. >>> >>> >>> >>> Terry >>> >>> =========================================================== >>> Terry Raymond >>> Crafted Smalltalk >>> 80 Lazywood Ln. >>> Tiverton, RI 02878 >>> (401) 624-4517 >>> [hidden email]<mailto:[hidden email]> >>> <http://www.craftedsmalltalk.com> >>> =========================================================== >>> >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email]<mailto:[hidden email]> >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >>> >>> IMPORTANT NOTICE >>> Email from OOCL is confidential and may be legally privileged. If it is >>> not >>> intended for you, please delete it immediately unread. The internet >>> cannot guarantee that this communication is free of viruses, >>> >> interception >> >>> or interference and anyone who communicates with us by email is taken >>> to accept the risks in doing so. Without limitation, OOCL and its >>> affiliates >>> accept no liability whatsoever and howsoever arising in connection with >>> the use of this email. Under no circumstances shall this email >>> constitute >>> a binding agreement to carry or for provision of carriage services by >>> OOCL, >>> which is subject to the availability of carrier's equipment and vessels >>> and >>> the terms and conditions of OOCL's standard bill of lading which is also >>> available at http://www.oocl.com. >>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > . > > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Spam: #isAxxx vs #respondsTo: vs isKindOf:
|
|
In reply to this post by Terry Raymond
On Jul 2, 2009, at 5:06 PM, Terry Raymond wrote: > On the squeak mailing list there is some discussion about the > proliferation of > #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: > because they > operate on the objects. However, recognizing the #isAxxx mess, it > occurs to me > that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx > on Object > achieves the same goal and does not cause Object to have all these > #isAxxx > methods. This also works for classes that support the #isAxxx > protocols but > may not be in the same inheritance hierarchy, which is needed for > #isKindOf:. > > Furthermore, if #respondsTo: was done in a primitive it could be > almost as fast > as using #isAxxx. > > What do you think? Just getting home from vacation and scanning over the thread... Does there have to be a one size fits all answer to this? Do all problems have to be solved with hammers? And does the screwdriver union have to argue vehemently that hammers should be abolished in favor of their preferred tool? My experience over the years is that you use the right tool for the job at the time. The simplest pragmatic thing that could possibly work. Some isStuff is good and handy. Too much is like the guy that just can't quit putting seasoning on the steak you're cooking. Same with abusive use of of the respondsTo: family. Though if this family wasn't worthwhile, it wouldn't be in the system at all. Polymorphism is great, but not always the most applicable approach in all contexts. Why does there have to be such a religious fervor of any of these? -- Travis Griggs Objologist "The best way to know you have a mind is to change it" -Judge Pierre Leval _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Spam: #isAxxx vs #respondsTo: vs isKindOf:
|
|
Travis
My message was directed to the desire to reduce the number of extension methods in Object. Just as long methods are a code smell I consider a large number of methods in a class, even Object, to be a code smell. It occurred to me that using (obj respondsTo: #isAxxx) in place of just (obj isAxxx) would allow one to remove the #isAxxx methods from Object. As for those who suggest that it smacks of procedural code instead of good OO techniques I would like to point out that readability is very important measure and code that reads like (is in some state) ifTrue: [do stuff] ifFalse: [do other stuff] is easier to understand than a polymorphic message that forces you to look at multiple classes to find the conditional actions. *** It is a trade-off, you don't always use the same technique *** Additionally, using #isAxxx does not mean you first test it and then do a message send to object, you may do something like obj isAxxx ifTrue: [someColl add: obj] ifFalse: [do stuff. anotherColl add: obj]. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs > Sent: Thursday, July 09, 2009 3:30 AM > To: VWNC > Subject: Re: [vwnc] Spam: #isAxxx vs #respondsTo: vs isKindOf: > > > On Jul 2, 2009, at 5:06 PM, Terry Raymond wrote: > > > On the squeak mailing list there is some discussion about the > > proliferation of > > #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: > > because they > > operate on the objects. However, recognizing the #isAxxx mess, it > > occurs to me > > that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx > > on Object > > achieves the same goal and does not cause Object to have all these > > #isAxxx > > methods. This also works for classes that support the #isAxxx > > protocols but > > may not be in the same inheritance hierarchy, which is needed for > > #isKindOf:. > > > > Furthermore, if #respondsTo: was done in a primitive it could be > > almost as fast > > as using #isAxxx. > > > > What do you think? > > Just getting home from vacation and scanning over the thread... Does > there have to be a one size fits all answer to this? Do all problems > have to be solved with hammers? And does the screwdriver union have to > argue vehemently that hammers should be abolished in favor of their > preferred tool? > > My experience over the years is that you use the right tool for the > job at the time. The simplest pragmatic thing that could possibly > work. Some isStuff is good and handy. Too much is like the guy that > just can't quit putting seasoning on the steak you're cooking. Same > with abusive use of of the respondsTo: family. Though if this family > wasn't worthwhile, it wouldn't be in the system at all. Polymorphism > is great, but not always the most applicable approach in all contexts. > Why does there have to be such a religious fervor of any of these? > > -- > Travis Griggs > Objologist > "The best way to know you have a mind is to change it" -Judge Pierre > Leval > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Spam: #isAxxx vs #respondsTo: vs isKindOf:
|
|
Terry, et al:
As an adjunct to your argument, let me point out that a proliferation of sends of #is* implies that in many places in the code, we have no idea what arguments are coming in, and we are using this test to sort them out. In my experience, most frequently the choices are either 1) it's a Foo, which is what I want, 2) it's nil, meaning something is wrong or missing or 3) it's a string with the name of the Foo I'm going to look up. If I only ever got an instance of Foo as argument, then I would certainly not need the "if". To my mind, the breakdown is that the sender of doSomethingWith: aFooOrStringOrNil knows exactly the type of the variable being passed (if not the direct sender, then a sender farther up the stack)! So somewhere along the way, the information about the argument's type is getting lost, and then the #is* method is trying to rediscover it. So I believe that the error is not with the proliferation of #is* methods, but rather with losing information as messages are being sent. One way to correct this, at least abstractly, is to make the decisions about what messages to send with what arguments higher up in the call stack (ie further back in time), when we know exactly what the arguments are going to be. So, as a trivial example, instead of doSomethingWith: aFoo "which is really aFoo, aString orNil" make methods like this: doSomethingWith: aFoo findFooName: aString ifNone: aBlock and then resolve the argument in the sender of doSomethingWith:, where you know what you have: A string, a Foo, or nil because we have either an error or not decided yet on which Foo instance we need. This allows the VM to decide which messages to send through its polymorphic message send lookup mechanism, rather than the programmer making the choices with "if" statements. In fact, I argue that OO programming at its heart is exactly this: "If" statement elimination. Best regards -Anthony On 9-Jul-09, at 7:52 AM, Terry Raymond wrote: > Travis > > My message was directed to the desire to reduce the number > of extension methods in Object. > > Just as long methods are a code smell I consider a large > number of methods in a class, even Object, to be a code smell. > > It occurred to me that using (obj respondsTo: #isAxxx) in > place of just (obj isAxxx) would allow one to remove the > #isAxxx methods from Object. > > As for those who suggest that it smacks of procedural code > instead of good OO techniques I would like to point out that > readability is very important measure and code that reads > like > > (is in some state) > ifTrue: [do stuff] > ifFalse: [do other stuff] > > is easier to understand than a polymorphic message that > forces you to look at multiple classes to find the conditional > actions. > > *** It is a trade-off, you don't always use the same technique *** > > Additionally, using #isAxxx does not mean you first test > it and then do a message send to object, you may do something > like > > obj isAxxx > ifTrue: [someColl add: obj] > ifFalse: [do stuff. anotherColl add: obj]. > > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On >> Behalf Of Travis Griggs >> Sent: Thursday, July 09, 2009 3:30 AM >> To: VWNC >> Subject: Re: [vwnc] Spam: #isAxxx vs #respondsTo: vs isKindOf: >> >> >> On Jul 2, 2009, at 5:06 PM, Terry Raymond wrote: >> >>> On the squeak mailing list there is some discussion about the >>> proliferation of >>> #isAxxx methods. Inherently, I dislike #respondsTo: and #isKindOf: >>> because they >>> operate on the objects. However, recognizing the #isAxxx mess, it >>> occurs to me >>> that doing 'anObject respondsTo: #isAxxx' and not defining #isAxxx >>> on Object >>> achieves the same goal and does not cause Object to have all these >>> #isAxxx >>> methods. This also works for classes that support the #isAxxx >>> protocols but >>> may not be in the same inheritance hierarchy, which is needed for >>> #isKindOf:. >>> >>> Furthermore, if #respondsTo: was done in a primitive it could be >>> almost as fast >>> as using #isAxxx. >>> >>> What do you think? >> >> Just getting home from vacation and scanning over the thread... Does >> there have to be a one size fits all answer to this? Do all problems >> have to be solved with hammers? And does the screwdriver union have >> to >> argue vehemently that hammers should be abolished in favor of their >> preferred tool? >> >> My experience over the years is that you use the right tool for the >> job at the time. The simplest pragmatic thing that could possibly >> work. Some isStuff is good and handy. Too much is like the guy that >> just can't quit putting seasoning on the steak you're cooking. Same >> with abusive use of of the respondsTo: family. Though if this family >> wasn't worthwhile, it wouldn't be in the system at all. Polymorphism >> is great, but not always the most applicable approach in all >> contexts. >> Why does there have to be such a religious fervor of any of these? >> >> -- >> Travis Griggs >> Objologist >> "The best way to know you have a mind is to change it" -Judge Pierre >> Leval >> > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Spam: #isAxxx vs #respondsTo: vs isKindOf:
|
|
> -----Original Message----- > From: Anthony Lander [mailto:[hidden email]] > Sent: Thursday, July 09, 2009 8:51 AM > To: Terry Raymond > Cc: 'VWNC' > Subject: Re: [vwnc] Spam: #isAxxx vs #respondsTo: vs isKindOf: > > Terry, et al: > > This allows the VM to decide which messages to send through its > polymorphic message send lookup mechanism, rather than the programmer > making the choices with "if" statements. In fact, I argue that OO > programming at its heart is exactly this: "If" statement elimination. I consider it to be a trade-off. Using just polymorphic sends reduces readability. When I am reading code that forces me to continually jump to another method just to read a few lines it breaks my thought continuity. Obviously, at some point I consider it more appropriate to delegate to the object. To me it is a conceptual chunking issue. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |