On Jun 19, 2013, at 00:18 , Nathan Kurz <[email protected]> wrote: > 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.
Yes, the possibility that the first definition of a method could be moved to a parent class is the main reason why we need all those offset variables. But it's just an implementation detail. It would be nice to find a better solution, but the current approach doesn't pose any serious problems. > 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. I don't think that the uptake of Lucy has anything to do with complexity, actual or perceived. The critical factor, in my opinion, is that we only support Perl. I don't want to start a discussion about the future of Perl, but it's a fact that Perl usage is declining and that there are very few new projects written in Perl. The good thing is that our architecture has been designed to support multiple host languages via Clownfish. Supporting other languages like Python or Ruby still means a lot of work, but I think we have made some considerable progress in that area. > 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. My current focus is about making Clownfish a stand-alone and great product. And for Clownfish, solving the fragile ABI problem would be an incredibly important feature. You're right that there's not much direct benefit to Lucy. But the current work on Clownfish doesn't make contributing to Lucy any harder. Hacking on the Lucy core is as easy or as hard as it's been since the initial release. Since we have to document some of the Clownfish internals now, it will hopefully become even easier to get started. The only thing that will add some complexity for Clownfish users is the problem of ABI stability with regard to instance variables. But that's still in the planning stage. I agree that we shouldn't strive for perfection and release early but often. Even if the Lucy core is basically unchanged from 0.3, I'm looking forward to a 0.4 release. The C library might spark some interest and I'd love to see a stand-alone Clownfish release on CPAN. Nick
