Ovid wrote: > ----- Original Message ---- > >> From: Jon Lang <datawea...@gmail.com> > >> > Actually, I'd prefer to go much further than this: >> > >> > use Core 'MyCore'; >> > >> > And have that override core classes lexically. >> > >> > That solves the "but I want it MY way" issue that many Perl and Ruby >> programmers have, but they don't shoot anyone else in the foot. >> >> Since 'use' imports its elements into the current lexical scope, the >> version-based approach can do this. >> >> The only catch that I can think of has to do with derived classes: >> does the existence of a customized version of a class result in >> same-way-customized versions of the classes that are derived from the >> original class? That is, if I added an "updated" version of Foo, and >> Bar has previously been defined as being derived from Foo, would I get >> a default "updated version" of Bar as well? Or would I have to >> explicitly update each derived class to conform to the updated base >> class? > > > I'm not sure I understand you. If 'Bar' inherits from 'Foo' and 'Foo' has > extended the core Array class to lexically implement a .shuffle method, then > I would expect 'Bar' to have that also.
No, you don't understand me. The Foo/Bar example I was giving was independent of your example. Rephrasing in your terms, consider the possibility of a class that's derived from Array, for whatever reason; call it "Ring". Now you decide that you want to redefine Array to include a shuffle method, and so you implement an "Array version 2.0". Would you be given a "Ring version 2.0" that derives from Array version 2.0, or would you have to explicitly ask for it? As long as you limit your use of class inheritance, the above remains manageable. But consider something like the Tk widgets implemented as a class hierarchy; then consider what happens if you reversion one of the root widgets. If you manually have to reversion each and every widget derived from it, and each and every widget derived from those, and so on and so forth, in order for your changes to the root to propagate throughout the class hierarchy... Instead, I'd rather see an approach where you need only reversion the base class and those specific derived classes where problems would otherwise arise due to your changes. -- Jonathan "Dataweaver" Lang
