Re: VTABLE methods and interfaces

2005-04-16 Thread Kevin Tew
Sam, Just wondering what the status is on python/parrot/pirate/pyrate. These both look outdated. http://www.intertwingly.net/stories/2004/10/05/pyrate.zip http://pirate.versionhost.com/viewcvs.cgi/pirate/ Is there a up to date cvs repo? Can we get this code checked into the parrot svn repo? Kevin T

Re: VTABLE methods and interfaces

2005-02-24 Thread Leopold Toetsch
Sam Ruby <[EMAIL PROTECTED]> wrote: > As long as find_method itself can be overridden, this above is merely a > description of the default behavior, not a hard requirement. Yes, of course. C *is* overridable and, as all method lookup is calling C, the code can do whatever is needed. I'm describin

Re: VTABLE methods and interfaces

2005-02-23 Thread Sam Ruby
Leopold Toetsch wrote: 2) Vtable entries should be real methods All non-defaulted, non-inherited entries of a vtable interface should be available as methods, like now with the METHOD keyword. This allows eventually code like this: Px = Py."__pop_pmc"() or Px = Py."__string"()# $x =

VTABLE methods and interfaces

2005-02-23 Thread Leopold Toetsch
There was already some discussion about splitting the VTABLE structure into distinct pieces. I'd like to start that task after 0.1.2 is out. Here are some thoughts: 1) Vtable and interfaces The VTABLE structure provides common slots that every PMC must provide and optional parts that roughly cor