On Wed, 2005-03-30 at 14:57, chromatic wrote:
> I certainly plan to continue to instrument code at runtime (and not just
> really slushy, partially slushy, and permafrost compile time).
That's FINE, and no one should stop you!
What I was referring to was only the items that an interface definition
would be concerned with (that is, those things which would invalidate
the compiler's assumptions).
An example follows.
Original code:
class X { method m(int $i) { say "Hello, world" } }
Valid string to eval:
q{class X { method m(int $i) { die "Goodbye, world" } }}
Invalid string to eval:
q{class X { method m(int $i) is rw($string) { say $string } }}
The latter changes the interface definition, and thus invalidates the
compiler's assumptions, but you can instrument the code all you like,
re-defining any darned thing you wish!
If you allow the interface definition to change, you're not optimizing
for the programmer. You're optimizing for the amount of time you spend
in the debugger. Failing to eval early because code would have changed
the interface (or type hierarchy) of your types will save thousands of
programmers everywhere much debugging time.
Like I said, if you allow run-time munging of the type interfaces, then
you can't tell if this is valid or invalid:
my X $a;
$a.m(1);
you have to allow it always, regardless of the definition of X. In fact,
you can NEVER reject ANY method or function invocation based on
signature, since it might change at run-time.
Is that really what you want?
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
