Quick comparison of two Namespaces proposals

more over, could be a syntax rule:

capitalized message: answer (self namespace at: message)
non-capitalized: traditional message send.

we could as well write (self Array new: 4)


Tansel a écrit :

On 19/09/2007, nicolas cellier <[hidden email]> wrote:
> more over, could be a syntax rule:
>
> capitalized message: answer (self namespace at: message)
> non-capitalized: traditional message send.
>
> we could as well write (self Array new: 4)
>

Well, we don't need to change anything to use lately bound names/classes.
You can always introduce messages in your classes, like
#myArrayClass
#myPointClass e.t.c.



--
Best regards,
Igor Stasenko AKA sig.

With st/x I used to struggle with dependencies between packages which
included references to globals/classes. To avoid any such early bound
references I used to  define a class called CLASS which you could use as

CLASS Array
CLASS String

as a short hand for Smalltalk at: #Array etc. This worked very well for me.

so thinking out load if my CLASS behaviour could be added to Class so that

Class WASession -> WASession

and we define WA similarly, then

WA Session -> WASession

If we make WA the current 'in' namespace, then Class could take that
into account, so that

Class Session -> WASession

for tool support, each prefixed class would need to know its
prefix.namespace so that tools could show the class name in browsers
without the prefix.

WASession-namespace

^WA

its late....

Keith

Hi Michael!

Ehm, well. :) It looks like a Package can contain any namespaces (like for
example one that you already have with the same name in another package)
and that the complete "tree" of the namespaces is the merged tree of all
packages in your image? But then I have a hard time seeing that a Package
ISA Namespace (subclass). Or perhaps the Namespace tree is in fact not a
tree at all.

And even if I am wrong... this feels complicated to me. But then again I
am pretty daft. ;)

regards, Göran

Hi Keith!

[SNIP]
> Class WASession -> WASession
>
> and we define WA similarly, then
>
> WA Session -> WASession

This would be trivial to do right now in my proposal. WA:: is already an
object of instance Namespace sitting in Smalltalk so if I add a DNU to it
- you got that.

And we could even add a "mapping" mechanism based on sender, like for
example, looking at the PI of the sender and decide if we want to resolve
in self (WA::) or delegate to another namespace (WA28::).

> If we make WA the current 'in' namespace, then Class could take that
> into account, so that
>
> Class Session -> WASession

I presume the idea here is to do totally "context dependent" resolution,
right? First of all, I would probably use Smalltalk instead of Class - we
are after all talking about globals and not ONLY classes.

So then you could write:

    WA Session

..or:

    Smalltalk Session

The first line would mean, give me "Session" in namespace WA:: - and
decide yourself what to give me back depending possibly on me as a sender
and on any other runtime aspect.

The second line would mean, give me "Session" in whatever namespace is
suitable (including the global space) depending possibly on me as a sender
and on any other runtime aspect.

> for tool support, each prefixed class would need to know its
> prefix.namespace so that tools could show the class name in browsers
> without the prefix.

Again, this already works in my proposal though.

In summary, yes, we can have message based simply dynamic lookup that can
take runtime context and sender into account. But do we REMOVE all
statically bound references and DISALLOW them from now on? That is a
*much*
larger step IMHO and I can't say I have thought through all ramifications
of such a route.

regards, Göran

PS. I can add the above DNUs to my proposal just to show how it can work etc.

Yea, it's pretty complicated. I spent ages contriving up the design, but the results are pretty spectacular and allow for some pretty nifty tricks.

I've edited http://gulik.pbwiki.com/Namespaces. Let me know if this is easier to understand.

Packages sub-class from Namespaces so that they can contain Namespaces in the same way that Namespaces contain other Namespaces. It also means they can be validly added to import lists.

My namespaces are not all merged together, because the compiler does not search every package/namespace instance in the image. The compiler /only/ searches a method's local Namespace instance, and then it searches that local Namespace's import list. It does not search anywhere else. If the name is not found in the local Namespace instance or in the import list, the code will not compile. To make use of a name, you need to add the namespace object containing that name to the local namespace's import list.

Gulik.



--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

On 9/18/07, Michael van der Gulik <[hidden email]> wrote:
> Array is a class, not a message. This is /not/ elegant and simply doesn't
> make sense. This is my last comment on this approach.

That may be your opinion but if we view a Namespace as an object that
gets a message #Array, which causes him to return the object (a meta
class) for his idea of Array, then the message concept makes perect
sense.

The only difference between this and regular message send is that the
"message" is capitalized, but I think this is a nice cue to show that
something different is happening here (i.e. resolved at compile time,
etc.).

And keep in mind, as with the other proposals, this syntax will only
be needed when it is ambiguous without it.

Personally this is the only solution I have seen that I found elegant.

On 9/18/07, Igor Stasenko <[hidden email]> wrote:
>
> Again, discussion downs not to about how namespaces should behave, but
> to choosing appropriate and  conventional syntax for it. Personally, i
> don't think its really matters.
> Please, people, lets focus on more important things, if you don't want
> to flame this topic, like in previous 'pipe syntax'.

How code looks is important.  If it wasn't then Java wouldn't be the
current most popular language.  It's also not going to be easy to
switch after the fact from e.g. :: to the message sending style.

ROFL :-D. You can't be serious about that!

Gulik.


--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Brent Pinkney wrote:
> 1. VisualAge's decision to use C-syle call stacks instead of proper
> objects prevented the use of continuations.

Just to nitpick, continuations can be perfectly well implemented even in
C (I have done so before, using setjmp/longjmp and stack copying, based
on a technique I saw used in Aubrey Jaffer's SCM interpreter), so it
seems to me that the problem is perhaps more one of a lack of complete
*reflective access* to the C-style stack than anything to do with the
implementation in the VM itself.

Of course, I haven't investigated VisualAge for myself, so I could well
be off base here.

Regards,
   Tony

Well, this adds levels of complexity to VM, by adding hard tricks,
like controlling C heap allocations (not VM heap, controlled by GC).


On 23/09/2007, Tony Garnock-Jones <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.

Oh no, I'm quite serious.  The reason Java gained such market share is
because it looks similar to the C/C++ languages people felt more
comfortable.  The guy who wrote about "the next big language" even
says this kind of look is a prerequirement now to success.

On 9/22/07, Michael van der Gulik <[hidden email]> wrote:

On 9/18/07, [hidden email] <[hidden email]> wrote:
>
> This reasoning makes no real sense to me. Why would multiple levels be
> "better"? Are we afraid of running out of namespace names? IMHO the
> proliferation of namespaces and hierarchies of them in other languages
> (like Java) is more based on the fact that they are used for
> organisational purposes.

Well my reasoning is simple:  we have effectively a flat namespace
now, and it doesn't seem to be enough.  If we add just one more level
then we increase our scale by quite a bit but you still have the
siltation like:

Net::Socket
NetFtp::Socket
NetTelnet::Socket

When what you want to say is:

Net::Socket
Net::Ftp::Socket
Net::Telnet::Socket

In other words, with only one level the Namespaces end up having the
same "prepending prefixes" problem as classes have now.



>
> I don't see the need for that many namespaces - in fact, they should
> probably map rather well to *communities* or *projects* rather than
> *packages*. Which again is why I don't consider namespace==package.

But don't communities have sub communities?  And projects sub projects?

> To make myself even clearer: The base Smalltalk-80 libraries could all
> be in one single namespace - and for convenience, let's jus stick to
> good ole "Smalltalk". The whole Seaside community could use ONE
> namespace. The Croqueteers could use ONE or a few. We don't need to
> create a namespace for every little silly class library you know! :)

We don't but we already do after a fasion.  The issue isn't that we
want big complicated Java libraries, the issue is that we want the
simplest name for our class but it's either taken or likely to clash
with something.

> Just maintaining spaces of unique names isn't rocket science IMHO. And
> yes, I agree - my proposal is NOT a *Package* proposal - it *is* a
> Namespace proposal though. Even though calling it "Prefixes improved"
> might make it sound less threatening. :)

Well, the terminology is confusing here.  Your proposal is what C++
calls "namespaces".  In C++ a "namespace" is just a string you prepend
to all classes/functions/variables/etc. that are in that "namespace"
and the compiler has special help so that you don't have to type it
all the time.

In my opinion this was just the simplest way to allow contextualizing
of variables that Bjärne could come up with.  C++'s is mostly complete
but as it is only a compile time convenience there is no possibility
of reflection, etc.

> But why? Smalltalk is different. We can always *learn* from other
> languages but just copying is not good.

> Agreed.  I will make my proposal in a different message.
> I would like to hear the views from the creators in this case. Just the
> fact that they are very seldomly used should IMHO signal us to
> reconsider. They are a namespace imported per class. They do create an
> "environment" where code behaves differently and where you can easily
> "trick" the reader - like having a shared pool shadowing a global etc.

True, in their presence one has to be more careful reading the class
definitions, but when we get a real package system we will have the
same issue.  But honestly the tools can easily point this sort of
thing out for us.

> IMHO a mechanism that widens the gap between what you read and type and
> what is actually executed - is generally a problem. Imports in general
> is such a problem, especially imports per class and in which ordering of
> imports matter (just mention the word "class path" to a java developer
> and watch him/her squirm).

But it can be managed obviously.  Smalltalk gets a big portion of it's
power from the tools, and I think the tools can give us an advantage
here again.

> Also - the fact that a shared pool does not even have to be a global,
> well, it sure makes them "tricksy enough" to warrant some scrutiny IMHO.

Scrutiny is welcome, as it helps us avoid "onions in the varnish", but
I would like to hear Dan or someone make a statement about them at
some point.

> I know that most languages mix these concepts - but that doesn't make it
> mystically right. :) Most code packages (as in deployment unit - think
> class library for example) are developed by individuals or groups of
> developers and it is convenient to create a little "sandbox" in which
> that group can maintain their own names without having to risk
> collisions with the rest of the world. This is what I call "pessimistic
> approach" - as in, you "lock" your own space and that's it. Downsides
> are proliferation of lots of small namespaces "just in case" and
> duplicated classes - lots of Date classes for example (see java again).

But you will see this anyway, we see it now.  Presumably if we had
your solution (or any solution), the prefixes we have now would be
exchanged for a "namespace".  So I know mostly Seaside/Magritte/Pier
and from there it's:   Seaside - WATask, WAComponent, etc., Magritte -
MAComponent, etc., Pier - PRStructure and so on.  Most projects *do*
have what you're calling a namespace already.

I don't think it's "pessimistic", it's just that we want to use the
simplest name we can.  In the examples above, it's not a
"WAComponent", it's a Component in the context of WA or Seaside.

> I am proposing fewer namespaces that are "more shared" and instead
> "embrace collisions" by using an optimistic approach and deal with them
> when they appear.

And how will they be dealt with?  By making a namespace right?  It
seems like you try to argue here like "it's ok, let us have them! you
wont even notice they're there!  They will hardly be used!", but it's
not true.  People want them to use them and the only thing that will
remotely slow them down is the desire for platform compatibility.  And
I don't know how big a factor that is; I see plenty of { } code.

> This is what we do today in SystemDictionary when we
> don't use prefixes - we are in fact maintaining and tending a shared
> namespace (hundreds of developers) and sometimes we end up with
> collisions and then we deal with that. This is GOOD. Putting every
> little silly class in its own little space - like for example if we
> equal class category to namespace - that would be nuts.

Well, I agree that class categories serve a different function, but
you can't believe we will only have one or two namespaces.  You can
look at e.g. the dev image right now to get a feel for how many we
will have.

> I am very curious to why you think so. Even in java the hierarchy is
> just by convention. I definitely do not see any obvious reason to why
> namespaces should have a father-child relation and I definitely don't
> see any obvious interpretation of such a relation. Really, I am not
> trolling. :)

I would never accuse you of trolling.  I don't think of it as
"father/son" as much as "in the context of".  For example, we have the
context of Smalltalk, and currently all our code is within that
context.  Once we have a namespace solution we can expand the contexts
further.  It can be that a namespace or context itself is not unique
in the context of Smalltalk, but something more specific (can't think
of any great examples right now, but a cheesy one might be:  Booking
means something different in the context of Police then it does
TradingSystem).

> This last statement shows clearly that you have not read about my
> proposal in any kind of depth, which of course is fine - it is by all
> means not required bedtime reading. :) But let me just say that imports
> is NOT the only way to get rid of fully qualified names in typing and
> reading.

I don't recall if I have or not, certainly I haven't recently.  But I
realize you don't have to type the names out unless there is a
conflict, but what I'm saying is in 5 years time there *will be*
conflicts if you don't have imports.

> In my proposal all classes (globals of course, but hey - we are talking
> about 99% classes) that have unique short names in the image (that would
> easily be 98% I guess)
> are always rendered and typed in their short
> form. ONLY the classes which are duplicates (Fruit::Orange and
> Color::Orange) would be rendered in fully qualified form and they still
> only need to be typed shortly - the browser will ask which one you mean
> and expand upon save.

Ok, so you don't have to type it.  :)

We can try it out today if we want to.  It has been a Squeaksource
package forever.  Why does everything have to be in the main image
before it's "tryable"?  We are going to all this trouble (well a
couple of people are, but we all claim to want) to remove packages
from the Squeak image to let people choose what they want, aren't we?
But before we're even done we are already deciding that people wont
choose it so it needs to be in the main image.  Confusing, no?

On 9/19/07, Igor Stasenko <[hidden email]> wrote:

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Hi!

Long post - probably not that interesting for most people. :)

I would actually not want that, I would want:

Net::Socket
Net::FtpSocket
Net::TelnetSocket

Ehm, noting of course that the design is bad in the first place - it
should not be different subclasses of Sockets at all. But my point is
still made - we should not use the word Socket for tons of different
things.

Also, noting that I am not advocating splitting base classes into spaces
either - so there would not be any Net:: at all.

> In other words, with only one level the Namespaces end up having the
> same "prepending prefixes" problem as classes have now.

I don't think so, you can probably come up with an example - but I think
it would be quite rare.

>> I don't see the need for that many namespaces - in fact, they should
>> probably map rather well to *communities* or *projects* rather than
>> *packages*. Which again is why I don't consider namespace==package.
>
> But don't communities have sub communities?  And projects sub projects?

They do, but not that often and it would most probably not need to be
represented as a "sub space" if they do. For example, Seaside might be
considered a "sub community" of the Squeak community - but we sure don't
argue that it should be a "sub namespace of Squeak". Same goes for most
projects I suspect - Scriptaculous being a sub project of Seaside? Sure,
but it doesn't force us to make it a sub namespace.

Actually, I think the biggest reason is that we (we being we who are using
prefixes) don't want to "pollute" the global space. And yes, we do want to
avoid clashes - but not because it would be terrible but because we
currently don't have mechanisms to deal with them.

But my point still stands - we don't *need* a space for every package.

I am not sure I caught the "confusing" part.

Just because tools can help us doesn't mean it is a good thing/idea in the
first place. IMHO the shared pools in Squeak is an ugly wart. Thank god we
only use them very sparingly.

>> IMHO a mechanism that widens the gap between what you read and type and
>> what is actually executed - is generally a problem. Imports in general
>> is such a problem, especially imports per class and in which ordering of
>> imports matter (just mention the word "class path" to a java developer
>> and watch him/her squirm).
>
> But it can be managed obviously.  Smalltalk gets a big portion of it's
> power from the tools, and I think the tools can give us an advantage
> here again.

Sure, but again, that doesn't mean they are good per se.

>> Also - the fact that a shared pool does not even have to be a global,
>> well, it sure makes them "tricksy enough" to warrant some scrutiny IMHO.
>
> Scrutiny is welcome, as it helps us avoid "onions in the varnish", but
> I would like to hear Dan or someone make a statement about them at
> some point.

Me too. :) I will meet Dan at OOPSLA later this month and will ask him.

Yes, but the mechanism is not the same. The tools will never ask you about
which "Component" you mean so the conflict of short name will not be
apparent and thus the current solution is pessimistic.

> I don't think it's "pessimistic", it's just that we want to use the
> simplest name we can.  In the examples above, it's not a
> "WAComponent", it's a Component in the context of WA or Seaside.

Sure, and we can decide to do that. But not *all* the time, sometimes we
hopefully end up making the name more descriptive instead. Like I did in
your Socket example.

>> I am proposing fewer namespaces that are "more shared" and instead
>> "embrace collisions" by using an optimistic approach and deal with them
>> when they appear.
>
> And how will they be dealt with?  By making a namespace right?

No, either we decide to live with them (hurts just a teeny bit - reading a
fully qualified name instead of a short one *iff* both packages are in
your image) or we rename one of them.

> It seems like you try to argue here like "it's ok, let us have them! you
> wont even notice they're there!  They will hardly be used!", but it's
> not true.

I am not saying "They will hardly be used!" - you just said that, not me.
But yes, you will not notice them much at all. What I am saying is that I
don't think we need *as many* namespaces as for example the java community
uses - but I am not saying you shouldn't use them.

For the base classes I *do* believe that. Because we are already
maintaining that namespace together and it is working just fine. I didn't
mean for the whole world of Squeak.

I still don't see the great need nor the semantics of it. But that's fine,
we don't need to agree at all. :)

This is an interesting statement that tries to argue that in 5 years we
will have much more libraries and code and that this will linearly
increase the number of conflicts. At first sight this seems logical BUT it
totally ignores the fact that you only get a naming conflict INSIDE AN
IMAGE.

And since the number of libraries and code in a given image is not likely
to increase all that much (some yes, but not much) the reasoning fails.

An example, let's say Magritte uses Component and so does Seaside. Sure,
they are used a lot together in many images and perhaps my proposal would
eventually make one of them to rename Component to something more
specific. But if a specialised Open GL library used a class Component it
would most likely not be loaded at the same time in that many images so it
would NOT cause the users to cheer for a rename. See my point?

Right. And also - if the references are in the LOCAL space then you don't
need to read it NOR even choose one in a menu - it will pick the local one
and not ask.

regards, Göran

PS. See my other recent post with a different proposal - just to confuse
of course. :) :)

Thinking about your discussion late vs early binding:

If the package loading tools were to support compilation (early binding)
based upon the definition of the namespace into which the import is
occurring then we could stick with early binding being the default
rather than accepting the cost of dnu's etc.

I am thinking here of SystemEditor which compiles the new implementation
'off line' so to speak. If System editor can be connected to the
namespace SystemDictionary of choice to perform its magic then this
could work well.

...

Thinking out load, I am also wondering whether supplying extension
methods as a specialized form of trait could also work.


Keith

On 04/10/2007, Göran Krampe <[hidden email]> wrote: But then, someone who worked with Component moved to another image and
found that Component here is not a Component there and he needs to
keep in mind every time that there are different Components in
different images. And then everytime he will see reference to
Component, he will keep losing time, checking is that Package deals
with Seaside component, or with OpenGL component, or maybe with Foo
Component?
And, in contrast, having full notation like Seaside::Component (or any
other proposed form), he'll never be confused while studiyng/checking
code in any image.

Personally, i tend to have one huge big image for my dev purposes. I
like to have all in single place, rather than running couple squeaks
and maintain number of images and keep remember where they live, what
packages they use e.t.c.
This is much more convenient - suppose i want to update something, so
i need to update only single image once, but having many images i
forced to do that many times..


--
Best regards,
Igor Stasenko AKA sig.

On 10/4/07, Michael van der Gulik <[hidden email]> wrote:
>
> If there was anything important in the rest of your email, could you
> summarise it for me? I'm not going to read the whole thing.

Same point as you about name classes just being moved

We already have lots of the proposed kind of "namespaces"

The terminology is confusing

The tools can help us with the complicated solution

1000 points of light