I agree that having Scenario extend SomethingScenario is weird, but still it's somehow pleasing. Like jam with cheese.
My thinking is, if I don't care and I'm always going to use the default setup, then all I care about is having a Scenario. Like if I want to rent a car, I just phone up and ask for a Car. It might be the default car (hence DefaultCar) which itself might be a Mazda. It might simply be the only car they have. Usually we represent this with an interface and a factory: Car anyOldCar = carHireShop.rentalCar(); but in this case we want to give people an actual class they can extend. Perhaps we've just stumbled on a new convention where the thing you want people to use (extend) most often is just called Thing (the "default" is implied), so there is nothing in its name to distract you from using it. It actually fits the Dreyfus learning model rather nicely. A novice just wants a Thing and some rules to make the thing work. Words like "Default" or "JUnit" are context - which the novice isn't ready for. Cheers, Dan 2008/9/26 Mauro Talevi <[EMAIL PROTECTED]> > Dan North wrote: > >> Ooh! I like the idea of leaving Scenario as the default abstract class, >> under JUnitScenario (so effectively it's just an alias for it). >> >> > Ok - so you're saying we should un-deprecate it as leave it as a default > alias? > > Not against an alias class, but perhaps I would name that alias > DefaultScenario (identical to what is now Scenario) - and leave Scenario > deprecated for 2.1+ (with the idea of eventually removing it). > > The main reason is that it's kinda odd to have a SomethingScenario be > implemented by Scenario - the convention goes the other way. > > WDYT? > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
