Dan Sugalski <[EMAIL PROTECTED]> wrote: > ... It happens, in some cases a *lot*. This is perl, > python, and ruby we're talking about, where changing the definition of a > sub is as trivial as a reference assignment into a global hash. It's easy, > people do it. Often, in some cases. (Heck, I've done it)
Its definitely simpler then changing libc, yes. So if its necessary, do die nicely instead of segfault, then I'm for a compile option, to be able to turn these tests off --cause-i-know-what-im-doing.
> Methods also cause significant headaches, since there are *no* signatures > available to the calling code, as there's no way for it to look up the > signature.
If there are prototypes - which could be optional - we could check at least at compile time.
>> e.g. version checking at program load.
> Which doesn't solve the problem.
No, doesn't solve. But param counts don't either. Both may help a bit.
Dan, I think we will still _need_ to support version based deprecation. Certainly situations will arise with the current scenario when libraries change in such a way that they don't even detect incompatibilities.
The easy situation is when argument counts change, but the hard situation is when semantics have changed. In that case we have to have some sort of version requirement in the bytecode.
-Melvin
