Quick comparison of two Namespaces proposals
Locked
12345
12345
Re: Quick comparison of two Namespaces proposals
 
|
On 9/19/07, Igor Stasenko <[hidden email]> wrote:
On 19/09/2007, Michael van der Gulik <[hidden email]> wrote: Unfortunately, this is important to discuss. It does end up becoming a bike-shed discussion, but in about five years time when most programmers in the world will be using Squeak, the namespacing syntax they use will be the result of this discussion. I'm still undecided as to which syntax to use and open to suggestions. I'll give it a week or so. Michael. |
RE: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
> 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's
not strictly correct. In the given example it is a message: you are simply
asking the given namespace to answer the named class, and the only confusing
thing about it is the message is capitalized. What if it were
written as "Kernel array new:4"?
It is already possible to create a capitalized
message in Squeak, we just avoid it because it gets confusing. However in the
given context I simply applaud Dan's genius and I second that it is a simple and
elegant solution. For the more conservative approach I would have no problem
with a namespace creating a non-capitalized accessor message for the given class
but that could cause other
confusions.
Tansel
> +10000 for: > self add: (Kernel Array new: 4). > This mechanism preseves the elegant foundation of Smalltalk: 'Everyting is an Object, which receives a messages and returns an object'. > In this (Dan's ?) solution, the implementation is late bound and can use the same lookup algorithm as used for messages . > The other solutions lack this elegance. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Ramon Leon-5
> > I agree we need namespaces, I just think we can do better,
> > That's the thing, not everyone agrees about needing them, which in the past > has made adding them a losing battle. +1, and Göran's proposal is transparent and preserves the classic simplicity and dynamism of Smalltalk. Squeak offers the possibility that "power users" (not hard-core developers), someday, maybe after Squeak By Example showing them how, will "hop in and drive" to sketch a program. But as soon as we require import declarations, etc. just to sling a simple program together, then you've lost the "power users" group and catering exclusively to just programmers and engineers. Not to mention, it feels a bit early bound. Future Squeaks are moving toward smaller images with less code, where name collisions will be virtually non-existent. In each of these tiny images, will we have a big honkin' namespace system "just in case?" Even in todays phat images, name collisions are the 1% case, so the solution should have the benefit of being invisible 99% of the time, and handling the problem as simply and elegantly as possible that 1% of the time. Göran's approach seems to do this. - Chris |
Re: Quick comparison of two Namespaces proposals
|
|
On 9/19/07, Chris Muller <[hidden email]> wrote:
> > I agree we need namespaces, I just think we can do better, Naming collisions aren't my concern. I want to be able to load untrusted code and run it, securely. This means that I need a unit for loading remote code, thus the package was born. It also means I need to have complete control over what that remote code has access to. If you give untrusted code access to the global SystemDictionary, it has access to everything (which I consider bad practice). To solve this, I've been working on a design for Namespaces that lets a code loader show a certain amount of discretion about what a package has access to ( i.e. the import lists). Answering your points directly, I'm hoping that my tools will not be that difficult to use so that even power users can use them. The import lists should usually be automatically populated by the NamespaceBrowser. As with smaller images, naming collisions only require two loaded packages to happen (even on the smallest image), and I'd find it pretty damn annoying if they happen for 1% of all class names. That's every third or fourth package. Gulik. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Chris Muller-3
Hi Chris,
> Even in todays phat images, name collisions are the 1% case, so the > solution should have the benefit of being invisible 99% of the time, > and handling the problem as simply and elegantly as possible that 1% > of the time. Göran's approach seems to do this. You could argue that for most of the constructs in the image. Almost all classes use the default Metaclass hierarchy. Should we remove those? Almost all classes are pretty shallow subclasses of Object: Should we limit the image to a depth of 3 or 4? What is requires is a really eleganct unconstrined solution which is transparent for 99% of the cases but entirely open to modifications for the 1%. The Metaclass implementation is a good example of how this can be done. Göran's solution does not satisfy these criteria. Examples: 1. VisualAge's decision to use C-syle call stacks instead of proper objects prevented the use of continuations. This platform cannot not foster innovations like Seaside. 2. Squeak needs proper BlockClosures: sure BlockContexts suffice for 99% of the time, but they are not the timeless solution. 3. MetaclassTalk You are correct that the solution must be transparent in 99% of the cases. Cheers Brent |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
On 19/09/2007, Michael van der Gulik <[hidden email]> wrote:
> > > On 9/19/07, Igor Stasenko <[hidden email]> wrote: > > On 19/09/2007, 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. > > > > > > What is possible is: > > > > > > self add: (Kernel-Array new: 4). > > > > > > Here, #- is a message. > > > > > > > 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'. > > Unfortunately, this is important to discuss. It does end up becoming a > bike-shed discussion, but in about five years time when most programmers in > the world will be using Squeak, the namespacing syntax they use will be the > result of this discussion. > > I'm still undecided as to which syntax to use and open to suggestions. I'll > give it a week or so. > Before we having a working namespaces system with working tools, we cannot get a taste of it, and therefore there's nothing to discuss about syntax of namespaces. Just release a code with any syntax you like and just note that It can be subject of change. Syntax is inferior to design. Changing syntax is a 10 minutes task, but changing system behavior to work with namespaces is not so straightforward. So, at first place we should discuss the design, which is most important thing. As for me, i see nothing 'groundbreaking' in removing global namespace (which is system dictionary). I see nothing awful in having classes with same names in system, since they rooted in different categories (named packages/namespaces or something else) there's no way how you can get confused with ambiguousness. For example in package #Zoo , you can see a class #Duck and you know that its a duck :) and in package #Man-Moves, a class #Duck is something else. I see no ways how this can lead to ambiguousness and confusion. Everyone living with methods which have same selector, but doing different things for different classes. How making classes with same names, but doing different things can be considered awful and inappropriate? So, i insist, that before saying 'no way, i never accept that', better give it a try and see how changes complicate or simplify development process. > Michael. > -- Best regards, Igor Stasenko AKA sig. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Göran Krampe
> Let me just note that the second version using :: is NOT ambiguous for > the parser - the one using "." seems to be unless I am missing something > obvious. You have to treat ". with an alphabetic lookahead" as a different kind of token (that would be "."/[A-Za-z] in Flex). Then there is no ambiguity anymore. >> What I am a bit concerned about is that I've made the BNF grammar more >> complex or that I've made it stupid. If a dot/period is followed by >> whitespace, it terminates the current statement; else it can validly be part >> of a word or keyword. The BNF is not more complex if you move the distinction up to the lexical analyzer. Paolo |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael Davies-2
>> self add: (Kernel Array new: 4) >> > > This looks like how GNU Smalltalk handles namespaces. Following up the > references in the gst info files, I found some discussion on the > Squeak wiki which includes some work done by Augustin Mrazik in 1992: GNU Smalltalk supports both "Kernel Array" and "Kernel.Array". The former is late (run-time) bound, the latter is compile-time bound using the same old "store an association in the method" technique as Squeak. Paolo |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
> What is possible is: > > self add: (Kernel-Array new: 4). > > Here, #- is a message. > > Michael. And what is Array? :-) I understand that you could use "Kernel-#Array" or something similar, but "Kernel/Array" seems hard to get right in the compiler. Paolo |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Brent Pinkney-2
Hi!
> Hi Chris, > >> Even in todays phat images, name collisions are the 1% case, so the >> solution should have the benefit of being invisible 99% of the time, >> and handling the problem as simply and elegantly as possible that 1% >> of the time. Göran's approach seems to do this. > > You could argue that for most of the constructs in the image. > > Almost all classes use the default Metaclass hierarchy. Should we remove > those? > Almost all classes are pretty shallow subclasses of Object: Should we > limit the image to a depth of 3 or 4? > > What is requires is a really eleganct unconstrined solution which is > transparent for 99% of the cases but entirely open to modifications for > the 1%. > The Metaclass implementation is a good example of how this can be done. > Göran's solution does not satisfy these criteria. Please elaborate the criteria you mention. regards, Göran |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
Hi!
> On 9/19/07, [hidden email] <[hidden email]> wrote: >> "Michael van der Gulik" <[hidden email]> wrote: >> > What do you mean by several packages defining names in the same >> namespace? >> > Are you talking about method overrides? Then like I said before, I >> can't >> > work out how to do this without creating a security issue (I'm >> planning >> on >> > Packages containing completely untrusted code which can be securely >> execute= >> > d locally). >> >> I am not talking about method overrides, no. I am simply talking about >> package P1 defining a class X in N1 and package P2 defining class Y in >> N1. Nothing magical. :) > > > My implementation handles this fine. In this case, you'd have P1 > containing > N1::X (using Krampe notation) and P2 containing N1::Y. The import list of > your code using X and Y would include P1 and P2 (import lists contain only > other Namespaces, and Packages are Namespaces). If I understand you correctly (there are lots of assumptions here that I am not totally getting) - you are saying: - Package IS a Namespace. - Two packages CAN define names in the same namespace. I may be daft but I don't get it. So P1 "contains" N1 and so does P2? And a package IS a Namespace? So N1 can appear in multiple places in your hierarchy, is that what you mean? regards, Göran |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Igor Stasenko
Hi!
> Before we having a working namespaces system with working tools, we > cannot get a taste of it, and therefore there's nothing to discuss > about syntax of namespaces. Mine is available on SM, I think Michaels is also available to taste. > Just release a code with any syntax you like and just note that It can > be subject of change. > Syntax is inferior to design. Changing syntax is a 10 minutes task, > but changing system behavior to work with namespaces is not so > straightforward. > So, at first place we should discuss the design, which is most important > thing. I agree. :) > As for me, i see nothing 'groundbreaking' in removing global namespace > (which is system dictionary). My proposal does not remove it btw. > I see nothing awful in having classes with same names in system, since > they rooted in different categories (named packages/namespaces or > something else) there's no way how you can get confused with > ambiguousness. > For example in package #Zoo , you can see a class #Duck and you know > that its a duck :) > and in package #Man-Moves, a class #Duck is something else. I see no > ways how this can lead to ambiguousness and confusion. Well, in many cases you are right. But in some cases it can get confusing. Take a class named "Component" or "Manager" or "Date". But this goes to the core of my idea, I want collisions to be "visible" but "handled" instead of hidden away. In a classical conventional approach you create a sandbox and put your classes there. You can then create Seaside::TcpService and use it and don't even notice you actually created a short name that is colliding with another namespace (let's imagine KomServices had a Namespace too). In my proposal these collisions are made visible in the sense that if a lot of people use BOTH KomServices and Seaside (which a lot do) then they will notice because even though everything WORKS FINE the references will read out in qualified form and when you type TcpService (in a third other namespace) you will be asked which one you mean. I am saying this is GOOD because it will "gently guide" ourselves into at least trying to not overloading the same names that other namespaces use. At least those namespaces that tend to be used a lot together - and thus occupy neighboring braincells in developers. Recall that this is a HUMAN problem, not a technical one. HUMANS have one single shared namespace that we try to keep track of stuff in. If lots and lots of people start reusing the same short name for different things we WILL get confused no matter if the computer is fine with it. :) > Everyone living with methods which have same selector, but doing > different things for different classes. How making classes with same > names, but doing different things can be considered awful and > inappropriate? Not *awful* but something we should try to keep at a reasonable level and avoid if at all possible. My proposal making short name collisions "visible but handled" is IMHO a mechanism to do that. If we use "pessimistic sandboxes" we invite people to make duplicate short names, IMHO. > So, i insist, that before saying 'no way, i never accept that', better > give it a try and see how changes complicate or simplify development > process. Agree. regards, Göran |
|
|
On Wed, 19 Sep 2007 01:18:41 -0700, Göran Krampe <[hidden email]> wrote:
> Recall that this is a HUMAN problem, not a technical one. HUMANS have one > single shared namespace that we try to keep track of stuff in. If lots > and lots of people start reusing the same short name for different > things we > WILL get confused no matter if the computer is fine with it. :) Oh, no, humans have more namespaces than the most seasoned Java or .NET programmer could imagine, and we usually don't supply the literal context! If I say program, I'll expect you to fill in the right namespace(s). television.program work.program government.program football.program computer.education.program computer.code.program (Forgive my use of "." here. Pascal programmers have been using "." since the introduction of "units", which solved both namespace and package problems.) All that aside, Goran's plan seems to address the problem (and nothing else) with a minimal amount of pain, and has the virtue of being currently usable (I think). It also raises the interesting issue of what problems we should be using tools to solve versus what the language should solve, which I'm not sure gets the proper attention. Goran, I missed what would happen with existing classes, like "Array". Would existing packages have to be given namespace designations? ===Blake=== |
Re: Quick comparison of two Namespaces proposals
|
|
Hi!
> On Wed, 19 Sep 2007 01:18:41 -0700, Göran Krampe <[hidden email]> wrote: >> Recall that this is a HUMAN problem, not a technical one. HUMANS have >> one >> single shared namespace that we try to keep track of stuff in. If lots >> and lots of people start reusing the same short name for different >> things we >> WILL get confused no matter if the computer is fine with it. :) > > Oh, no, humans have more namespaces than the most seasoned Java or .NET > programmer could imagine, and we usually don't supply the literal context! > If I say program, I'll expect you to fill in the right namespace(s). > > television.program > work.program > government.program > football.program > computer.education.program > computer.code.program > > (Forgive my use of "." here. Pascal programmers have been using "." since > the introduction of "units", which solved both namespace and package > problems.) Well, philosophically I agree - people have "lots of namespaces" but as you also imply - we usually communicate with "short names" and we tend to try to not have multiple meanings of the word "program" WITHIN the same context. In software engineering we have one meaning of "program", and not three. > All that aside, Goran's plan seems to address the problem (and nothing > else) with a minimal amount of pain, and has the virtue of being currently > usable (I think). It should be usable - IIRC there was one or two small problems left to figure out regarding fileouts or something, I don't recall. But AFAICT it is 90% done. If a few of us grabbed it and sat down we should be able to get it flying quickly. OOPSLA comes to mind, I am going there btw. > It also raises the interesting issue of what problems we > should be using tools to solve versus what the language should solve, > which I'm not sure gets the proper attention. > > Goran, I missed what would happen with existing classes, like "Array". > Would existing packages have to be given namespace designations? Nope! In the beginning I was going with the idea of turning "top level categories" into Namespaces (Kernel, Collections, Graphics etc) but someone pointed out to me that... "why?". And that person was IMHO right - there is no real point in doing that AFAICT. Even though it could probably work quite easily - but why bother? So no, when you install my Namespaces proposal into your image nothing much happens. Your classes are there just like before, there are no Namespace instances around until you start making classes named Blabla::Something and if you don't WANT to you can just continue like before - you can even ignore it totally and use old fashion prefixing. :) Hopefully then people can start using the new prefixing for new code and hopefully also convert old prefixed code bases to it. regards, Göran |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Paolo Bonzini-2
On 9/19/07, Paolo Bonzini <[hidden email]> wrote:
Array is a class.... which the Kernel namespace uses to look up.... oh, I see your point. Okay, bad design :-P. Gulik. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Göran Krampe
On 9/19/07, Göran Krampe <[hidden email]> wrote: Hi! Well... kind of. I'll explain it in code: Package is a subclass of Namespace; Namespace is a subclass of Dictionary. p1 := Package new. n1 := Namespace new name: #Namespace1. p1 at: #Namespace1 put: n1. " should be p1 addNamespace: n1. " n1 at: #X put: X. p2 := Package new. n2 := Namespace new name: #Namespace1. p1 at: #Namespace1 put: n2. n2 at: #Y put: Y. Now, if you add both p1 and p2 to your local import list, you can refer to Namespace1.X and Namespace1.Y. Does this answer your question? Regards, Gulik. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
On 18/09/2007, Michael van der Gulik <[hidden email]> wrote:
> Period works okay if Period followed by whitespace is an expression > separator, and period followed by a printable character can be part of a > name. granted > What's a variadic message? With unknown number of arguments (e.g. implicitely passing a collection of values). It's not in smalltalk but Ian Piumarta thought of in for Pepsi, and it is a plausible future extension. > I'm not sure what the status of underscores are. Currently I think they're > still a hack for the back-arrow in the squeak image, and from what I hear > they are not accepted in Croquet? It is possible to free them up and make > people use either a Unicode back-arrow :-) or :=. Well my suggestion was more a joke, knowing that there would be technical problems because _ is not completely eliminated yet. But still, it would be nice to reclaim that character for other purposes. -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Damien Pollet
Isn't underscore used for assignment?
On 9/18/07, Damien Pollet <[hidden email]> wrote:
On 18/09/2007, Brent Pinkney <[hidden email]> wrote: |
|
|
In reply to this post by Michael van der Gulik-2
On Wed, 19 Sep 2007 02:33:19 -0700, Michael van der Gulik
<[hidden email]> wrote: > On 9/19/07, Paolo Bonzini <[hidden email]> wrote: >> >> >> > What is possible is: >> > >> > self add: (Kernel-Array new: 4). >> > >> > Here, #- is a message. >> > >> > Michael. >> >> And what is Array? :-) I understand that you could use "Kernel-#Array" >> or something similar, but "Kernel/Array" seems hard to get right in the >> compiler. >> > > Array is a class.... which the Kernel namespace uses to look up.... oh, I > see your point. > > Okay, bad design :-P. I was looking at it more like: self add: (Kernel-#Array new: 4). But I guess without the # the namespace object wouldn't see "Array" it would only see an undefined object? |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
Are the classes aware of their namespace?
In which case, your security might be broken AnyPublicClass namespace class allInstances detect: [:e | e name = #Smalltalk]. Anyway, no need for namespace at all, just a: (AnyPublicClass withAllSuperclasses last allSubclasses detect: [:e | e name = #SystemDictionary]) allInstances etc... Sorry, you might have to restrict available messages too... Michael van der Gulik a écrit : > > Naming collisions aren't my concern. > > I want to be able to load untrusted code and run it, securely. > > This means that I need a unit for loading remote code, thus the package > was born. It also means I need to have complete control over what that > remote code has access to. If you give untrusted code access to the > global SystemDictionary, it has access to everything (which I consider > bad practice). To solve this, I've been working on a design for > Namespaces that lets a code loader show a certain amount of discretion > about what a package has access to ( i.e. the import lists). > > Answering your points directly, I'm hoping that my tools will not be > that difficult to use so that even power users can use them. The import > lists should usually be automatically populated by the NamespaceBrowser. > > As with smaller images, naming collisions only require two loaded > packages to happen (even on the smallest image), and I'd find it pretty > damn annoying if they happen for 1% of all class names. That's every > third or fourth package. > > Gulik. > > > ------------------------------------------------------------------------ > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |