Squeak and Namespaces

Hi G"oran,

on Thu, 30 Nov 2006 01:19:41 +0100, you wrote:
My mistake: I wrote "hierarchy" but in fact the space is organized like  
the space in Trait (users of a trait composition and the composition's  
components).

> 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:

  (A >~ B) "results in"
  (Association key: #B value: B) "which is a component of A"

For namespace maintenance:

  (A >~ B) moveToNamespace: C. "next line still refers to same B"
  (A >~ B) namespace shallowCopy moveToNamespace: D.
  (C >~ B) = (D >~ B) "true"

/Klaus

I don't know what to think of the syntax; it smells a bit like C++. I prefer dotted namespaces, but that's quite subjective and not really a killer issue.

I disagree with the implementation. I personally think that the Smalltalk SystemDictionary should be split up into multiple, nested Namespaces (which are subclasses of Dictionary). These would have some mechanism, such as import lists, to glue them together. At this stage, I don't have a well-thought out alternative proposal.

The proposed implementation also doesn't solve one of the problems that Namespaces could solve: security. I'm writing a distributed environment that provides a sandbox for remote code; the remote code must be denied access to the SystemDictionary for securities' sake. Instead, remotely loaded code should only have access to particular Classes and "global variables" in the Namespaces that the remote code has access to. The namespace of a particular class could be stored in the class's "environment" variable.

I suppose it doesn't really matter; if I use the same notation and semantics for resolving classes and global variables, then code would continue to compile under both this proposal and an alternate namespacing implementation that I'll be writing.

Michael.

So would it be possible to

a) remove the 'bug' which allows ':' in Class names, and
b) allow the binary operator shown above to be '::'?

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

cheers

Keith

       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

stephane ducasse wrote:
>> And, I think imports are critical for scalability - because they a)
>> declare dependencies explicitly and b) allow the *user* of a
>> package/global to decide under which name to use them. The Python
>> module system works that way and it works great.
>
> Can you give an example? Do you mean that you can alias them?

No, I mean that a user can decide what's important for him and where to
qualify and where not. For example, consider that both Tweak and Morphic
define a class named Button. In Goran's proposal it means that you
always have to qualify Button everywhere you see it; even in the innards
of Morphic and Tweak where there is not the slightest chance of it
meaning anything but what is reasonable in this context. In Python's
module system you could (in the scope you are working in; usually a
file) decide to either use only Tweak (and not qualify) or use only
Morphic (and not qualify) or use Tweak qualified and Morphic
unqualified, or vice versa, or use both qualified.

In either case it puts the user in control about what is important for
him in the context he is working in instead of the system making
requirements about qualifications of names because in some distant
corner of the world a name has been used.

Cheers,
   - Andreas

It wouldn't have to.  No matter how the mechanism works, it can be resolved
at compile time to point to the actual location of the class, so slightly
slower compile but that's it.  I can't think of any reason to do such
lookups dynamically.

>Also, your message names are capitalised, which will have a negative affect
>on your karma.
>
>Michael.

Well if you see them as Name or Class spaces then I think convention would
indicate they should be upper case.

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered
by Pandora http://radio.msn.com/?icid=T002MSN03A07001

But this is my point.  I think many people would use your solution because
it *is* more natural to be able to just say Dictionary or SystemEditor or
whatever within your package.  So lets say that someone starts doing a lot
of research on this in 2 or 3 years and come up with a solution 2 or 3 years
after that.  At that point I don't think renaming all the classes that will
be using this will be trivial.  I think it will be a lot of work and thus
not doable for the base image.  I would just see it as a shame to not be
able to adopt a new solution because of legacy.

What you said in your other message about it not coming up unless there is a
conflict was good.  That would make it easier to simply load other projects
and not worry about conflicts, and then later fix them.  But I just don't
see it working like that.  I think once namespaces are in they will be used
whole-sale, and the reason I think that is what you said before: we are
using them now manually.

I hope I don't sound too negative.  I think you have done great work and it
is good to be able to load namespaces if you need them at your company.  For
a company, a quick stop gap is very needed because you have to deliver a
product in a specific time frame.  But squeak isn't under such constraints,
so I don't personally see a rush to put something in the image for this.

To be clear, I think your solution is great.  I just disagree with making it
default in the image.

> > p.s. Does it get the namespace from the category?  If not, then that
>might
> > be something to think about. :)
>
>The class creation template borrows the category name in some fashion
>IIRC. But it is only a suggestion.
>

Well I don't know.  It sounds like you avoid a lot of the ambiguity by
simply forcing every class to be explicit if there is more then one with the
same name.

My thinking with categories was: if there is a conflict then the package
could automatically resolve to the category it is in, and all classes in
that category resolve the conflict to mean the class in their same category.
  The problem with that is that there has to be a way for those classes to
explicitly reference classes in other packages, and anything not in that
package must always explicitly reference which class they mean.  There is
also the problem that some implicit magic happens with conflict resolution.  
So this idea would also introduce new syntax (and thus I wouldn't go for it
either).

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered
by Pandora http://radio.msn.com/?icid=T002MSN03A07001

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.


_________________________________________________________________
Talk now to your Hotmail contacts with Windows Live Messenger.
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get.live.com/messenger/overview

This is all very interesting.  So I guess the given user has to be
explicitly set up to use any namespace they get?  And if one is added you
rebuild all the places the user is being implicit since he may now be
talking about a totally different class even though his code didn't change?

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

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.

Cheers,
   - Andreas

On 30 nov. 06, at 05:00, Andreas Raab wrote:

Ok I see.
Indeed this is close to what I was thinking. Inside your package you  
do not have the idea that you may have imported from different  
namespace.
you get a flat world. And you can decide to bind your symbols in the  
import.

> In either case it puts the user in control about what is important  
> for him in the context he is working in instead of the system  
> making requirements about qualifications of names because in some  
> distant corner of the world a name has been used.

Yes

>
> Cheers,
>   - Andreas
>
>
>

Hi!

If there is another Button *in the image* - yes. But see below.

There is AFAICT nothing really stopping us from putting some kind of
"imports" into the system later. But it has the following "problems":

1. We loose the "single mode" that is a large part of the Smalltalk feel.
In Squeak I can type an expression anywhere and just "do it". With imports
you suddenly get the inevitable question "In what context?". Anyone having
used VA for Java and its "Scrapbook" recalls that sure, it was almost like
a Workspace - but you had to tell VA in which class it was supposed to
"run" so that VA could figure out the imports. I think this effect is one
of the largest "pains" when using a namespace solution with imports - and
I would guess that the pains people refer to in VW might have something to
do with this.

2. If you have used Eclipse and discovered alt-shift-o (or whatever key
combo it is that "auto fixes" the imports) would agree with the following
observation:

After having discovered this you can essentially work like this:
- Type only "short names" of classes.
- Regularly press alt-shift-o and let Eclipse "fix the imports". It will
ask you if there are more than one match - just like in my solution.

The idea to even have a background thread pressing the key combo for you
every 10 seconds has occurred - since you end up pressing it that often
yourself. :)

What is the consequence? Well, in *practice* this emulates my solution -
only type short names and it asks when there are choices. You hardly ever
look at the imports anymore - which is yet another evidence that you
typically *know* what you use/import.

Ok, I hate the way imports get into my face in Java. And people are more
or less only offering solutions based on very similar models. I really
would like for people to try to think "out of the box" here. And I am not
referring to you Andreas - you already have enough insight. But others
might benefit from at least *contemplating* that namespaces:

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

regards, Göran

Hi!

Let me just remind you that we *already* have that problem regardless if
my solution gets in or not - in fact - we are even *worse* off. How come?
Because we *already* use "prefixes" but unfortunately in a way that
disables automated renaming. Just look: SMSqueakMap, WAComponent
blablabla...

>  I think it will be a lot of work and thus
> not doable for the base image.  I would just see it as a shame to not be
> able to adopt a new solution because of legacy.

See above.

> What you said in your other message about it not coming up unless there is
> a
> conflict was good.  That would make it easier to simply load other
> projects
> and not worry about conflicts, and then later fix them.

Yes, and let me here note that in my solution ALL references to globals
are JUST LIKE TODAY. That means that they are ALWAYS fully qualified in
the SOURCE. Sorry for the caps, but this is VERY important to realize.

It means that I can load 34 other packages into my image and as long as we
don't have *namespace name* clashes (like two people using the same name
for their namespace) nothing funky will happen in my source. All
references are still perfectly correct.

The only diff is that when I *browse* the code that earlier said
"Dictionary" now may say "Kernel::Dictionary" because my image now also
contains "Joes::Dictionar" and "Schmoes::Dictionary".

> But I just don't
> see it working like that.  I think once namespaces are in they will be
> used
> whole-sale, and the reason I think that is what you said before: we are
> using them now manually.

Yes, again, see above - problem *already* exists.

> I hope I don't sound too negative.

No problem, I just urge you to test it or read how it works. :)

> I think you have done great work and
> it
> is good to be able to load namespaces if you need them at your company.

I don't think addon namespace solutions will ever be used. I wouldn't.

> For
> a company, a quick stop gap is very needed because you have to deliver a
> product in a specific time frame.  But squeak isn't under such
> constraints,
> so I don't personally see a rush to put something in the image for this.

Hehe, rush? Are you aware of when I wrote this? Are you aware of how many
posts I have written about it? Are you aware of how awfully many times the
question of Namespaces have come up on the list? It is one of the "deadly
subjects" always causing an explosion of subjective views and always end
in nada.

Note that I thought you meant in what namespace a class is *created*.

> My thinking with categories was: if there is a conflict then the package
> could automatically resolve to the category it is in, and all classes in
> that category resolve the conflict to mean the class in their same
> category.

This mechanism of "local" references is in my solution. So yes, if a
method in Foo::Bar refers to Foo::Boo it will be enough typing "Boo" and
it will render as "Boo" even though you have 100 other Boos in your image.
But it will be "Foo::Boo" in the actual source - as always. Because that
is the name of the class.

Note that these "policy" is nicely encapsulated in a single class - just
check the code. We can play with different rules for this - but I agree -
"local references" is a special case in which we can "guess" for the user.
If he really wants "Blooper::Boo" then he will just have to type that.

>   The problem with that is that there has to be a way for those classes to
> explicitly reference classes in other packages, and anything not in that
> package must always explicitly reference which class they mean.  There is
> also the problem that some implicit magic happens with conflict
> resolution.
> So this idea would also introduce new syntax (and thus I wouldn't go for
> it
> either).

Not sure what you mean.

regards, Göran

Hi!

(don't have time to respond to all - but I read all)

> On Nov 29, 2006, at 2:26 PM, Daniel Vainsencher wrote:
>
>> 1. Given 2 independently developed systems, each introducing its
>> own meaning for a new class name, a developer should be able to
>> make them able to live together in the same image without changing
>> the actual code for either. I think this is the real goal of
>> scalable independent deployment.
>
> Yes, that's a good part of it...

Which my solution btw supports fully. :) The only problem would arise if
two developers have picked the same *namespace* name - but that is far
more unlikely *and* it can easily be solved by remapping or some such
mechanism when loading/filing in.

>> 2. If the two systems both introduce similar concepts with the same
>> name,  system should facilitate their merging by the respective
>> maintainers. This goal is meant to facilitate sharing code that is
>> living (and I this is what Markus is talking about).

Exactly. This is what I am after when I blabber about "optimistic"
approaches compared to pessimistic. The idea that there is real *value* in
seeing class name clashes - even if they are in different namespaces -
because it would be much better if they did NOT clash.

Remember - we humans only have one bucket of names in our head. We can't
keep track of 5 different "Date" classes.

> It may be counterproductive to burden the namespace design with this
> sort of criterion;
> how do you assess it?    The problems to solve with namespaces are
> the ones
> brought about by their absence.   Is lack of namespaces the reason
> why people
> implement variations on the same idea?

Eh, no... But if you look at typical namespace solutions like for example
how it works in Java-land - then they suffer from this effect. Everyone
happily sits in their own little "pessimistic" sandbox and invents yet
another Date, BigNum, Socket or whatever...

> (Not just being glib there; the problem is that if you hold out for a
> namespace solution
> that brings peace to the Levant, it will be a long wait.  And the
> system needs namespaces.)

No. This "attribute" is available in my solution. Unless I totally
misunderstand what Daniel means.

> I'd offer a different second goal: the namespace solution should
> give clear guidance about what things should be called.

Mmmmm, not sure I understand.

Sure.

Right - this is important. I would call the problem "How do we partition
our classes in namespaces?".

And this is interesting. Some people mix the concept of modules with
namespaces. A Module IMHO is a "separately deployable/loadable unit". It
does NOT equal a Namespace.

A Namespace is a space of names in which a single human (or a group) takes
on the responsibility of making sure the names in that space are unique
and thus most probably are also "coordinated" in some fashion.

So... would we really need to invent fine granular spaces for the current
base classes? IMHO - no. For most of what is in Squeak basic we could just
use Kernel::, because that group of classes is maintained by *us*.

> Object ?
> SharedQueue?

Kernel::Object and Kernel::SharedQueue. In almost all cases you would not
see "Kernel::" in the code or ever type it because people typically make
sure that their own classes don't clash with the classes in Kernel::.

Btw, note how I have started using ZZZ:: to refer to a Namespace. Kinda
nice, right? That notation is typically an effect of the fact that they
aren't hierarchical.

> Monticello's Package?

Monticello::Package. MC is a good example because it typically has quite a
bit of classes that could clash with other classes in Kernel. So either we
put Monticello in the Kernel - or we use a Namespace of its own.

> Croquet TFrame?

Croquet::TFrame

> Seaside internal utiltities?

I would almost never have more than one Namespace for a single project. So
all Seaside classes should be in Seaside:: just like today (WA*). Why?
Because again - we aren't talking about "modules" - we are talking about a
space of names. Why would the Seaside developers have problems with name
clashes *within their own project*?

> And when I come along with my new little pet project,
> how do I decide what to start calling my own things,
> and how is my claim laid to those names I use?

Use a descriptive name - typically the name of the project. We do have
SqueakMap and we could easily maintain unique public namespace names
there.

But we should not depend on that - we just have to have nice functionality
to help us if we suddenly happen to get a namespace name clash. But again
- that is easy IMHO.

Which doesn't mean that they fit Smalltalk/Squeak or are good in general.

> You get local short names, and fully-qualified long names;
> you import a long name once to use short names a lot.
> There's policy that lets you know what long names you're supposed to
> choose.
> People adhere to the policy because it guarantees goal 1) by
> construction...
> policy-guided fully qualified names are always unique.

Sure, many systems work this way and I urge you to reconsider. There is a
REASON for Smalltalk being different and having unique values.

My biggest gripes with the systems you describe are:

- Imports generally suck as Java has more or less proven IMHO. See my
other post where I describe Eclipse etc.

- Hierarchies generally suck. They make everything much more complex and
most people don't understand what the parent-child relation actually
*means*. Does it mean that importing xx.yy also imports all its children?
Does it mean that yy sees everything in its parent? Or is it just an
elaborate boring scheme to make sure namespace names are unique - which
people still can break by just using xx?

Remember - in Smalltalk prefixes has more or less "solved" our issues -
even though in a very crude way. They are not hierarchical.

Make sure you understand *why* you want imports and hieararchies. I urge
you. :) The "feel" of Smalltalk is a fragile thing. I took great care in
preserving that feel with my solution. Don't think that just copying a
solution from another language will preserve that feel.

regards, Göran

Hi!

You lost me. You have "System >~ Default >~ Compiler" - that is a path
down a hierarchy, right?

>> 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?

regards, Göran

Hi G"oran,

on Thu, 30 Nov 2006 09:33:01 +0100, you wrote:
> Hi!
...
> There is AFAICT nothing really stopping us from putting some kind of
> "imports" into the system later. But it has the following "problems":
>
> 1. We loose the "single mode" that is a large part of the Smalltalk feel.
> In Squeak I can type an expression anywhere and just "do it". With  
> imports
> you suddenly get the inevitable question "In what context?".

This is exactly the *explicit* situation of the automated language  
translator and the [tendentially] *implicit* situation of the human reader  
/ listener, thank you G"oran for bringing this up!

Nothing else than *this* *situation* needs most of our attention, when  
making [partially?] irreversible decisions on namespace concepts.

For quite some decades, the automating linguists have solved this problem  
by assigning specialized microglossaries to [arbitrary] portions of text,  
a (re-)usable example is:

- www.microglossary.net

A nontrivial real-world example for all the consequences (the good, the  
bad and the ugly), in the realm of the automated field of our discussion,  
with conceptually (microglossary := microtheory), is

- http://www.cyc.com/cycdoc/ref/cycl-syntax.html

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

> 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?

> Ok, I hate the way imports get into my face in Java. And people are more
> or less only offering solutions based on very similar models. I really
> would like for people to try to think "out of the box" here. And I am not
> referring to you Andreas - you already have enough insight. But others
> might benefit from at least *contemplating* that namespaces:
>
> - Don't *have* to be hierarchical.
> - Don't *have* to use file/class/package level imports.
+1
  - Don't *have* to be explicit.

/Klaus
>
> regards, Göran
>

On Thu, 30 Nov 2006 07:13:49 +0100, 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.

And nothing makes {firstMethod. secondMethod} a compilation unit (except  
perhaps collective behavior, Adrian :)

Good point, J J.

/Klaus