On 3 June 2015 at 02:16, Peter Uhnák <[email protected]> wrote: > But I would like them to be defined like this: >> >> [ inc: x | x + 1 ]. >> (inc: 3) = 4 >> >> [add: x to: y | x + y ]. >> (add: 3 to: 4) = 7. >> >> >> What do you think? Is it feasible? >> > > But you still need to have the block saved in a variable. You cannot > pollute global namespace with names of parameters within the block, >
The block would still be saved in a variable -- I see that happening behind the scenes. In other words, you would have something like this: [ inc: x | x + 1 ]. (inc: 3) = 4. inc class = BlockClosure [add: x to: y | x + y ]. (add: 3 to: 4) = 7. addto class = BlockClosure not to mention the fact that most blocks in the system have same parameter > names. > Now while the idea seems interesting; I cannot imagine how it would work > in practice. Imagine collection's "do:" method explicitly stating the name > of the argument, which would force me to name it in such and such way which > would actually impair the readability. > I don't see that problem, as anonymous blocks would remain the same as now. You will still have this: (1 to: 5) do: [ :x | x + 1 ] My extensions are syntactic sugar to store and evaluate a block. They wouldn't help in a case like this: Point class >> incBlock ^[: x | x + 1] b := Point incBlock. I am sure others will have different opinions. > > However if you want to try it out, you should apart from Opal have to look > also at AST-Core since you are changing syntax. > Thanks for the pointers. > > Also I am thinking that combination of variable name + named arguments > could perhaps be done purely with overriding doesNotUnderstand: method in > BlockClosure and calling value:value: internally. (Or even cull:cull:, but > form what I've heard that has some dire performance issues); this could > perhaps even solve my comment about enforced naming. > > Peter > >> >
