[EMAIL PROTECTED] wrote:
Leo --
[[ Caveat Reador: Extremely dynamic stuff is a pet issue of mine. Keep your favorite halide handy. ]]
The per-op approach makes fingerprinting obsolete, which is another reason I'm for it.
Yes partly, see below.
... Having major changes in opsfiles will invalidate PBCs, ase.g. a change from gcc 2.x to 3.x invalidates C++ object files.
I disagree that it is too expensive, but I expect it will require hard data to settle the matter. Since this is my pet issue, I expect you won't be surprised when I say invalidating PBC files isn't necessary, and therefore we shouldn't feel obligated to follow past practice in that regard.
So lets have a closer look:
- a new opcode emerges => put it into a new opsfile. Done.[1]
(in the next major release, it can go, where it belongs to)
- a opcode is obsoleted => you can't delete it anyway, so keep it, update docs.
- a opcode gets more or less or changed params => you are as out of luck with the old PBC as my approach is: invalidate PBC file.
So, I don't really see that much advantage for the dynamic solution. Or did I miss something?
[1] There is always a newops.ops, which get new opsen appended, and this has
to be referenced last, when such ops are used.
Regards, -- Gregor
leo
