[svn:parrot] r37222 - trunk/src/ops

[Reini Urban]

2009/3/9 Allison Randal <allison at parrot.org>:
> Reini Urban wrote:
>>
>> So since when are we in production? My understanding is that the first
>> production release starts with 1.0
>
> 1.0 is production.
>
>> With this change we lost now cross-version bytecode portability
>> and we will win the habit of randomly changing ops and pmc numbers
>> as before.
>>
>> The pbc designers thought about that long and hard, and set a date
>> when these random changes should stop and should be exchanged
>> about a support policy which should help keeping backwards portability.
>
> It's been a long time since anyone thought it was a good idea to freeze
> changes to the bytecode at some arbitrary point. Any feature where you tell
> users "we will never change the internal implementation or interface of X"
> means you can never improve that part of the project. Get enough of those,
> and your project dies.
>
> What we will do is make the bytecode changes respect the usual deprecation
> cycle.

I strongly believe you have no idea what the pbc idea was:

I'm not talking about bytecode format changes here.
The pbc format is fixed, even if 64bit got it wrong in the current padding code.

I'm talking about the internal freeze/thaw format and the ops, which
are indexed by number as in any bytecode format.

To make bytecode cross-version compatible, at least halfway, being
able to read old bytecode on a newer parrot, it will just require to
keep all the old indices and only add new ops/pmcs at the end. That's
a simple change in the renumbering tools and a bit of deprecation
discipline. This was the idea for years until some time ago. Until you
deleted that.

Since that confuses you (though are saying it confuses others) I'm a
bit puzzled that you feel qualified to make such bold statements about
confusion and throwing away portability at all. Rejecting tickets,
pulling out documentation and so on.

Maybe it would be better if someone who understood the idea of pbc portability
would do that. It's a big change you did, probably the biggest change
in perl6 history.

perl6-1.2 will not be able to read perl6-1.0 or pynie-1.0 or
parrot-1.0 pbc's, just single pirs. pbc was the fast, small and
portable container format for all. pbc was even the container for a
whole language.
Now it looks like another .pmc cripple from perl5. Nobody will use it,
because it's only valid for a month, up to the next PBC_COMPAT change.
Maybe think about that.
-- 
Reini Urban