A little namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Tue Apr 13 15:48:50 UTC 2004


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



More information about the Squeak-dev mailing list