I have a class and need to find out whether an instance of the class
understands a method. Does anyone know how to do it without creating an instance of the class? Kind regards Runar _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
I would check implementors of #respondsTo:
>Stevenson, Dave (contr) <[hidden email]> 972-946-4890 -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Runar Jordahl Sent: Friday, March 27, 2009 8:32 AM To: VWNC List NC Subject: [vwnc] Finding out whether a class' instance understands a method I have a class and need to find out whether an instance of the class understands a method. Does anyone know how to do it without creating an instance of the class? Kind regards Runar _______________________________________________ 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 |
In reply to this post by Runar Jordahl
On Mar 27, 2009, at 6:31 AM, Runar Jordahl wrote: > I have a class and need to find out whether an instance of the class > understands a method. Does anyone know how to do it without creating > an instance of the class? aClass canUnderstand: #aSelector e.g. Point canUnderstand: #yourself --> true Point canUnderstand: #detect:ifNone: --> false -- Travis Griggs Objologist "Every institution finally perishes by an excess of its own first principle." - Lord Acton _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Stevenson, Dave (contr)
Runar Jordahl asked:
> I have a class and need to find out whether an instance of the class > understands a method. Does anyone know how to do it without creating > an instance of the class? aClass canUnderstand: #aMethodSymbol - The method should really be called "instancesCanUnderstand:" Steve _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Steven Kelly wrote: Or "instancesRespondTo:" to make it similar to the instance side "respondsTo:" ??Runar Jordahl asked:I have a class and need to find out whether an instance of the class understands a method. Does anyone know how to do it without creating an instance of the class?aClass canUnderstand: #aMethodSymbol - The method should really be called "instancesCanUnderstand:" I have always had to "go and look" to get "canUnderstand", because I can only remember "responds". Steve _______________________________________________ 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 |
> - The
method should really be called "instancesCanUnderstand:"
Or "instancesRespondTo:" to make it similar to the instance side "respondsTo:" ?? For a second I thought that it's easy enough to write a
new class method #respondsTo:
However, this would create a maintenance nightmare as VW
moves to a new version. So, maybe this should be left to
Cincom?
Guys?
Víctor
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
No, you don’t want to implement #respondsTo: on the class!
#respondsTo: is implemented in Object and answers whether the receiver can respond to the argument message. Classes inherit this behavior to answer whether they respond to a particular message. You don’t want to override this in Class to answer instance behavior, because then you can’t find out whether the class responds to something.
I like the idea of combining “respondsTo” and “canUnderstand” to similar names – so, using #instancesRespondTo: implemented in Behavior or ClassDescription answers whether instances of the receiver respond to the indicated selector. This, of course, now covers sending “instancesRespondTo:” to a metaclass to see whether the class can respond… Don’t you just love the complications and convolutions of self-referential systems?
Cheers!
From: [hidden email] [mailto:[hidden email]] On Behalf Of Victor
>
- The method should really be called "instancesCanUnderstand:" For a second I thought that it's easy enough to write a new class method #respondsTo: However, this would create a maintenance nightmare as VW moves to a new version. So, maybe this should be left to Cincom?
Guys?
Víctor
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Runar, if you can, use polymorphism... it's much easier,
faster, and easier to maintain than using respondsTo: or any of those
mechanisms. In its most rudimentary form, you'd have something like
this:
(someObject respondsTo: #blah) ifTrue: [someObject
something] ifFalse: [someObject somethingElse]
This transforms to
Object>>blah
^self somethingElse
ObjectThatUnderstoodBlahFromBefore>>blah
^self something
Therefore, the code above simplifies to
someObject blah
Each implementation of #blah takes care of the
receiver. The #respondsTo: stuff does not end up reimplementing what the
VM was designed to do. Also, it's easier to maintain because if you tag
every object that could receive #blah with an implementation of #blah, checking
implementors of #blah tells you all the objects that will be sent #blah at the
send site. This, without running any code.
With #respondsTo:, #isKindOf: and the like you only know
the objects that go through the send site which understand #blah. You do
not know all the others that do go through the send site but do not understand
#blah. One could think of nil, but is that really the only one? Why
not nil, the empty string and the empty array? This complicates matters
because it makes code unmaintainable. If the actions for #blah need to be
updated, which objects should now implement #blah when previously they
didn't? Using #isKindOf: is even worse because it flat out prohibits
polymorphism, and thus cuts flexibility away. To top it off, all this does
is to simulate what the VM would do. And, of course, doing this
work in the image is nowhere near as fast.
My 2 cents...
Andres. From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Friday, March 27, 2009 10:39 AM To: [hidden email]; [hidden email]; [hidden email] Cc: [hidden email] Subject: Re: [vwnc] Finding out whether a class'instance understands a method No, you dont want to implement #respondsTo: on the class!
#respondsTo: is implemented in Object and answers whether the receiver can respond to the argument message. Classes inherit this behavior to answer whether they respond to a particular message. You dont want to override this in Class to answer instance behavior, because then you cant find out whether the class responds to something.
I like the idea of combining respondsTo and canUnderstand to similar names so, using #instancesRespondTo: implemented in Behavior or ClassDescription answers whether instances of the receiver respond to the indicated selector. This, of course, now covers sending instancesRespondTo: to a metaclass to see whether the class can respond Dont you just love the complications and convolutions of self-referential systems?
Cheers!
From:
[hidden email] [mailto:[hidden email]] On Behalf Of Victor
>
- The method should really be called "instancesCanUnderstand:" For a second I thought that it's easy enough to write a new class method #respondsTo: However, this would create a maintenance nightmare as VW moves to a new version. So, maybe this should be left to Cincom?
Guys?
Víctor
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
For known situations this works nicely. However, we have an
application development framework which often
gets lists of "domain attributes" which it has to apply. Often you can assume they are correct, but there are times when you cannot assume that. I would shoot-on-sight an application level programmer who did it, but in lower level things you really need to at times. Its the fact that I do it so seldom that makes me forget "canUnderstand" ! Valloud, Andres wrote:
-- 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 |
Yeah... sometimes isKindOf: is actually "correct"...
for example, when dealing with exceptions, isKindOf: is more or less
natural. As you say though, I'd rather avoid getting shot on sight
:). From: [hidden email] [mailto:[hidden email]] On Behalf Of Dennis Smith Sent: Friday, March 27, 2009 11:06 AM Cc: VW NC Subject: Re: [vwnc] Finding out whether a class'instance understands a method gets lists of "domain attributes" which it has to apply. Often you can assume they are correct, but there are times when you cannot assume that. I would shoot-on-sight an application level programmer who did it, but in lower level things you really need to at times. Its the fact that I do it so seldom that makes me forget "canUnderstand" ! Valloud, Andres wrote:
-- 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 |
Valloud, Andres wrote: I have come close -- had one that wanted to assign a title to each business-level class in a hierarchy of about 5 or 6, had title (self isKindOf: XXclass) ifTrue: [^'...]. (self isKindOf: YYclass) ifTrue: [^'...]. ... Makes for a nice mess if you add a subclass :( -- AND its a ton more code!).
-- 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 |
Oh, and then...
title isKindOf: isKindOf: ...... ^'some default value' And then, one day, some customer reports seeing 'some default value'. Which class was that? Andres. Dennis Smith wrote: > > > Valloud, Andres wrote: >> Yeah... sometimes isKindOf: is actually "correct"... for example, >> when dealing with exceptions, isKindOf: is more or less natural. As >> you say though, I'd rather avoid getting shot on sight :). > I have come close -- had one that wanted to assign a title to each > business-level class in a hierarchy of about 5 or 6, had > title > (self isKindOf: XXclass) ifTrue: [^'...]. > (self isKindOf: YYclass) ifTrue: [^'...]. > ... > Makes for a nice mess if you add a subclass :( -- AND its a ton more > code!). > >> >> ------------------------------------------------------------------------ >> *From:* [hidden email] [mailto:[hidden email]] >> *On Behalf Of *Dennis Smith >> *Sent:* Friday, March 27, 2009 11:06 AM >> *Cc:* VW NC >> *Subject:* Re: [vwnc] Finding out whether a class'instance >> understands a method >> >> For known situations this works nicely. However, we have an >> application development framework which often >> gets lists of "domain attributes" which it has to apply. Often you >> can assume they are correct, but there are times >> when you cannot assume that. I would shoot-on-sight an application >> level programmer who did it, but >> in lower level things you really need to at times. Its the fact that >> I do it so seldom that makes me forget >> "canUnderstand" ! >> >> Valloud, Andres wrote: >>> Runar, if you can, use polymorphism... it's much easier, faster, and >>> easier to maintain than using respondsTo: or any of those >>> mechanisms. In its most rudimentary form, you'd have something like >>> this: >>> >>> (someObject respondsTo: #blah) ifTrue: [someObject something] >>> ifFalse: [someObject somethingElse] >>> >>> This transforms to >>> >>> Object>>blah >>> >>> ^self somethingElse >>> >>> >>> ObjectThatUnderstoodBlahFromBefore>>blah >>> >>> ^self something >>> >>> >>> Therefore, the code above simplifies to >>> >>> someObject blah >>> >>> >>> Each implementation of #blah takes care of the receiver. The >>> #respondsTo: stuff does not end up reimplementing what the VM was >>> designed to do. Also, it's easier to maintain because if you tag >>> every object that could receive #blah with an implementation of >>> #blah, checking implementors of #blah tells you all the objects that >>> will be sent #blah at the send site. This, without running any code. >>> >>> With #respondsTo:, #isKindOf: and the like you only know the objects >>> that go through the send site which understand #blah. You do not >>> know all the others that do go through the send site but do not >>> understand #blah. One could think of nil, but is that really the >>> only one? Why not nil, the empty string and the empty array? This >>> complicates matters because it makes code unmaintainable. If the >>> actions for #blah need to be updated, which objects should now >>> implement #blah when previously they didn't? Using #isKindOf: is >>> even worse because it flat out prohibits polymorphism, and thus cuts >>> flexibility away. To top it off, all this does is to simulate what >>> the VM would do. And, of course, doing this work in the image is >>> nowhere near as fast. >>> >>> My 2 cents... >>> >>> Andres. >>> >>> ------------------------------------------------------------------------ >>> *From:* [hidden email] [mailto:[hidden email]] >>> *On Behalf Of *[hidden email] >>> *Sent:* Friday, March 27, 2009 10:39 AM >>> *To:* [hidden email]; [hidden email]; >>> [hidden email] >>> *Cc:* [hidden email] >>> *Subject:* Re: [vwnc] Finding out whether a class'instance >>> understands a method >>> >>> No, you don’t want to implement #respondsTo: on the class! >>> >>> >>> >>> #respondsTo: is implemented in Object and answers whether the >>> receiver can respond to the argument message. Classes inherit this >>> behavior to answer whether /they/ respond to a particular message. >>> You don’t want to override this in Class to answer instance >>> behavior, because then you can’t find out whether the class responds >>> to something. >>> >>> >>> >>> I like the idea of combining “respondsTo” and “canUnderstand” to >>> similar names – so, using #instancesRespondTo: implemented in >>> Behavior or ClassDescription answers whether instances of the >>> receiver respond to the indicated selector. This, of course, now >>> covers sending “instancesRespondTo:” to a metaclass to see whether >>> the class can respond… Don’t you just love the complications and >>> convolutions of self-referential systems? >>> >>> >>> >>> Cheers! >>> >>> >>> >>> Tom Hawker >>> >>> >>> >>> Senior Framework Developer >>> >>> Home >>> >>> >>> >>> +1 (408) 274-4128 >>> >>> >>> >>> *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 *Victor >>> *Sent:* Friday, March 27, 2009 8:46 AM >>> *To:* Dennis Smith; Steven Kelly >>> *Cc:* VWNC List NC >>> *Subject:* Re: [vwnc] Finding out whether a class' instance >>> understands a method >>> >>> >>> >>> > - The method should really be called "instancesCanUnderstand:" >>> Or "instancesRespondTo:" to make it similar to the instance side >>> "respondsTo:" ?? >>> >>> For a second I thought that it's easy enough to write a new class >>> method #respondsTo: >>> >>> However, this would create a maintenance nightmare as VW moves to a >>> new version. So, maybe this should be left to Cincom? >>> >>> >>> >>> Guys? >>> >>> >>> >>> Víctor >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> ----- Original Message ----- >>> >>> *From:* Dennis Smith <mailto:[hidden email]> >>> >>> *To:* Steven Kelly <mailto:[hidden email]> >>> >>> *Cc:* VWNC List NC <mailto:[hidden email]> >>> >>> *Sent:* Friday, March 27, 2009 11:19 AM >>> >>> *Subject:* Re: [vwnc] Finding out whether a class' instance >>> understands a method >>> >>> >>> >>> >>> >>> Steven Kelly wrote: >>> >>> Runar Jordahl asked: >>> >>> >>> >>>> I have a class and need to find out whether an instance of the class >>>> understands a method. Does anyone know how to do it without creating >>>> an instance of the class? >>>> >>> >>> >>> aClass canUnderstand: #aMethodSymbol >>> >>> - The method should really be called "instancesCanUnderstand:" >>> >>> >>> >>> Or "instancesRespondTo:" to make it similar to the instance side >>> "respondsTo:" ?? >>> I have always had to "go and look" to get "canUnderstand", >>> because I can only remember "responds". >>> >>> Steve >>> >>> >>> >>> _______________________________________________ >>> >>> vwnc mailing list >>> >>> [hidden email] <mailto:[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] <mailto:[hidden email]> >>> >>> Toronto, ON M2J 4Z8 sip:[hidden email] >>> >>> 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 >>> >>> 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 >>> >> >> -- >> 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 sip:[hidden email] >> 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 >> > > -- > 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 sip:[hidden email] > 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 |
Andres Valloud wrote: OR -- we got all of them with isKindOf, so we just drop off the end?Oh, and then... title isKindOf: isKindOf: ...... ^'some default value' No, didn't do that at least! And then, one day, some customer reports seeing 'some default value'. Which class was that? Andres. Dennis Smith wrote:Valloud, Andres wrote:Yeah... sometimes isKindOf: is actually "correct"... for example, when dealing with exceptions, isKindOf: is more or less natural. As you say though, I'd rather avoid getting shot on sight :).I have come close -- had one that wanted to assign a title to each business-level class in a hierarchy of about 5 or 6, had title (self isKindOf: XXclass) ifTrue: [^'...]. (self isKindOf: YYclass) ifTrue: [^'...]. ... Makes for a nice mess if you add a subclass :( -- AND its a ton more code!).------------------------------------------------------------------------ *From:* [hidden email] [[hidden email]] *On Behalf Of *Dennis Smith *Sent:* Friday, March 27, 2009 11:06 AM *Cc:* VW NC *Subject:* Re: [vwnc] Finding out whether a class'instance understands a method For known situations this works nicely. However, we have an application development framework which often gets lists of "domain attributes" which it has to apply. Often you can assume they are correct, but there are times when you cannot assume that. I would shoot-on-sight an application level programmer who did it, but in lower level things you really need to at times. Its the fact that I do it so seldom that makes me forget "canUnderstand" ! Valloud, Andres wrote:Runar, if you can, use polymorphism... it's much easier, faster, and easier to maintain than using respondsTo: or any of those mechanisms. In its most rudimentary form, you'd have something like this: (someObject respondsTo: #blah) ifTrue: [someObject something] ifFalse: [someObject somethingElse] This transforms to Object>>blah ^self somethingElse ObjectThatUnderstoodBlahFromBefore>>blah ^self something Therefore, the code above simplifies to someObject blah Each implementation of #blah takes care of the receiver. The #respondsTo: stuff does not end up reimplementing what the VM was designed to do. Also, it's easier to maintain because if you tag every object that could receive #blah with an implementation of #blah, checking implementors of #blah tells you all the objects that will be sent #blah at the send site. This, without running any code. With #respondsTo:, #isKindOf: and the like you only know the objects that go through the send site which understand #blah. You do not know all the others that do go through the send site but do not understand #blah. One could think of nil, but is that really the only one? Why not nil, the empty string and the empty array? This complicates matters because it makes code unmaintainable. If the actions for #blah need to be updated, which objects should now implement #blah when previously they didn't? Using #isKindOf: is even worse because it flat out prohibits polymorphism, and thus cuts flexibility away. To top it off, all this does is to simulate what the VM would do. And, of course, doing this work in the image is nowhere near as fast. My 2 cents... Andres. ------------------------------------------------------------------------ *From:* [hidden email] [[hidden email]] *On Behalf Of *[hidden email] *Sent:* Friday, March 27, 2009 10:39 AM *To:* [hidden email]; [hidden email]; [hidden email] *Cc:* [hidden email] *Subject:* Re: [vwnc] Finding out whether a class'instance understands a method No, you don’t want to implement #respondsTo: on the class! #respondsTo: is implemented in Object and answers whether the receiver can respond to the argument message. Classes inherit this behavior to answer whether /they/ respond to a particular message. You don’t want to override this in Class to answer instance behavior, because then you can’t find out whether the class responds to something. I like the idea of combining “respondsTo” and “canUnderstand” to similar names – so, using #instancesRespondTo: implemented in Behavior or ClassDescription answers whether instances of the receiver respond to the indicated selector. This, of course, now covers sending “instancesRespondTo:” to a metaclass to see whether the class can respond… Don’t you just love the complications and convolutions of self-referential systems? Cheers! Tom Hawker Senior Framework Developer Home +1 (408) 274-4128 *The Environment:* */We take it personally/* Office +1 (408) 576-6591 Mobile +1 (408) 835-3643 ------------------------------------------------------------------------ *From:* [hidden email] [[hidden email]] *On Behalf Of *Victor *Sent:* Friday, March 27, 2009 8:46 AM *To:* Dennis Smith; Steven Kelly *Cc:* VWNC List NC *Subject:* Re: [vwnc] Finding out whether a class' instance understands a method- The method should really be called "instancesCanUnderstand:"Or "instancesRespondTo:" to make it similar to the instance side "respondsTo:" ?? For a second I thought that it's easy enough to write a new class method #respondsTo: However, this would create a maintenance nightmare as VW moves to a new version. So, maybe this should be left to Cincom? Guys? Víctor ------------------------------------------------------------------------ ----- Original Message ----- *From:* Dennis Smith [hidden email] *To:* Steven Kelly [hidden email] *Cc:* VWNC List NC [hidden email] *Sent:* Friday, March 27, 2009 11:19 AM *Subject:* Re: [vwnc] Finding out whether a class' instance understands a method Steven Kelly wrote: Runar Jordahl asked:I have a class and need to find out whether an instance of the class understands a method. Does anyone know how to do it without creating an instance of the class?aClass canUnderstand: #aMethodSymbol - The method should really be called "instancesCanUnderstand:" Or "instancesRespondTo:" to make it similar to the instance side "respondsTo:" ?? I have always had to "go and look" to get "canUnderstand", because I can only remember "responds". Steve _______________________________________________ vwnc mailing list [hidden email] [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] [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 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-- 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-- 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 -- 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 |
Gotta love this stuff :)...
title isKindOf: isKindOf: ^self So what's the title of a window? A domain model... Andres. Dennis Smith wrote: > > > Andres Valloud wrote: >> Oh, and then... >> >> title >> isKindOf: >> isKindOf: >> ...... >> ^'some default value' >> > OR -- we got all of them with isKindOf, so we just drop off the end? > No, didn't do that at least! >> And then, one day, some customer reports seeing 'some default value'. >> Which class was that? >> >> Andres. >> >> >> Dennis Smith wrote: >> >>> Valloud, Andres wrote: >>> >>>> Yeah... sometimes isKindOf: is actually "correct"... for example, >>>> when dealing with exceptions, isKindOf: is more or less natural. As >>>> you say though, I'd rather avoid getting shot on sight :). >>>> >>> I have come close -- had one that wanted to assign a title to each >>> business-level class in a hierarchy of about 5 or 6, had >>> title >>> (self isKindOf: XXclass) ifTrue: [^'...]. >>> (self isKindOf: YYclass) ifTrue: [^'...]. >>> ... >>> Makes for a nice mess if you add a subclass :( -- AND its a ton more >>> code!). >>> >>> >>>> ------------------------------------------------------------------------ >>>> *From:* [hidden email] [mailto:[hidden email]] >>>> *On Behalf Of *Dennis Smith >>>> *Sent:* Friday, March 27, 2009 11:06 AM >>>> *Cc:* VW NC >>>> *Subject:* Re: [vwnc] Finding out whether a class'instance >>>> understands a method >>>> >>>> For known situations this works nicely. However, we have an >>>> application development framework which often >>>> gets lists of "domain attributes" which it has to apply. Often you >>>> can assume they are correct, but there are times >>>> when you cannot assume that. I would shoot-on-sight an application >>>> level programmer who did it, but >>>> in lower level things you really need to at times. Its the fact that >>>> I do it so seldom that makes me forget >>>> "canUnderstand" ! >>>> >>>> Valloud, Andres wrote: >>>> >>>>> Runar, if you can, use polymorphism... it's much easier, faster, and >>>>> easier to maintain than using respondsTo: or any of those >>>>> mechanisms. In its most rudimentary form, you'd have something like >>>>> this: >>>>> >>>>> (someObject respondsTo: #blah) ifTrue: [someObject something] >>>>> ifFalse: [someObject somethingElse] >>>>> >>>>> This transforms to >>>>> >>>>> Object>>blah >>>>> >>>>> ^self somethingElse >>>>> >>>>> >>>>> ObjectThatUnderstoodBlahFromBefore>>blah >>>>> >>>>> ^self something >>>>> >>>>> >>>>> Therefore, the code above simplifies to >>>>> >>>>> someObject blah >>>>> >>>>> >>>>> Each implementation of #blah takes care of the receiver. The >>>>> #respondsTo: stuff does not end up reimplementing what the VM was >>>>> designed to do. Also, it's easier to maintain because if you tag >>>>> every object that could receive #blah with an implementation of >>>>> #blah, checking implementors of #blah tells you all the objects that >>>>> will be sent #blah at the send site. This, without running any code. >>>>> >>>>> With #respondsTo:, #isKindOf: and the like you only know the objects >>>>> that go through the send site which understand #blah. You do not >>>>> know all the others that do go through the send site but do not >>>>> understand #blah. One could think of nil, but is that really the >>>>> only one? Why not nil, the empty string and the empty array? This >>>>> complicates matters because it makes code unmaintainable. If the >>>>> actions for #blah need to be updated, which objects should now >>>>> implement #blah when previously they didn't? Using #isKindOf: is >>>>> even worse because it flat out prohibits polymorphism, and thus cuts >>>>> flexibility away. To top it off, all this does is to simulate what >>>>> the VM would do. And, of course, doing this work in the image is >>>>> nowhere near as fast. >>>>> >>>>> My 2 cents... >>>>> >>>>> Andres. >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* [hidden email] [mailto:[hidden email]] >>>>> *On Behalf Of *[hidden email] >>>>> *Sent:* Friday, March 27, 2009 10:39 AM >>>>> *To:* [hidden email]; [hidden email]; >>>>> [hidden email] >>>>> *Cc:* [hidden email] >>>>> *Subject:* Re: [vwnc] Finding out whether a class'instance >>>>> understands a method >>>>> >>>>> No, you don’t want to implement #respondsTo: on the class! >>>>> >>>>> >>>>> >>>>> #respondsTo: is implemented in Object and answers whether the >>>>> receiver can respond to the argument message. Classes inherit this >>>>> behavior to answer whether /they/ respond to a particular message. >>>>> You don’t want to override this in Class to answer instance >>>>> behavior, because then you can’t find out whether the class responds >>>>> to something. >>>>> >>>>> >>>>> >>>>> I like the idea of combining “respondsTo” and “canUnderstand” to >>>>> similar names – so, using #instancesRespondTo: implemented in >>>>> Behavior or ClassDescription answers whether instances of the >>>>> receiver respond to the indicated selector. This, of course, now >>>>> covers sending “instancesRespondTo:” to a metaclass to see whether >>>>> the class can respond… Don’t you just love the complications and >>>>> convolutions of self-referential systems? >>>>> >>>>> >>>>> >>>>> Cheers! >>>>> >>>>> >>>>> >>>>> Tom Hawker >>>>> >>>>> >>>>> >>>>> Senior Framework Developer >>>>> >>>>> Home >>>>> >>>>> >>>>> >>>>> +1 (408) 274-4128 >>>>> >>>>> >>>>> >>>>> *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 *Victor >>>>> *Sent:* Friday, March 27, 2009 8:46 AM >>>>> *To:* Dennis Smith; Steven Kelly >>>>> *Cc:* VWNC List NC >>>>> *Subject:* Re: [vwnc] Finding out whether a class' instance >>>>> understands a method >>>>> >>>>> >>>>> >>>>> >>>>>> - The method should really be called "instancesCanUnderstand:" >>>>>> >>>>> Or "instancesRespondTo:" to make it similar to the instance side >>>>> "respondsTo:" ?? >>>>> >>>>> For a second I thought that it's easy enough to write a new class >>>>> method #respondsTo: >>>>> >>>>> However, this would create a maintenance nightmare as VW moves to a >>>>> new version. So, maybe this should be left to Cincom? >>>>> >>>>> >>>>> >>>>> Guys? >>>>> >>>>> >>>>> >>>>> Víctor >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> >>>>> *From:* Dennis Smith <mailto:[hidden email]> >>>>> >>>>> *To:* Steven Kelly <mailto:[hidden email]> >>>>> >>>>> *Cc:* VWNC List NC <mailto:[hidden email]> >>>>> >>>>> *Sent:* Friday, March 27, 2009 11:19 AM >>>>> >>>>> *Subject:* Re: [vwnc] Finding out whether a class' instance >>>>> understands a method >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Steven Kelly wrote: >>>>> >>>>> Runar Jordahl asked: >>>>> >>>>> >>>>> >>>>> >>>>>> I have a class and need to find out whether an instance of the class >>>>>> understands a method. Does anyone know how to do it without creating >>>>>> an instance of the class? >>>>>> >>>>>> >>>>> >>>>> >>>>> aClass canUnderstand: #aMethodSymbol >>>>> >>>>> - The method should really be called "instancesCanUnderstand:" >>>>> >>>>> >>>>> >>>>> Or "instancesRespondTo:" to make it similar to the instance side >>>>> "respondsTo:" ?? >>>>> I have always had to "go and look" to get "canUnderstand", >>>>> because I can only remember "responds". >>>>> >>>>> Steve >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> vwnc mailing list >>>>> >>>>> [hidden email] <mailto:[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] <mailto:[hidden email]> >>>>> >>>>> Toronto, ON M2J 4Z8 sip:[hidden email] >>>>> >>>>> 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 >>>>> >>>>> 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 >>>>> >>>>> >>>> -- >>>> 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 sip:[hidden email] >>>> 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 >>>> >>>> >>> -- >>> 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 sip:[hidden email] >>> 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 >> > > -- > 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 sip:[hidden email] > 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 |
Free forum by Nabble | Edit this page |