find_method changes and proposals

[Patrick R. Michaud]

On Sun, Feb 28, 2010 at 10:40:29AM -0500, Andrew Whitworth wrote:
> I've created a branch to do a little bit of refactoring of the
> find_method VTABLEs in Object and Class. The branch is
> find_method_object. As the primary part of this work, I am trying to
> move most of the logic from Object.find_find into Class instead. Since
> I could not add a find_method VTABLE on Class (without losing the
> ability to access the METHODs defined on Class itself), I moved most
> of the logic into Class.get_pmc_keyed_str, which was not used for any
> other purpose.

It sounds to me as though you're changing the meaning of find_method
on Class PMCs, so that it locates methods for its objects as opposed
to finding methods on the Class PMC itself.

If so, I fundamentally disagree with this proposed change.  Class PMCs
are objects the same as any other, and they should be able to have
their own methods that can be located using the find_method VTABLE,
the same as with other objects.  There may be a model in which
find_method on class objects returns the methods of its instances,
but Parrot has several times in the past explicitly rejected that model.

Overloading get_pmc_keyed_str for the purpose of looking up class
methods also feels wrong.  Granted the vtable might not be used 
for any other purpose, but re-using it this way means that Class 
PMCs will begin to respond to a hash interface where presently 
they do not.  In general, I think that re-using existing
vtables for things "because they're not being used for any other
purpose" is fundamentally wrong.  That's how we've ended up
with problems with assignment versus binding, set_addr/get_addr 
having multiple meanings, etc.

If I'm completely misreading the proposal, then I apologize for
this message and hope you can clarify.

Pm