Igor Stasenko wrote: > 2008/11/10 Stéphane Ducasse <[EMAIL PROTECTED]>: > >> Hi keith >> >> >>>>> We had Kerala loaded when we committed this SUnit version, but Kerala >>>>> >>>> overrides method in SUnit such as TestResult>>runCase:, so those >>>> methods didn't get committed. Very bad. >>>> >>> Not bad, typical, and you get used to it winding you up if you are an >>> MC1.0 user. So you have to adopt a strategy for maintaining each >>> package, such as maintainng an image specifically for each package that >>> you may have overrides in. >>> >>> So that is what MC1.5 was written for, to fix this bug! But people have >>> failed to see the need for it. >>> >>> Because many of you folks are package writers, rather than package >>> users/tweakers you don't find this problem an issue. But if the package >>> writer will not take on board requests for modifications what can you do. >>> >> You lost me. >> Could reexplained it to me> May be I'm just too tired too :) >> >> > > Let me elaborate. Suppose there is two persons A and B. > Both are using package C. > And both want to override some methods in package C to make their > packages working. > But author of package C refusing to include modifications of both persons. > Now, the only option they have is to ship their MC package each with > own overrides to original 'maintained' version of C, and hope that if > someone would want to load both A and B packages, their overrides will > not interfere with each other. > As an alternative users A and B can club together and make a package called C-extras, which avoids the problem of overrides clashing.
This is exactly the situation we have with Seaside, package maintainers refusing to add even simple accessors, so... Seaside28Jetsam was created as "Seaside-Extras". This is exactly the role of the Kernel-Extensions package (not that it includes many overrides). Several have turned their noses up at Kernel-Extensions because it includes things that they dont necessarily like, but in the process you are pooring scorn on a social process of collecting all extensions in a managed place where collisions can be avoided. Taking this on board... a package developer could recognise that perhaps they haven't got it all right and recognise a need to harness and guide such extras. Thus encouraging users of their package to collaborate in order to make the extras well documented and worthy of inclusion into future releases of the main package. Presently, the culture of "overrides are evil" is maintained because of the danger of clashes as Igor explained. But they dont have to be evil if they are managed in a social collaborative process which avoids such collisions, i.e. Seaside28Jetsam, and KernelExtensions. Those who write the packages can pronounce the doctrine of "overrides are evil", because they are not forced to use them, however those of us who want to actually. The solution for SUnit is for those who are interested in improving SUnit to actually TALK to others who have been already doing the same, and to collaborate on one such SUnit-improved rather than 10 separate ones! regards Keith _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
