[KCP] SystemChangeNotifications: Current state and some code

Daniel Vainsencher danielv at netvision.net.il
Thu Jul 24 19:55:38 UTC 2003


I don't think we are communicating very well. I am aware of everything
you mention. I am saying that I don't want authors to be always be shy,
sometimes they should "presume". 

I do agree that if a class is tailored, for example including many
implementation details that make its reuse impractical anyway, you're
right, it should avoid taking up useful name space.

But classes which do represent abstractions that are candidates for
reuse, should have names that indicate this.

And KCP stuff, planned as they are for inclusion in the image anyway,
are meant to be definitive - the solution is not to hide them in
prefixes, but to make sure they really do represent a useful
abstraction.

Consider that the purpose of a community is not just to avoid
interference - it is synergy. This requires us to look at one anothers
abstractions and fit them to our purposes, not just to be able to
conviniently ignore them.

Your suggestion is fine - it is a simple version of having real support
for namespaces. I for one think they solve a problem we don't yet really
have. Other than SocketStream which is defined by network rewrite and by
Comanche, I don't recall recent clash issues, and in that case I think
we'll end up with a common implementation, which is a better result than
having two competing ones. Since namespaces do complicate things a bit,
I think we should postpone it until it is more urgently needed.

Daniel

Chris Muller <afunkyobject at yahoo.com> wrote:
> Daniel Vainsencher wrote:
> 
> When I go looking for abstractions to reuse, I am less likely to reuse
> one that has a namespace prefix because it is "proclaiming" to be
> non-generic. So especially for classes that abstract something that may
> be widely useful, it is important to not discourage reuse in this way.
> 
> Thinking about KCP stuff that is going into the image, I think it should
> definitely not use "namespace" prefixes.
> 
> ======
> 
> I heartily disagree with this.  Actually, prefixes exist so that the package is
> friendly to other packages that may implement same-named classes and methods.
> 
> Hogging generic names without a prefix seems presumptious to me; the idea that
> I would dictate to you what a LargeCollection is supposed to be, how it's
> supposed to work, and how fast it's supposed to perform.  Once you get outside
> the realm of all but the most general-purpose functionality, people don't want
> "God" objects that "proclaim" to be the end-all, be-all solution to their
> needs.  Sometimes they need the behavior of a LargeCollection, sometimes they
> want a MagmaCollection, and sometimes they want both in the same image to do
> two different jobs independently.
> 
> Prefixes also offer personalization.  When you see a prefix, you should expect
> it to fit within the style and patterns of that author, and if it doesn't work
> easily with your own patterns, you can choose a different personality that
> does. 
> 
> To handle the rare case of prefix-collsion, I have a fine suggestion that
> allows us to avoid having the long Java-style prefixes.  Create a utility as
> part of the package loading that can *rename a prefix* whenever there is a
> collision according to the *loading* users desire.
> 
> This solution has numerous benefits including simplicity for everyone and
> complete customizability for what is important to each person for THEIR image
> environment.
> 
> Cheers!
>   Chris
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com



More information about the Squeak-dev mailing list