Sam Ruby <[EMAIL PROTECTED]> wrote:
> General thoughts on the proposal to replace VTABLES with methods:

> 1) Anything that is unary (i.e., contains exactly or one argument) is
> not affected by MMD.

That's not quite true. We currently have just infix MMD dispatching on
left and right. That's just a specialized version. S13 has e.g.

  multi method prefix:<+> ...
  multi method prefix:<~> ...

when I translate that it boils down to:

  obj."__get_number"()
  obj."__get_string"()

(But there isn't much "multi" on such dispatch, that's right ;)

Anyway the current (2-dim) MMD system is really static. Overriding one
operator doesn't effect any class that inherits from it.

> ... There is no need to replace any such methods.

I haven't stated to get rid of these vtables. I've said that for
function dispatch these should be equivalent for plain PMCs and objects.
While we support above methods aready, we have an extra meta-class
(delegate) to dispatch correctly to the overloaded operator.

> 2) While I don't see Python translators using a "sin" opcode, I can see
> the implementation of Math.sin doing a VTABLE_sin(INTERP,value).

Well, a vtable is a static construct. Having VTABLE_sin (and others)
forces all 100 (or whatever) PMCs and objects to have a vtable slot for
it.

> 3) My biggest problem with the runtime introducing methods is that
> language semantics vary.  Here's a concrete example: both Ruby and
> Python have methods named "index" on string.  Ruby returns C<nil> if not
> found.  Python throws C<value_error> if not found.

Fine. We have e.g. PyString isa String and RbString isa String.

  METHOD index() {                METHOD index() {
    res = SUPER()                   res = SUPER()
    if (res < 0)                    if (res < 0)
      raise ...                       return RbNil

This is exactly what methods are for.

> String."replace" may be an even better example.  Ruby and Python's
> methods by this name don't mean the same thing or even have the same
> signature.

Doesn't really matter.

> Overall, for any non-trivial method, I think we are looking at a double
> dispatch: first to the language specific "wrapper"

Mehods can call each other and parent methods.

> ...  There are advantages and disadvantages to
> making the dispatch methods the same.

Why?

> ... Ultimately, if they are the same,
> the names should be picked in a way that minimizes the possibility of
> collisions.  If they differ, no such possibility exists.

Why? Px."foo"() and Py."foo"() can be totally different things, if the
classes of Px and Py differ.

> - Sam Ruby

leo

Reply via email to