> I wrote:

>> So to get back to the idea of standardization, I like the idea of
>> low-level primitives on which anybody can build their own syntax. vtable
>> and Smalltalk-style method dispatch are fundamentally different
>> semantically, and as we've seen in this discussion there are plenty of
>> valid uses for both.  So we probably need to provide primitives for
>> both.  I don't know whether there should be optional sets of primitives
>> depending on the kind of dispatch, or whether the standard should simply
>> lump all of them into a "Base OO wordset".  I'd prefer the latter, myself.

>

>> Another question is class-based or prototype-based OO.  I'm most
>> comfortable with class-based myself, but I'm sure there are some avid
>> prototype people around.  The worrying thing is that again the semantics
>> are so different we're faced with including both of them.  But I'm less
>> comfortable with that than with method dispatching.  I'd like to think
>> about ways we could standardize specifying classes, maybe with
>> structures as a starting point?

>

>> This is all just off the top of my head, but I think it would be good to
>> try thinking about what primitives we could come up with that would be
>> capable of implementing all the common OO paradigms that are in use.

>
> Nobody's replied yet (maybe everyone's kill-filed the OO syntax thread?)
> so I'm renaming the topic and going to do some rambling about possible
> standardizable primitives.  Let me state categorically that this is just
> rambling at this stage.  I have no experience in formally proposing
> words for a standard, and as we're going on holiday fairly soon I don't
> have much time anyway.  I just want to throw around some initial ideas
> and hope that a profitable discussion might follow.
>
> I'll start with method invocation since I've got to start somewhere.
>
> Messages need to be sent to objects, so we seem to need something like
>
> SEND  ( ^obj selector -- ?? )
>
> which takes the address of an object and *something* representing a
> selector.  I don't care what it is.  This word invokes a method and
> returns whatever the method returns.  The stack order of parameters
> isn't important.
>
> Now this can be decomposed into binding, and execution.  So we need
> something like
>
> BIND  ( ^obj selector -- xt )
>
> which takes the object address and selector and returns the xt of the
> method to be invoked.  Then we can have
>
> EXECUTE-METHOD  ( ^obj xt -- ?? )
>
> which takes the xt we got from BIND, and invokes the method.  Notice we
> don't simply use EXECUTE since the method, when running, needs the base
> address of the object somewhere (hopefully in a register but that's an
> implementation detail).  I suppose EXECUTE could be made clever enough
> to realize that it's a method we're calling, but it seems more
> straightforward to just specify EXECUTE-METHOD and let the compiler
> decide how best to implement it.
>
> So now, conceptually, we can have
> 
> : SEND  ( ^obj selector -- ?? )
>         over swap bind  execute-method  ;
>
> Now BIND probably isn't good enough, since there are different kinds of
> bindings.  I'm familiar with three, and we're going to hit a terminology
> problem.
>
> 1.  Early binding.  This is OK - I think everybody understands what this
> means.
>
> 2.  vtable binding.  Also called "late binding" by some.  This requires
> the method name to be already declared in the class, though the binding
> can be to a subclass that hasn't yet been declared at the time the
> binding is done.  I prefer to call this vtable-binding to distinguish it
> from 3. below.
>
> 3.  Smalltalk-style late binding.  Commonly this uses a hashed selector
> which is resolved at run time.  The method need not be already declared
> anywhere when the binding is done.
>
> So I think BIND actually needs to be three words, though I'm not sure
> what to call them.  Let me, for now, call them
>
> EARLY-BIND
> VTABLE-BIND
> LATE-BIND
>
> OK, I'll leave it there for now -- comments, anyone?
>
> Cheers,  Mike.
>
> ---------------------------------------------------------------
>       Mike Hore     mike_hore...@OVE.invalid.aapt.net.au
> ---------------------------------------------------------------
> ** Posted fromhttp://www.teranews.com**