Namespaces for Squeak

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Namespaces for Squeak

Torsten Bergmann
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
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Stéphane Ducasse
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:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Mariano Martinez Peck


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.

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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Markus Fritsche
In reply to this post by Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Stéphane Ducasse
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

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Michael van der Gulik-2
In reply to this post by Mariano Martinez Peck
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
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Stéphane Ducasse
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:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Markus Fritsche
In reply to this post by Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Igor Stasenko
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
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Stéphane Ducasse
In reply to this post by Markus Fritsche
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:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Markus Fritsche
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
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Stéphane Ducasse
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:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Igor Stasenko
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.

> Stef
>
> On Mar 28, 2009, at 9:14 PM, Markus Fritsche wrote:
>
>> 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
>>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces for Squeak

Igor Stasenko
2009/3/29 Igor Stasenko <[hidden email]>:

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

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 #==

>> Stef
>>
>> On Mar 28, 2009, at 9:14 PM, Markus Fritsche wrote:
>>
>>> 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
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

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