Namespaces for Squeak

FYI: see http://www.squeaksource.com/Names.html

MIT License
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Thanks
see http://www.squeaksource.com/Namespace.html we did that some years  
ago
But we have to change its design because we separated trait/class/
global binding and it was not good.

I think that we need namespaces but not a la VW. So names seems good  
(but I can be wrong)

About Names...
        - import: '*' is not a so good design decision (we see it daily with  
Java) but it is probably necessary.
        - One namespace per category wow! Probably for a start. :) but  
clearly if we want one per package (which I hope
        we want).
        - The export clause is nice to have (even if I'm not sure about  
export: from: since export from itself self can be
        more important than from another namespace).
       
        All in all even if I can often argue with andreas I like his design  
(may be I'm wrong).
        I like the fact that there is no nesting. I prefer that design if I  
understand it correctly
        over macro like expansion as proned by goran (even if his solution  
was backward compatible).
        It is close to what we did with  http://www.squeaksource.com/Namespace.html 
  ( we did not have an export
        close if I remember correctly but were thinking about adding one).
        Now I would like to see where we defined them. Ideally I would put  
them on Package.

Stef

On Mar 27, 2009, at 8:32 AM, Torsten Bergmann wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse <[hidden email]> wrote:

> Thanks see http://www.squeaksource.com/Namespace.html we did that some
> years ago

Did it solve real-word-problems? Did it leverage new productivity/
semantics? Or was it just "me too"?

--
Zitat B. Zypries: Es gehe um die Frage: “Wie können wir verhindern,
dass deutsche Internetbenutzer auf ausländische Seiten gehen.”


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

What do you mean by me too?
We need namespace but we have to think about the design so  
implementing that package was a way to learn
and see. Now because this is more than 6 years that we are thinking  
(working with VW) looking at Java and others
I have build a kind of taste and it lets me understand and appreciate  
the design of the one proposed by andreas.

Note that I do not want to argue on the necessity of namespace because  
we will hit the wall one of these
days without them.

Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 3/28/09, Mariano Martinez Peck <[hidden email]> wrote:
> On Fri, Mar 27, 2009 at 6:17 AM, Stéphane Ducasse <[hidden email]
>> wrote:
>
>> Thanks
>> see http://www.squeaksource.com/Namespace.html we did that some years
>> ago
>> But we have to change its design because we separated trait/class/
>> global binding and it was not good.
<snip>
>
> There is also this: http://gulik.pbwiki.com/Namespaces

This package is a bit too radical for Pharo. It's a complete redesign
for how code refers to classes and global variables and how code is
packaged.

Gulik.

--
http://gulik.pbwiki.com/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

yes so this is why we should keep an eye on names.html

stef

On Mar 28, 2009, at 9:44 AM, Michael van der Gulik wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse <[hidden email]> wrote:

> Note that I do not want to argue on the necessity of namespace because we
> will hit the wall one of these days without them.

Which walls? Ambiguity?


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/28 Markus Fritsche <[hidden email]>:
> Stéphane Ducasse <[hidden email]> wrote:
>
>> Note that I do not want to argue on the necessity of namespace because we
>> will hit the wall one of these days without them.
>
> Which walls? Ambiguity?
>
yup
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

if you want to have a modular system then sharing a falt space is not  
ideal.

On Mar 28, 2009, at 3:34 PM, Markus Fritsche wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse <[hidden email]> wrote:

> if you want to have a modular system then sharing a falt space is not  
> ideal.

>> Which walls? Ambiguity?

I just think if the approach of Craig, using something like GUIDs during
Class creation, and then referring to those GUIDs would be more practical
than to use namespaces.

Namespaces proved to be a pain in the ass with several implementations, as
your "import *" example shows. We need to circumvent that...



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I think class GUID is orthogonal to namespace.
I still would be able to argue really why GUID for classes are good (I  
mean really scientifically).

Stef

On Mar 28, 2009, at 9:14 PM, Markus Fritsche wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/29 Stéphane Ducasse <[hidden email]>:
> I think class GUID is orthogonal to namespace.
> I still would be able to argue really why GUID for classes are good (I
> mean really scientifically).
>

Let argue then :)
A GUID , as for me, is a simple and logical extension of object
identity concept.
An object identity used heavily in many different scenarios in
smalltalk. A GUID also enables to identify objects not only for single
image, but also beyond it.
From 'scientific' point of view, there is no problems, as to me - for
computer its no difference what you using to identify objects - by
name or by GUID.
But for humans, this is a problem, because this no longer true, and
name losing its role as a way to identify objects.
This is where namespaces can get in play and help.

P.S. i also thinking, that GUID could be made as a special subclass of
Symbol. GUIDs are unique and immutable - same characteristics for
defining a Symbol.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/29 Igor Stasenko <[hidden email]>:
In Squeak its an UUID class. There are a certain set of applications
who using them. And making them symbols would speedup indexing a lot,
since as with symbols, you don't need to compare object contents, just
use identity comparison #==



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project