Squeak and Namespaces

Hi!

You have no idea how long. :)

> Sample scenario
>
> I take a clean 3.9-ish image.
> I load the namespace support.
> I load a package that introduces the classes Someones::SharedQueue
> and Someones::Something
> <would that work, given that there is a naked SharedQueue in the
> system?>

Yes. You now have two classes, one named #Someones::SharedQueue and one
named #SharedQueue. Just like with prefixes today.

> I go into a method in Someones::Something and type
> SharedQueue new.
>
> Does this prompt a disambiguation question,
> and if so, how do I indicate that I want to use the system's
> SharedQueue?

This is a good example. If you had written SharedQueue in Foo:: then when
saving a popup menu comes up and asks which one you want. You select which
one and Squeak will correct the code by inserting the prefix, if you
selected Someones::SharedQueue.

But if you type it in Someones::Something then there is a policy that says
that "local" references (=typing a short name that has a match in the
namespace of the class that you are editing, regardless of other matches
in other namespaces) are assumed to mean the local one - so it will not
ask and it will not expand visually to Someones::SharedQueue - BUT the
source will read "Someones::SharedQueue". Theoretically we could meet half
way - not asking, but still expanding it visually - but that is not how it
works today.

I can't verify this right now - but I am pretty sure this is how it works
and how I meant it to work - local references is such an obvious special
case that I think it is worth "deviating" from the rule that a short name
always means that there are no other such short names in any of the other
Namespaces in the image.

But note that this "lookup policy" for local references is actually a
"Tools Issue" - we could even make that a Preference! Or you could hack in
"imports" and use that. And I have isolated this policy in the code in a
single class to make it easy to experiment with.

> The answer earlier about how yes, one could use existing categories
> as defaults,
> but you'd do it in the class-creation template, prompted this question.
> What is the default full name of an existing class,
> when your changes are first incorporated into an image?

It depends on how we wish to partition the classes we already have, see
below.

> I.e. where did 'Kernel' come from in your example above,
> if not by automatically namespacing legacy code by category?
> And if that is done, does it immediately affect the content of all
> fileouts
> and package commits?

We have three choices:

1. Keep the basic classes unprefixed just as now.
2. Introduce a single space for all basic classes, like Kernel::.
3. Cut the basic classes up in several namespaces.

IMHO #3 is bad. We aren't talking about Modules nor Categories. The base
classes are maintained by the same group of humans (=us) and we can make
sure all their names are unique - so we should just have ONE space.

#2 was what I first envisioned - but now that you posted I recollect that
someone thought it was better to just keep them in the "unprefixed
Namespace" which equals Smalltalk.

So disregard my previous post and forget about Kernel:: - I recommend #1.

> Or is it the case that you can't introduce a namespace-prefixed name
> whose base name is also present as a naked legacy class name?

If we go for #1 - that is correct since all Namespace instances are also
globals. In other words - at the same instant you create Foo::Bar, the
system will instantiate the class Namespace and put that in Smalltalk at:
#Foo.

Sorry for the confusion.

regards, Göran

Klaus D. Witzel wrote:

>> What is the consequence? Well, in *practice* this emulates my solution -
>> only type short names and it asks when there are choices.
>
>
> And preserve that during fileOut? And cause conflicts (DNU's?) during  
> fileIn?

As I understand it, the explicit fully qualified name is maintained in
the code and filed out.  [ The tools *may* display them as short names
if they are non-ambiguous.  ]

>> You hardly ever
>> look at the imports anymore - which is yet another evidence that you
>> typically *know* what you use/import.
>
>
> Except when you hunt for bugs where two methods of the same class (and
> on  the same side) use different namespaces?

They would be fully qualified in the code, so there would not be a
conflict.  [ However, if you like, the tools can *display* only the
short names, where these are non-ambiguous.  ]

>> - Don't *have* to be hierarchical.
>> - Don't *have* to use file/class/package level imports.
>
> +1
>  - Don't *have* to be explicit.

Yes, this is in Goran's proposal.  [ Again, they are explicit in the
actual code, but the tools *may* display the non-explicit short names if
they are non-ambiguous.  Similarly, you only need to enter a short name
if it is  non-ambiguous, if there are two or more possibilities, the
tool will ask which you mean.  However, the explicit name is stored in
the actual code.  ]

David

Hi!

Not sure what you mean though. :)

[SNIP of micro glossaries]
> ...
>> What is the consequence? Well, in *practice* this emulates my solution -
>> only type short names and it asks when there are choices.
>
> And preserve that during fileOut?

Yes, the fileouts (actually - the SOURCE - not just the fileout) always
contain the class names. And recall the the names of the classes are the
fully qualified names - just like the name of WAComponent is...
#WAComponent today. No difference whatsoever with how it works today.

The only differences are in how the code viewers/editors choose to render
and accept qualified names/short names.

> And cause conflicts (DNU's?) during
> fileIn?

Nope. No conflicts, just like how WAComponent doesn't conflict with
anything today unless someone uses the exact same prefix and short name.

>> You hardly ever
>> look at the imports anymore - which is yet another evidence that you
>> typically *know* what you use/import.
>
> Except when you hunt for bugs where two methods of the same class (and on
> the same side) use different namespaces?

Waff? In Java?

Unsure what you mean with "explicit".

regards, Göran

Again what is the difference between really naive simple namespace  
proposed by  goran and prefix usage.
Seriously I do not understand. Really! I should be too stupid.
On the one you cannot say look this is simple and cool and what does  
it brings. I mean really, deeply versus the cost
(ie fixing all the places that will break). it is just that you can  
load and that in case of conflict you can say move this def in this  
namespace?

Stef

PS: what I see is that this anedoctal for now compare to all the  
tasks that could improve squeak:
        - more tests
        - toolBuilder usage
        - better packaged code
        - clean dependencies
        - removing dead code/broken code

Hi Keith,

on Thu, 30 Nov 2006 03:33:42 +0100, you wrote:
Sure. Get rid of it.

> b) allow the binary operator shown above to be '::'?

In principle: yes. Except for #Aselector: and Aclass, which can be  
mistaken (next line is a bug) for

  Aselector::Aclass

> #>~ seems rather naff #>> would make some sense to me but is used by  
> Integer for shifting, so I guess it would not be available.

I won't care as long as colons are explicitly reserved for the argument  
concept. From the GOF designers point of view, *either* a selector has  
special character(s) *or* the argument(s) are delimited by a special  
character (colon for the latter) - and no whitespace allowed, like in  
negative examples (3 + = 4) and (key : value).

This "special character *or colon* accompanies *every* argument position"  
message of Smalltalk was always evangelistic clear to me. We don't have  
#(( or #[[ or #^^ or #__ or #.. and I hope the same for the #:: symbol.

/Klaus

> cheers
>
> Keith

Hi!

Yes, but that doesn't mean that it would not benefit from merging!

> or b) most commonly, are simply using the most natural
> name for a component of their work - which is often the most
> natural name for someone else's unrelated component of their work.

I agree. But if they are building a piece of software that they want
others to use - typically like we do in Squeak most of the time (open
source stuff) then they also need to take into account that choosing a
name like Component has a price. It might in that case be better to *try*
to choose something more unique or more specific.

> Neither is one in which there is value in assisting in the merging
> of these two classes (whatever it would mean to assist that,
> beyond letting them coexist without any inconvenience,
> which they generally do.)
>
> One of the nice things about working in a namespaced system
> is that you can happily choose short, simple names for the innards of
> your stuff,
> and not  be penalized when other people do the same.

Note that you don't get penalized in my solution - BUT if you spread your
package as open source (to lots of other users) then you will inevitably
"pullute" our shared namespace of common short names. We want to be very
careful about that pollution - because it muddles our brains.

The fact that my solution shows such pollution - makes it apparent to the
developers that it indeed exists - it will hopefully keep it to an
acceptable level.

There is one small mechanism I added and then managed to remove somehow -
but it would be easy to add again. The idea is that most of the classes in
a package aren't that useful outside of it - they are "private" to the
package. So if you use such common short names for "private" classes -
then you could mark them as "shy". The effect would be that Squeak would
not consider those classes when you type those short names elsewhere - so
they would not cause the popups nor the visual expansion.

Again - this violates the idea with short names being fully disambiguous
(just like local references violates that principle) - but again,
something we could experiment with and might be worth it.

regards, Göran

Hi all ...

one thing I really love in Smalltalk after programming years in different languages (and since
1996 in Java) is the simplicity and the really straight concept. One point is, that I don't have
to deal with imports (or my IDE doesn't has to deal with it), I just wirte the class name and it's
OK. All I need is in my image. Oh, yes, many of those classes have a little prefix of two or three
chars, but who cares? That makes it allways clear, which implementation I use. So even in
VisualWorks I use my TLAs as prefix, it makes live more simple.

Adding namespaces adds complexity, a litte one, but it does. Smalltalk would loose a piece of its
advantage.

Just my two cents.

mue

--
**
** Frank Mueller / Oldenburg / Germany
**
** http://frank.mweb.de
**

Hi!

I agree 100%. That is very much my own feeling but I went ahead and
thought "Can we still do *something* that actually maintains this
feeling?" and that is how I came up with my solution.

In practice most things would just continue to feel and look like before.
You can still create classes *without* prefixes. You can still use
packages using the old prefixes. There are no new tools needed, and no
complicated models to learn - everyone can learn that ok - if you used
class names like "WAComponent" before you can now instead use
"WA::Component" and you get a few nice advantages. Easy.

And there are no imports and there are no multiple contexts. IMHO it only
improves on the situation that we *already* have - prefixes.

If you haven't read it:

     http://swiki.krampe.se/gohu/32

regards, Göran

On Thu, 30 Nov 2006 10:17:41 +0100, G"oran wrote:
Inasmuch as containers and components form a hierarchy: yes. Inasmuch as  
the atom of a hierarchy can always root a subhierarchy versus, an atom of  
a namespace can always be subdivided: no.

Suggestion: you take the branch marked with *yes* :)

>>> But yes, the idea was to use late binding using message
>>> sends etc.
>>
>> No, this was not my idea. The compiler reduces the #>~ message symbol:
>
> Ok, but it was in Henrik's/Dan's code. :)
:)
>
>>   (A >~ B) "results in"
>>   (Association key: #B value: B) "which is a component of A"
>
> Eh... so you do compile time binding just like I do? Then what was the
> point of using a "binary message"? Just syntactic?

Partially; more specific: an attempt to use the same syntax for coding and  
for maintenance (for doIt and friends) which *also* can be overridden  
(specialized) at will (like, for example, in the Smalltalk language every  
method can be overridden at will :)

In this particular discussion, I mean *not* to override your  
#scopeVariable method in Parser. Instead, here's the difference:

  binding := scope perform: #>~ with: varName asSymbol "cannot just send >~  
here ;-)"

Note the difference between #bindingOf: and #>~ (the latter is a binary  
message, suitable for easy doIt).

/Klaus

> regards, Göran
>

brad fowlow wrote:
> Given that, do the merits benefit allotting a syntax change (a valuable
> commodity) that could begin to fork the world into ::-dependent and
> ::-free code?  
> Or would it would be better to acknowledge that letter-prefixing is just
> about as good, and free, and already there, and hold out for a stronger
> solution without colonizing the code pool in the meantime?

Bingo. That's precisely the concern I was voicing earlier.

Cheers,
   - Andreas

You just said "no", and then repeated J J's post in your own words.  ;)
In short: you can add hierarchical names with no immediate cost,
but once people use it, it would be a much larger cost to go back.

While, I like hierarchical naming in general, there is no denying that
there are plenty of issues to consider.


-Lex

Hi!

Well, I of course do not claim any Truth (TM) here but:

- Syntax change: Well, it is about allowing $: in class names. Sure, in
principal this is a syntactic change I guess. But we aren't talking about
anything more or less.

- Regarding changing Squeak from the compatibility view (not brought up
above): If we are *that* concerned then lots of other changes recently are
much more earth shattering (Traits, Pragmas etc).

- If you take an old Squeak you only need to modify 3-4 methods
approximately to get it to work with new ::-code. Do realize that many
other components and changes in Squeak like m18n etc are much more
disruptive regarding "forking the world of Squeak" when it comes to old
and new Squeak. And there are also lots of changes, even on the language
level, being done in other "forks" of Squeak like Croquet or Tweak. In
fact, it was Andreas that "triggered" this (my solution) way back when he
wanted modifications done to the Parser/Scanner to allow "scoped
variables". In fact, some of these modifications are already in Croquet
(if I am correct)!

- Regarding the benefits of my ::-solution, see my answer to Stephane.

- Also, we don't *have to* colonize the base code pool if we add this. As
I noted I think that the '' (empty) Namespace (=Smalltalk) should be used
for our current classes in the basic image.

- And finally, about "holding out for a stronger solution":
   - I really don't think my solution is "weak". It is different.
   - I really think it will be hard, hard work introducing an elaborate,
hierarchical, imports-based, alias-enabled model without destroying
much of the feel of Smalltalk. And TONS of people will argue against
it, since it will be such a radical change. Just my guess.

Btw, I have started that walkthrough here:

   http://swiki.krampe.se/gohu/35

...during that (last night) I discovered that the core does not work on
its own currently (the scopeVariable method needs to work in a more
simplistic way) - but it is approximately correct. :) I will fix that. The
idea is of course that the core changeset is all you actually *need* so if
you grab a Squeak 3.2 you file that in and tada - all new ::-code loads
and works fine. And you can even write such code in 3.2 etc.

regards, Göran

PS. It feels like history is repeating itself. Within a week I will
probably have given up on getting this accepted all over again and it will
be dormant for another few years. I guess it all depends on the current
board and on the upcoming release team leaders.

Andreas Raab <[hidden email]> writes:
> J J wrote:
> > You bring up good points, but how would you implement something like
> > this in smalltalk?  A "compilation unit" (and thus a lookup context)
> > in python is a file.  A "compilation unit" in smalltalk is a method.
>
> Sure, but this is not about a "compilation unit" it's about a
> scope. Such a scope can easily be defined, system categories or
> Monticello packages are good candidates.

It might work out well to equate all of these things.  Packages,
categories, and naming prefixes would be the same thing.

I do not know for sure whether this would all work out, but it seems
fine on the surface.  The result would be easy to think about, because
programmers would not have to split hairs about, e.g., categories
versus packages.  It should also produce shorter code, because you
could have one declaration (package foo) instead of three (package
foo, namespace foo, category foo).


-Lex

In some sense yes. :) But I tried getting the subtle differences across -
like that the name of MCDictionary is not its short name with my solution
being in - it is the fully qualified name.

So there is AFAICT no difference from the current state - when we have
MCDictionary.

> In short: you can add hierarchical names with no immediate cost,
> but once people use it, it would be a much larger cost to go back.
>
> While, I like hierarchical naming in general, there is no denying that
> there are plenty of issues to consider.
>
> -Lex

I agree. And yes, there is a cost. But people seem to think that we have
these choices:

1. No change at all leaving us without Namespaces as it has always been.
We don't need no darn Namespaces!

2. Adding my solution now that gives us Namespaces that don't seem so
impressive to all the language scientists (hey, no imports? It must suck).

3. Wait for some "stronger cool advanced" solution coming soon solving all
problems known to man kind regarding naming, dependencies, modules etc.

When in fact we IMHO probably have these choices:

1. Live on with "manual" namespaces using prefixes that doesn't enable any
proper tool support. We have them ALREADY - don't deny it.

2. Fix prefixes so that they can at least be used as proper Namespaces and
enable tool support and what not. It is just an improvement on what we
ALREADY have.

3. Wait forever for "stronger cool advanced" solutions that will be
presented, shot down and never enter the official Squeak. And during this
perpetual wait we will still be using crappy prefixes, while arguing to
death on squeak-dev about different models more incomprehensive than the
next.

Wanna bet? :)

regards, Göran

PS. To all recent Squeakers - Namespaces is a well known squeak-dev killer
subject. It pops up EVERY year, creates tons of posts and never any real
changes. I wrote my solution more than 2.5 years ago!!! And that sure
wasn't the first time this was discussed - remember Squeak 3.3alpha?! Or
Dan's environment experiment which predates even that? Don't think this is
anything new, it is just a recurring cycle. Lord knows how the hell we got
Traits into 3.9 - it is a bloody miracle. :)

tim Rowledge <[hidden email]> writes:
> Forgive me if I'm being hopelessly naive here (remember, none of my
> degrees are in CS ) but isn't namespaces something that has been
> solved before? I mean, it's not exactly a new issue is it? Isn't
> there a standard somewhere for dealing with them?

It is an old issue that has seen a lot of research.  I don't think
there is a consensus on a good solution, though.  Keep in mind that
this stuff is related to the ongoing work on components, an area that
seems to be nowhere near mined out.


Practically, a Java-like solution seems pretty good.  There is room
for incremental improvement in that area, though.  The generalized
imports of Scala seem helpful, IMHO.  As two examples of this (and
attempting a Smalltalky syntax):

   import Core.Date -> CDate  "import Core.Date, and"
                              "rename it to CDate in"
                              "this scope"


   import Deeply.Nested.[Package -> Pack]
                              "make Pack be a shortened"
                              "version of Deeply.Nested.Package"
                             


These are small improvements over Java, but I use them all the time.

-Lex

Hi lex

Just a question. Do you think that in practice nested namespaces are  
needed (not in the context of Java).
I have the impression that this introduces complexity.

Stef

On 30 nov. 06, at 13:06, Lex Spoon wrote:

Hi!

I agree that simplicity/unification is good in principle. One problem
would be that it would "force" us to have more namespaces than we actually
need. For example, I think base Squeak should just be one namespace - the
"Smalltalk one" which has no prefix.

So if we equal namespace to either package or category that would instead
create tons of them.

IMHO we have four concepts here that are different even though they may
seem similar:

- Categories. This is a pure organisational unit so that we can find stuff
more easily. Sure, PI today "uses" them to create Packages, but that is
just a trick, albeit a nice one since it creates a mapping between
categories and packages which is actually pretty nice.

- Packages. Manifested as PIs and used practically as MC packages. This is
a "developer unit" IMHO.

- Namespace. As I said I think it is about a group of humans maintaining a
space of unique names. An example is a project like Seaside operating much
on its own with a group of developers. Another example is official basic
Squeak.

- Module. The best definition of a module that I can recall was the one
saying that it is a "separately deployable unit". It is about deployment.
We don't have this today IMHO. Package (above) comes closest with its
MC's, but it is still more of a developer construct instead of a
distribution construct.

So would we want one or more of these to unite/overlap? I can't say I do
actually, but would easily like to be convinced otherwise. :) Possibly
Categories could be removed of course, they fill the least function and
Packages more or less fits the bill there.

regards, Göran

On Nov 30, 2006, at 13:06 , Lex Spoon wrote:

Actually, IMHO import lists like in Java or Python do not fit  
Smalltalk at all. Sure, people want to use unqualified names in their  
code. But in those file-centric environments, you know exactly where  
to look to identify which local name refers to which global name -  
you scroll up a few pages to the import list. Also, these imports  
always travel with the code using them, because it's in the same file.

Not so in Smalltalk. As has been noted elsewhere, the compilation  
unit is a method in a class. Consequently, you need either fully  
qualified names, or have class-based imports. We already have a way  
to express the latter (class pools [*]), and we may like to have a  
way for the former. That's all.

- Bert -

[*] Try this on the class side of some class:

initialize
        self ensureClassPool.
        classPool at: #Button put: SimpleButtonMorph

 From now on, you can refer to SimpleButtonMorph simply by Button. To  
share this "import", simply put the code into a SharedPool subclass  
and list that in the poolDictionaries of your class.