Re: Keyword Arguments

First of all, thank you Kevin and Steve for this wonderful thread. It has been one of the best discussions I've seen on an emotional issue in a long time. 

A few observations:

1.) Steve is right - having done a lot of work with metamorphic objects which "type shift" via reparenting or altering their slots dynamically, ( cf. Plaid language for the concept http://www.cs.cmu.edu/~aldrich/plaid/ ) the entire notion of "type" in a language like IO is separate from identity, and as initialization via constructor should be considered harmful. Smalltalkers may be familiar with the limitations become: which don't apply to languages like io. 

2.) JIT is ad hoc by design, and a lot of work in Self had to do with backing out (deoptimization) of JIT to maximize overall performance. Type info as constraints do not ensure better performance, as they may require additional type conversions which can be more expensive than a naive interpreter.  Having written a few JIT implementations now, my anecdotal experience matches what the Self team published back in the 90s on dynamic deoptimization. 

3.) keyword arguments violate encapsulation if viewed as setting the internal state of the object. It is not the Object doing the internalization but an external compiler mucking with the internals of an object. As per point 1, this is untennable in a distributed environment where compilation may occur via proxy, and the underlying representations may be platform / architecture specific.  

4.) Steve's approach comes out of behavioralism of live objects.  By avoiding complicating the compiler (itself a live object with behavior) he can minimize the opportunities for static typers to write non-behavioral friendly code. It really avoids a conceptual model that violates the spirit of the language. 

Once again thank you to both of you for digging into this topic. 

Dave



-=-=- [email protected] -=-=-