Smalltalk › Pharo › Pharo Smalltalk Developers

strange idea about slots

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Ben Coman

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

Pavel Krivanek-3

Re: strange idea about slots

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 <[hidden email]>:

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

Clément Béra

Re: strange idea about slots

In reply to this post by Ben Coman

On Wed, Mar 1, 2017 at 3:56 PM, Ben Coman <[hidden email]> 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

Richard Sargent

Re: strange idea about slots

Administrator

In reply to this post by Ben Coman

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