Hi Russell!

"Russell Penney" <russell.penney at tincanct.com> wrote:
> A man who can apologise is worthy of respect!

We all fumble the ball sometimes. :)

> I have had a bit of a brainwave about this issue...wouldn't the best place
> to check for class name conflicts be in SqueakMap? I know this wouldnt fix
> all the problems but the major issue as I see it is conflicts between
> packages.

In fact - this is what I plan to do "of a sorts". I want the Namespace
names to be registered on SM - just like PI names can be registered
today (more and more will use that I guess as PackageInfo gets more and
more the standard way of specifying a package).

I know (my proposal) this creates three partly overlapping concepts, but
I am not sure we want to loose either one:

1. Categories. Simply named groups of classes - doesn't affect the code
in any way.

2. PackageInfo names aka PIs. Today there is a connection between a PI
name and a category namely that the PI name "SMBase" includes all
categories beginning with "SMBase".

3. Namespaces. A class knows its Namespace object and the Namespace
objects themselves are kept in Smalltalk. A Namespace is just a
Dictionary of names and values, typically holding classes (just like
Smalltalk is today).

In my current code I have coded up the class creation templates so that
it picks a Namespace name by looking at the category name, but you can
pick any name you like. So a Category can hold classes from different
Namespaces - meaning that there is no connection except that the
developer probably make them align more or less.

This of course creates the question - should we drop merge the concept
of categories and namespaces? Hmmm, not sure because I didn't want
Namespaces to be that fine granular. I just wanted Morphic:: and
Kernel:: etc, not many at all. So skipping the categories would make the
system harder to browse I think.

Ideally the browsers could use either mechanism I guess. Right now I am
messing with class Browser and friends to make them cope with my
namespace model - it works "kinda" - but there is still a bit to go
before I post my code.

> So the steps for example would be:
> I write some code with classes and extensions to base classes.
> I package it up (I know it can be done but I have never tried to do it).

Monticello is your friend there. Simple, neat.

> I upload to SqueakMap.
> SqueakMap checks the packages and replies that I have a conflict with a
> class in package X. I can then decide to rename it, or whatever.
> Or it might come back and say "You have overridden a method in a base class
> that is overridden in package Y"
> 
> Hmmmm...
> 
> Seeing as SqueakMap seems to be the "Official" place for package information
> to live, cant the information be updated to include a list of class names
> and extensions for each package? That way SqueakMap doesnt have to check
> when I upload, I can check for conflicts when I build the Package.
> 
> The package tools would need a few changes to check SqueakMap first. Oh and
> SqueakMap would need changing but I dont see it being too big a job.

Well, I agree that we want this kind of "super catalog". Avi and I have
discussed it and probably a few others. I envision it as a separate
server though - that *uses* SM to find all code out there and builds a
mega-index of it all. It would enable us to do alt-m, alt-N etc on a
global scale! Really useful and cool. But quite a bit of work.

Though I agree it could also help here in discovering and thus reducing
name conflicts.

> That way nothing in the Squeak kernel itself has to change.

Well, I still think we need to be *able* to have conflicting names like
Tweak::Button and Morphic::Button - because otherwise a whole group of
good often used names will go extinct. :)

But it would surely help minimizing this "pollution" of common names.
And this is after all the underlying idea with my proposal - all names
are "exported" by default thus making these clashes clear and visible to
everyone.
 
> Russell

regards, Göran