On Sun, Jun 7, 2015 at 7:54 PM, Francisco Garau <francisco.garau@gmail.com> wrote:
Hi Ben,
Thanks for your comments. There's another aspect of the syntax changes I am playing with. The intention is to make more evident the relationship between objects and closures as they could be implemented in terms of each other (see below article from Vassily on the subject).
http://live.exept.de/doc/online/english/programming/humor.html
I'm lost. It seems to me that Vassily's response is a contrived example to get rid of Objects. The url does indicate humour.
Your ideas below regarding method definition is interesting, but this class definition seems problematic.
[Point: Object | | x y |
I've removed passing the superclass as an argument, that was a mistake. Now a more complete example would be written as:
[Generator: initialValue | | currentValue | currentValue := initialValue. [reset | currentValue := 0 ]. [next | currentValue := currentValue + 1. ^currentValue]. reset category: 'accessing'. next category: 'accessing'. ]. myGen := Generator: 5.
It seems this is how you are creating an instance, and you would be constrained to have only one way to create an instance. How would you handle having two ways to create an instance. For example... Point class >> r:degrees: Point class >> x:y:
myGen next = 6. myGen reset = 0. myGen next = 1.
To highlight that the blocks defining the methods wouldn't be thrown away, I've added a couple of categorization methods.
When are these categorization methods executed? It seems that the "currentValue := initialValue" line might meant be executed each time an instance is created. In that case the two #category message sends would seem to also be sent at each instance creation ???
Notice how close is that from a valid implementation using plain blocks in regular Smalltalk. Almost identical if you ignore the method lookup resolution which is obviously missing from blocks.
Sorry its not obvious. I don't understand that last statement. What would this missing part look like? Maybe part of the problem is I can't help reading the above syntax as blocks, even if they are named blocks aka methods. Sorry its just how I'm wired, and I haven't even been doing Smalltalk long. I found the following example really hard to follow, and I could not do it just reading it. I had to evaluate it piecemeal and inspect each step. Would such a thing ever be used in practice? It strikes me as failing Brian Kernighan's rule: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." So I feel its not a good justification to replace this with your new syntax. Do you have another?
generatorClass := [:initialValue | | currentValue | currentValue := initialValue. Array with: [ currentValue := 0 ] with: [ currentValue := currentValue + 1 ]. ].
myGen := generatorClass value: 5. myGen last value = 6. myGen first value = 0. myGen last value = 1.