osimons wrote: > Subclassing components is not an encouraged development pattern with > Trac. The one or two places where we subclass in Trac (like the > WikiMacroBase) the components are clearly marked as "abstract = True" > to ensure that responsibilities are clearly set.
The other place in core being the admin panels, again with an "abstract" base class. The other uses I remember are AccountManagerPlugin, which inherits from and extends LoginModule, and I have advised people to inherit from CommitTicketUpdater to extend its functionality. > Making complex > hierarchies of components that implement and override methods and data > will be a painful development and maintenance experience. There's actually nothing wrong with using inheritance with components, except for two things: - Only one component in a "branch" of inheritance should be enabled (i.e. you should never enable both parent and child). - Calling the base class constructor is awkward. I'm not even sure what the correct way to do that would be. > Trac components > are to a large extent a subclassing anti-pattern, and you should > organize your code to make each self-contained and having them call > each other instead of making a class tree of methods and data. I too have only rarely had a use for inheriting from components, but that doesn't mean it's an anti-pattern. Save for the two caveats above, it actually works fine. > And if > really needed you should implement your own init structure by using > other names for methods and data - like for instance checking for some > 'is_initialized' setting and calling own init() if not. That's one possibility, yes. Another one would be to provide a clean way to call the parent constructor. I was suggesting calling it automatically, but we could also have a super_init() function that calls the parent's constructor correctly (and bypasses the registration of the instance under the parent's class). > With lots of components and plugins already doing their own > __init__(), it would be quite dangerous if Trac should now change to > start traversing the hierarchy looking for __init__ calls to make. We > can risk double or erroneous calls to be made, perhaps depleting > scarce resources or overwriting data. I don't think so. We seem to agree that having inheritance between components is rare, and it's even more rare to have a constructor in both the parent and child (AFAIK this is the first time someone asked about it). So adding the automatic call to the parent constructor would only change the behavior in very rare cases. And we have always recommended the constructors to be mostly trivial (i.e. initialize attributes), so even in the rare case above, a double call would most probably have no ill effects. > "Try to avoid subclassing components" is the best advice, > really... :-) Heh, not convinced here :) -- Remy
signature.asc
Description: OpenPGP digital signature
