[Pharo-project] 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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Mar 27, 2009 at 6:17 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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.
There is also this: http://gulik.pbwiki.com/Namespaces
On 3/28/09, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Fri, Mar 27, 2009 at 6:17 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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/
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 <marianopeck@gmail.com> wrote:
On Fri, Mar 27, 2009 at 6:17 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse <stephane.ducasse@inria.fr> 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.â
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/3/28 Markus Fritsche <fritsche.markus@gmx.net>:
Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse <stephane.ducasse@inria.fr> 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...
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/3/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/3/29 Igor Stasenko <siguctua@gmail.com>:
2009/3/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
participants (6)
-
Igor Stasenko -
Mariano Martinez Peck -
Markus Fritsche -
Michael van der Gulik -
Stéphane Ducasse -
Torsten Bergmann