Reason for closure/method discrepancy?

victor_yurkovsky 7dreamer at usa.net
Wed Dec 19 14:29:58 UTC 2001


Can anyone justify closure treatment in self?  It would seem to be 
more in the spirit of self to merge closures with methods and perform 
a purely dynamic message lookup, that is search block 
locals/parameters, then follow parent slots (outer closures - and now 
deprecated 'methods').  This would have an interesting side effect of 
erasing the difference between closures, methods and objects - any of 
these could be stuck into a slot and sent at least a 'value' message.

A method implementation would become therefore just another object 
(with local, parameter and parent slots) which is sent a 'value' 
message by default, but can accept other messages!

  Then it is up to the programmer to decide whether to write 
a 'block' inside a 'method' (an anonymous closure), create a method 
(a named closure) or send messages to object or methods (that are 
also objects) interchangeably.

  As for the non-local return out of closures, is there a really good 
reason for it?  Why not return to the outer scope (other than perhaps 
a clumsier syntax)?

  Forgive my possible stupidity - I am stuck in x86 world and haven't 
been able to explore self personally.  I am amazed at the clarity of 
reasoning behind self, with this minor exception.  Perhaps someone 
can clarify this.




More information about the Self-interest mailing list