On Fri, Jun 14, 2013 at 4:37 PM, Marvin Humphrey <[email protected]> wrote: > It's always bugged me that our global OFFSET variables take up so much space.
To understand why we need an offset per method rather than an offset per class, I re-read some previous threads to remind myself how we got to where we are. I think the reason was to allow moving a public parent method to a grandparent class, and vice versa, without breaking binary compatibility for a compiled extension uses but does not override this method. If this is the primary reason, and if we want to reduce the number of offset variables, I think we should reconsider whether the benefit is worth the cost. 1) The uptake of Lucy has been slow. The complexity of our approach is one of the barriers. We're trying to make things perfect for extension developers, but possibly at the cost of scaring off developers. "It became necessary to destroy the village in order to save it." Anything that reduces the actual or perceived complexity would be good. 2) While we can currently re-order methods within a level and move them between levels, changing the name or type signature will still cause silent breakage. Allowing non-public methods to be added, removed, and tested is great, but there are other ways of achieving this. Would things have been worse over the last year if we lacked this limited flexibility? 3) I don't see anything wrong with occasionally breaking binary compatibility to fix mistakes, improve clarity, and clear out cruft. The chances of getting an API right the first time are slim. Rather than worrying that everything has to be perfect for eternity when declared public, it's comforting to know that there will be a time one can make improvements. I love the technical challenge of trying to solve the fragile base class problem, but I think Lucy should optimize for simplicity and performance rather than trying to cross the valley of complexity in pursuit of a perfect development environment. --nate
