Okay, I've lost any free time I might have and the discussion's gotten to the point where it's obvious that we're not going to get anywhere. So, this is what we're going to do:

1) The changes I proposed are going in. We get arg counts for I/S/N registers if they're used. Everyone can cope. (You may, if you choose, whine about it for a bit--that's OK, if somewhat unbecoming)

2) I'm adding in an alternate, link-time, non-overridable subroutine call sequence. This is for routines which may not change in any way at runtime. They may or may not be sub-PMC based. Probably not. This will cause some issues with perl/python/ruby code that would choose to manipulate the subs, but there are ways around it, and people can cope.

3) We're going to add some metadata (virtually to start) to note library versions, sub signatures, and whatnot so we've some chance of catching signature errors (which usually indicate a deeper versioning problem) at link and, hopefully, runtime.


Not much more to say about #1 than "I disagree", and I think we've dealt with that problem.


#2 will introduce, I think, a:

call X, Y

op, where X is the start of the bytecode to call and Y is the bytecode segment header, or something like that. *NOTE THAT THIS IS NOT SET IN STONE!* or mud even. I'm fine with a completely different format. Anyway, X and Y are resolved at link time which, for us, is bytecode load time. (Unless we bring in a linker. Maybe for V2)

Since these are essentially addresses which are resolved at link time there's no way that they can be overridden, which is arguably a Bad Thing. Certainly will get in the way of folks looking to do exactly that. Well... too bad. Wrap the non-overridable version in an overridable version and be done with it.

#3 is going to be important so we can have signatures that we can reliably mark as non-overridable (though I suppose just properties on the sub PMCs that the compiler can note is OK. Still, we need to define those), floor values for library versions so people can note breaks in compatibility, signatures on functions and subs, *versions* on subs and functions (potentially) all will be useful to make sure that we can, hopefully, have some chance of noting that things have changed.

Oh, and we need to make sure that the global stash that we're using to store subs checks function signatures when existing subs/methods/whatever are overridden, because we need to be able to pitch a fit if that's the case, even if we don't complain by default.
--
Dan


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

Reply via email to