RE: Objects, finally (try 1) [x-adr][x-bayes]

[Dan Sugalski]

At 11:44 AM -0600 1/15/03, Garrett Goebel wrote:

From: attriel [mailto:[EMAIL PROTECTED]]


   I think what Jonathan asked for was an operator for
   returning a method (as an object) which can be invoked
   later with some arguments (or even applied with a
   partial list of arguments for currying).
   
   This would be a lot more useful than a yes-or-no
   answer about the existence of a method.
 
  Exactly. 'Yes' might be valid one moment, and invalid the
  next. Not a very useful operation... Returning a coderef
  on the other hand is useful.

 Er.  How could Is it possible to call this method become
 invalid, but the fptr remains valid?  I'm not sure that I
 follow that ...


Perhaps I'm misunderstanding Dan's meaning when he talks of invalidating
method handles.


Yep. (Horse, meet stick. Stick, meet horse. Prepare to be thumped again)

I'm not talking about user-level code. I had originally figured that 
would just walk through the symbol tables and inheritance trees and 
find the method there and grab it, with no vtable involvement at 
all--code of the form:

  $foo = Bar-can(baz);

doesn't really involve parrot's method code at all. (Or so I thought, 
though I'm coming to think differently, as even that will need to be 
delegated to the objects at some point)

I've been concerned with cases like:

  foo-bar
  foo-bar
  foo-bar

where the compiler would be getting foo's bar method once, sticking 
it into a PMC reg, and invoking it three times. Which would be very 
wrong, as that handle would be potentially really wrong after the 
first use. (Heck, finding it could potentially invalidate it, making 
the first use wrong)

The common case for method handles, if they work, is as a 
shortcut/optimziation for the compiler, not for user code use, so 
that's what I'm most concerned with.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

RE: Objects, finally (try 1) [x-adr][x-bayes]

[Garrett Goebel]

From: attriel [mailto:[EMAIL PROTECTED]]
 
   I think what Jonathan asked for was an operator for
   returning a method (as an object) which can be invoked
   later with some arguments (or even applied with a
   partial list of arguments for currying).
   
   This would be a lot more useful than a yes-or-no
   answer about the existence of a method.
 
  Exactly. 'Yes' might be valid one moment, and invalid the 
  next. Not a very useful operation... Returning a coderef
  on the other hand is useful.
 
 Er.  How could Is it possible to call this method become 
 invalid, but the fptr remains valid?  I'm not sure that I
 follow that ...

Perhaps I'm misunderstanding Dan's meaning when he talks of invalidating
method handles. In Perl5:

package Foo;
sub bar { print hello world\n }
package main;
my $cref = Foo-can('bar');
undef *Foo::bar;
Foo-$cref();
Foo-bar();
1;

would result in:

hello world
Can't locate object method bar via package Foo (perhaps you forgot to
load 
Foo?) at [...] line 7.

As you can see, this is something you can do this in Perl5. And as Perl6 is
supposed to be able to run Perl5... I'd think this'd be something parrot'd
be required to support.


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]