strange idea about slots
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. cheers -ben
Slots only drive access to the instance variables and the association "literal" is already a message send. But I guess you wold be able to do such behavior with own Opal plugin. -- Pavel 2017-03-01 15:56 GMT+01:00 Ben Coman <btc@openinworld.com>:
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.
cheers -ben
On Wed, Mar 1, 2017 at 3:56 PM, Ben Coman <btc@openinworld.com> 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.
For this you can do it by manipulating the stack in #substitute: . Are x and y temporary variables or instance variables ? You could look-up in the context's sender method AST what they are and do something accordingly.
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 this you need parser extensions as this is not valid Smalltalk. 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.
You mean like tuples in Python ? To cover all your use-cases, the best is to change the bytecode compilation pipeline. If you need to extend the Syntax, you need to use Opal with an extended Parser (Typically a subclass of RBParser you write). Then the easiest is to transform the AST from your extended parser (or the default AST if you don't extend the syntax) to standard Smalltalk AST doing what you want before the semantic analysis and feed it to Opal. You can do something manually or something with RBParseTreeRewriter :-). In the cases you show it is enough to generate what you want. Ah yeah, modifying the syntax or modifying the expected behavior of a syntax is often considered as a bad practice or evil.
cheers -ben
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.
participants (4)
-
Ben Coman -
Clément Bera -
Pavel Krivanek -
Richard Sargent