A man who can apologise is worthy of respect!

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.

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).
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.

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

Russell

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
goran.krampe at bluefish.se
Sent: Wednesday, 14 April 2004 1:49 AM
To: The general-purpose Squeak developers list
Subject: RE: A little namespace "proposal"

Hi Russell and all!

"Russell Penney" <russell.penney at tincanct.com> wrote:
> Goran,
>    I have agonised about whether I should make a comment or not about this
> chain of emails, this one pushed me over the edge. Sorry if I sound rude,
I
> am a fairly blunt person (with a very weird sense of humour).

No problem, I think I might have deserved it.

> Don't slap someone down because they disagree with you. Your way is NOT
> always the right way (it might be sometimes).

No, I agree - and perhaps I did go over the edge on that posting. I am
sorry about that.
I did hesitate a little bit when pushing the send button, and perhaps I
should have listened to that hesitation.

Colin? Forgive me?

> >- No source is changing "under your feet" in my proposal. The source (as
> >kept in memory, as saved in changelog, as filed out etc) etcALWAYS has
> >the qualified names in it. ALWAYS. ALWAYS. Ok?
> 
> Check your email on Tue Apr 6 18:40:55 CEST 2004 (ripped straight out of
the
> squeak mailing list so I have NO idea what timezone that is) which was
> directed mainly at Roel's initial comments where you say:
> 
> >The idea is to allow the short form if there is no ambiguity in the
> >image. And expand it to the qualified form if there suddenly is. So this
> >means that source will "change" under our feet. :) But hey - this is
> >Squeak and we can do that, can't we?
> 
> So which is it? And Colin was right to put that in his email, yes? I got
the
> impression that the code would "change".

The quotes were there for a reason. :) What I meant at that time - and
still mean - is that the source itself will NOT change but as it looks
in the browsers etc it will "appear" to change. Another way of saying
this is that the browsers will "render" the code slightly differently
depending on the circumstances - but the underlying source will not
change.

I am sorry if I have been unclear on that part. It may also be because
the proposal has evolved a bit.

> >- There is no "clutter" of qualified names since the source is
> >"rendered" as "qualified enough". And given that 99% of the classes in a
> >given image are named uniquely they render JUST LIKE TODAY.
> 
> Then why do we need it? To solve the 1% of problems? There are other ways
to
> handle this (EXAMPLE ONLY: every class has a UUID so the name actually
means
> nothing or even just prefix the class names with an identifier which is
what
> I do).

We need it to solve a few problems yes. As the number of packages grow
there will be a higher probability of naming conflicts and if they
happen today things simply break. A single class with the same name will
make two packages unloadable in the same image.

So even if the vast majority of all our classes will be uniquely named a
significant amount of packages will still clash because it only takes
*one single class* to make it so.

And the UUID thingy doesn't solve it. I can agree that having a class id
in parallell to the name could in theory be useful - but I want to see
use cases to demonstrate that first. Either I am really thick in the
head or... well, I dunno. Please enlighten me how I as a reader of code
will be any more wise if the classes had a UUID in them.

The prefix convention on the other hand DOES solve it - but in a
"pessimistic fashion". In fact - it is a bit like my proposal, and I use
it too today, but it is still a hack. The proposal as it stands turns
that convention into something much more proper IMHO.
 
> I will say it, your proposal sucks but don't feel bad because so do all
the
> others that people have come up with.

I really don't think it sucks. :) But hey - instead of talking I will
(and have) post code to show you how it works. And then after having
tasted it you can repeat that it sucks and I will gladly drop this whole
thing. But I am betting you will like it. In fact, I am betting it will
be so "smooth" you will not even notice it when doing normal Squeaking.
And that is very important.

And btw - we will not push such a fundamental change (even if it turns
out pretty small and clean) into the image without looking at the
various options and without having tried it out for real. So I am coding
it up and then we can play with it and see how it looks. Ok?

> Why do they suck? Because *I* don't have a problem with namespaces :) and
> 99% of Squeak doesn't either.

That is just because we use prefixes as a workaround. And there have
been conflicts too, the class SocketStream comes to mind.
Squeak is moving steadily towards being built of packages (instead of
the monolithic image) and we will increasingly see that *some* support
in this area is needed.

> Now I am dirt ignorant (but I haven't married my cousin yet) and don't
> really write packages but I don't want a Smalltalk that is hard to use
(and
> I know your proposal is easy to add and easy to use) or cluttered with
stuff
> because other languages have it or it is cool (Traits being put in the
main
> code makes me very nervous).
> 
> If it ain't broke don't fix it...fix some of the stuff that IS broken.
> Russell

I agree - and that is why *I* am so very much against the import-models
that have been proposed. Because they *will* IMHO impose on people.

I am trying very hard to keep Squeak just as soft and comfy as it is
today and *still* have the ability to name classes what I like without
being in fear of conflicts, but with the environment gently helping me
when I choose stupid names. And also get a few other neat mechanism
along with it - like better ways to navigate the image or manipulate it.

regards, Göran

PS. Again, I beg Colin and others for forgiveness if I came on too hard.
I should know better. Just a bit too much emotionally attached to my
proposal I guess. ;)