[vwnc] Testing sequencable types..
Locked
[vwnc] Testing sequencable types..
 
|
Hi all..
If I've got an argument to a function that can either be an array of #foo #bar #baz (e.g. #(#foo #bar #baz) like items or it can be a non-array like #foobar, is there a way to tell when I've got the array variant versus the non-array? I was hoping something like #isSequencable might help but both are apparently sequencable types.. Any ideas? Thx! _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Testing sequencable types..
|
|
Ok.. I found I can use #_type to query if its an array -- isn't there
a better way like having something like #isArray I can query it with? I didn't see anything like that but #_type would work if nothing else exists.. -- Rick On Aug 29, 2008, at 9:57 PM, Richard E. Flower wrote: > Hi all.. > > If I've got an argument to a function that can either be an array of > #foo #bar #baz > (e.g. #(#foo #bar #baz) like items or it can be a non-array like > #foobar, is there a > way to tell when I've got the array variant versus the non-array? I > was hoping > something like #isSequencable might help but both are apparently > sequencable > types.. Any ideas? vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Rick Flower
On Fri, Aug 29, 2008 at 9:57 PM, Richard E. Flower <[hidden email]> wrote: Hi all.. You could use arg isSequenceable and: [arg isCharacters not]. There might be a better way, but this one should work. Randy -- Randy Coulman [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Rick Flower
You could always extend by adding Array>>isArray ^true and Object>>isArray ^false. But often it is a warning sign that perhaps your api isn't quite right. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Randy Coulman
Thanks Boris & Randy --
I had considered the class extending but thought there might be a better way.. As it turns out, Randy's suggestion seems to work just fine.. I might refactor the code later to make it work a bit different but for now I'll chug on.. Thanks again! -- Rick On Aug 29, 2008, at 10:22 PM, Randy Coulman wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Rick Flower
On 30.08.2008, at 06:57, Richard E. Flower wrote: > Hi all.. > > If I've got an argument to a function that can either be an array of > #foo #bar #baz (e.g. #(#foo #bar #baz) like items or it can be a non- > array like > #foobar, is there a way to tell when I've got the array variant > versus the non-array? I > was hoping something like #isSequencable might help but both are > apparently > sequencable types.. Any ideas? The recommended way to handle this is a visitor pattern. Implement both variants properly separated: MyClass>>methodForArray: anArray MyClass>>methodForSymbol: aSymbol and one generic method: MyClass>>methodFor: anArgument ^anArgument methodArgumentTo: self and for either argument class: Array>>methodArgumentTo: aReceiver ^aReceiver methodForArray: self Symbol>>methodArgumentTo: aReceiver ^aReceiver methodForSymbol: self The good thing with visitor patterns is that you can extend them by adding more variants at any time without bloating a sinlge method with argument comparisons and lengthy code. In fact, your protocol becomes a nicely clean list of all "types" supported. All this only for the cost of a one-liner per supported class! HTH Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Rick Flower
Richard E. Flower wrote:
> Hi all.. > > If I've got an argument to a function that can either be an array of > #foo #bar #baz > (e.g. #(#foo #bar #baz) like items or it can be a non-array like > #foobar, is there a > way to tell when I've got the array variant versus the non-array? I > was hoping > something like #isSequencable might help but both are apparently > sequencable > types.. Any ideas? Hm, a thought from here: Does the method look like that? method: anArrayorOtherObject (anArrayorOtherObject isSequenceable and: [arg isCharacters not]) ifTrue:[do something] ifFalse:[do something else] To me, this always is a case of "lets split the method and have one for each case"; i.e. method1: anArray, method2: anObject. But then again, it is saturday morning and I might completely misunderstand. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Rick Flower
Two comments
1. I added a long time ago, "isListOf" to Collection returning true, then isListOf to String and Symbol returning "false". 2. someone some time ago suggested adding "do:" to Object Object>>do: aBlock aBlock eval: self that way you just treat the parameter as if it were an Array Richard E. Flower wrote: > Hi all.. > > If I've got an argument to a function that can either be an array of > #foo #bar #baz > (e.g. #(#foo #bar #baz) like items or it can be a non-array like > #foobar, is there a > way to tell when I've got the array variant versus the non-array? I > was hoping > something like #isSequencable might help but both are apparently > sequencable > types.. Any ideas? > > Thx! > > _______________________________________________ > 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 |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Rick Flower
Two comments
1. I added a long time ago, "isListOf" to Collection returning true, then added isListOf to String and Symbol returning "false". 2. someone some time ago suggested adding "do:" to Object Object>>do: aBlock aBlock eval: self that way you just treat the parameter as if it were an Array, but then that would not deal well with String or Symbol would it. Richard E. Flower wrote: > Hi all.. > > If I've got an argument to a function that can either be an array of > #foo #bar #baz > (e.g. #(#foo #bar #baz) like items or it can be a non-array like > #foobar, is there a > way to tell when I've got the array variant versus the non-array? I > was hoping > something like #isSequencable might help but both are apparently > sequencable > types.. Any ideas? > > Thx! > > _______________________________________________ > 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 |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Andre Schnoor
Andre Schnoor wrote:
> The good thing with visitor patterns is that you can extend them by > adding more variants at any time without bloating a sinlge method with > argument comparisons and lengthy code. In fact, your protocol becomes > a nicely clean list of all "types" supported. All this only for the > cost of a one-liner per supported class! > This needs to be qualified: the above is true if visitor and visitee are (conceptually) in the same project. If you have several different projects that each define a visitor for the same visitee set you have created a dependency on the types of visitees. Adding a visitee type will force you to update the visitors of all the dependent projects. (Adding visitors does not show this dependency problem.) I'm pretty sure this is mentioned in The Design Patterns Smalltalk Companion (but am to lazy to verify that). R - _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Testing sequencable types..
|
|
In reply to this post by Andre Schnoor
Also, this methodology has two additional advantages. First, you can
track down the shape of the pattern via implementors / senders, something that is more difficult to do with vanilla selectors such as isSequenceable. The second advantage is that this code style tends to run faster as well because the ifTrue:/ifFalse:/etc messages are effectively replaced by a couple assembler instructions in a polymorphic inline cache. Andres. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Andre Schnoor Sent: Saturday, August 30, 2008 1:18 AM To: Richard E. Flower Cc: VWNC List Subject: Re: [vwnc] Testing sequencable types.. On 30.08.2008, at 06:57, Richard E. Flower wrote: > Hi all.. > > If I've got an argument to a function that can either be an array of > #foo #bar #baz (e.g. #(#foo #bar #baz) like items or it can be a non- > array like #foobar, is there a way to tell when I've got the array > variant versus the non-array? I was hoping something like > #isSequencable might help but both are apparently sequencable types.. > Any ideas? The recommended way to handle this is a visitor pattern. Implement both variants properly separated: MyClass>>methodForArray: anArray MyClass>>methodForSymbol: aSymbol and one generic method: MyClass>>methodFor: anArgument ^anArgument methodArgumentTo: self and for either argument class: Array>>methodArgumentTo: aReceiver ^aReceiver methodForArray: self Symbol>>methodArgumentTo: aReceiver ^aReceiver methodForSymbol: self The good thing with visitor patterns is that you can extend them by adding more variants at any time without bloating a sinlge method with argument comparisons and lengthy code. In fact, your protocol becomes a nicely clean list of all "types" supported. All this only for the cost of a one-liner per supported class! HTH Andre _______________________________________________ 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 |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |