Ben Coman wrote
> I'm not sure I'm thinking straight, but I wonder...
> Can you put Slots inside an Association?
>
> For example, could have two slots x and y,
> and then be able to do the following...
>
> (x -> y) substitute: (1 -> 2).
> self assert: x equals: 1.
> self assert: y equals: 2.
>
> So the association method #substitute:
> assigns into the relevant variables.
>
> And even better if you could do...
> (x -> y) := (1 -> 2).
> and...
> { x. y ) := #(1 2).
>
> For example, when you're hacking fast and want to return two values from a
> method without mucking around with creating an object for this, it might
> look like...
> myCalc
> ^#(1 2)
>
> but instead of...
> result := inst myCalc.
> x := result at: 1.
> y := result at: 2.
>
> you could do...
> { x . y } := inst myCalc.
I see this often, and even practice it sometimes. :-(
But every time I think about it, I get frustrated. We have no problem
creating instances of an existing class (Array, Association, even
Dictionary) to return multiple values from a method.
However, I always feel like doing so abdicates our responsibilities. At
least with a Dictionary, the values are properly identified rather than
stuffed into an anonymous collection or mis-represented as key and value.
Ultimately, I always conclude that this anti-pattern indicates a modelling
failure. Why not create a class which does the computation, holds the
several desired result objects, and provides the ability to answer them?
Worst case, you have a simple computation that produces more than one result
object. In such a case, create a data transfer object (no real behaviour)
that holds the results in appropriately named instance variables.
There seems to be a fear of creating new classes. Don't let that rule your
designs.
> cheers -ben
--
View this message in context:
http://forum.world.st/strange-idea-about-slots-tp4936623p4936691.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
