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,
keith may I say that this is not productive to bash us systematically.
We did a report on Kernel Extensions and we will certainly harvest
some of
the extensions. Now if nobody beside me look at it, then it will end up
on my long stack and so far I'm quite busy.
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.
Overrides are still something that we should avoid as much as possible.
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!
True. Alex told me that he will have a look at your extensions.
So he will I'm sure.
Stef
regards
Keith
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
