FWIW Suggestion (don't know how much suitable ... but ...) is to have a single Scheduler class and add a the other functionality by defining another interface (let's call it ISchedulerBehavior , JFTR) and delegate that behavior to components implementing that interface . Then you'll have classes like e.g. PluggableCalendarImplementation & ResourceUsage ... which , once enabled will make the system to behave as expected .
In general while dev-ing Trac plugins think of using aggregation rather than inheritance (there's a generic way to do that from an abstract OOP perspective, considering there are even programming languages that don't support inheritance e.g. Self ... plus programming models not supporting / encouraging it either e.g. COM, CORBA , ... ) . ;) Hope this might help . PS: CMIIW pls On 11/30/11, Chris Nelson <[email protected]> wrote: > On 11/30/2011 07:51 AM, 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. Making complex >> hierarchies of components that implement and override methods and data >> will be a painful development and maintenance experience. >> >> Trac can only guarantee that we call the component constructor >> (__init__()) and the rest must be up to you. ... >> >> "Try to avoid subclassing components" is the best advice, >> really... :-) > > I accept that fixing this now would inconvenience lots of developers and > I don't mind jumping through a hoop or two to do my own subclassing > rather than having it happen by magic but not using subclasses is going > to make my implementation very awkward. I have: > > * A SimpleScheduler - uses built-in assumptions 8-hour work days, > Monday-Friday > * A CalendarScheduler - Exactly like a SimpleScheduler except it uses > an extension point to access a pluggable calendar implementation > * A ResourceScheduler - Exactly like a CalendarScheduler except it > keeps track of resource usage > > If I can't do: > > class SimpleScheduler(Component): > ... > class CalendarSchduler(SimpleScheduler): > ... > class ResourceScheduler(CalendarSchduler): > ... > > then I have a *lot* of duplicate code in the classes. > > Is all I have to do: > > ... > class CalendarSchduler(SimpleScheduler): > def __init__(self): > # Pass self explicitly due to Component limitations > SimpleScheduler.__init__(self) > ... > > ? If so, I'm good. > > Chris > -- > Christopher Nelson, Software Engineering Manager > SIXNET - Solutions for Your Industrial Networking Challenges > 331 Ushers Road, Ballston Lake, NY 12019 > Tel: +1.518.877.5173, Fax: +1.518.877.8346 www.sixnet.com > > -- > You received this message because you are subscribed to the Google Groups > "Trac Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/trac-users?hl=en. > > -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
