Quick comparison of two Namespaces proposals
Locked
12345
12345
Quick comparison of two Namespaces proposals
 
|
Hi folks!
I just read through Michael van der Gulik's page: http://gulik.pbwiki.com/Namespaces Just stumbled over it btw, and I have only read it once and wrote down some notes compared to my own little "venture" in this area: http://swiki.krampe.se/gohu/32 Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and this is mainly addressed to Michael btw. Namespace comments: - I personally think hierarchical namespaces is "too much". I opted for single level namespaces and still think that is enough. - I personally don't like the "." notation for namespaces, especially since we already use "." for statement separation. I still think "::" is the best I have seen, although granted - this is a tiny, tiny detail. - Imports are done in your code "per Namespace" which is immensely better than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all. - I agree that shared pools theoretically could be replaced with Namespaces, but then we actually have imports *per class*, which I really don't like. You may argue, "but we already have them!" - yes, I agree, but I don't like them anyway and in my proposal I opted out by simply ignoring/not touching them. :) - Your Namespaces are linked to a Package scheme, I personally would like to keep these concepts separate. So... to sum it all up: - You also bind at compile time just like globals are bound now (and just as in my code). No difference. - You also reify the namespaces as instances of Namespace, as I do. No difference, though you intend to nuke SystemDictionary - I don't. - You also have a Dictionary protocol on the Namespaces enabling normal dynamic lookup just as I have. Kinda normal if you reify them as objects of course. But... - You go hierarchical, I stayed simple and kept it on one level. - You use ".", I use "::". - Your code use *both* qualified names (long with dot-notation) and non qualified names (short), I *always* use qualified names in the source and only let the tools "render" them short (or accept writing them short) when they are indeed unique or when the user has a policy that allows a lookup - like for example resolving by default to "local names" (in the same Namespace). - You added an explicit import list per Namespace, I opted to not have imports at all. - You coupled Namespaces with Packages, I did not at all go there. So the big differences are the two last ones - Explicit import lists vs my approach of no-imports-render-and-accept-short-names and mixing it with a package concept vs not doing that. :) regards, Göran |
Re: Quick comparison of two Namespaces proposals
|
|
On 17/09/2007, Göran Krampe <[hidden email]> wrote:
> Hi folks! > > I just read through Michael van der Gulik's page: > > http://gulik.pbwiki.com/Namespaces > > Just stumbled over it btw, and I have only read it once and wrote down > some notes compared to my own little "venture" in this area: > > http://swiki.krampe.se/gohu/32 > > Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and > this is mainly addressed to Michael btw. > > Namespace comments: > > - I personally think hierarchical namespaces is "too much". I opted for > single level namespaces and still think that is enough. > > - I personally don't like the "." notation for namespaces, especially > since we already use "." for statement separation. I still think "::" is > the best I have seen, although granted - this is a tiny, tiny detail. > > - Imports are done in your code "per Namespace" which is immensely better > than like for example in Java where it is per class (well, per file, but > anyway). It is still though the major difference with my proposal in which > there are *no* explicit imports at all. > > - I agree that shared pools theoretically could be replaced with > Namespaces, but then we actually have imports *per class*, which I really > don't like. You may argue, "but we already have them!" - yes, I agree, but > I don't like them anyway and in my proposal I opted out by simply > ignoring/not touching them. :) > > - Your Namespaces are linked to a Package scheme, I personally would like > to keep these concepts separate. > > So... to sum it all up: > > - You also bind at compile time just like globals are bound now (and just > as in my code). No difference. > - You also reify the namespaces as instances of Namespace, as I do. No > difference, though you intend to nuke SystemDictionary - I don't. > - You also have a Dictionary protocol on the Namespaces enabling normal > dynamic lookup just as I have. Kinda normal if you reify them as objects > of course. > > But... > > - You go hierarchical, I stayed simple and kept it on one level. > - You use ".", I use "::". > - Your code use *both* qualified names (long with dot-notation) and non > qualified names (short), I *always* use qualified names in the source and > only let the tools "render" them short (or accept writing them short) when > they are indeed unique or when the user has a policy that allows a lookup > - like for example resolving by default to "local names" (in the same > Namespace). > - You added an explicit import list per Namespace, I opted to not have > imports at all. > - You coupled Namespaces with Packages, I did not at all go there. > > So the big differences are the two last ones - Explicit import lists vs my > approach of no-imports-render-and-accept-short-names and mixing it with a > package concept vs not doing that. :) > > regards, Göran > > Besides Namespaces, keeping package dependencies is important thing to make single image holding every known package in squeak universe (by universe i mean all known forks, which currently forced to keep own separated development branches and cannot be used with single image due to many conflicts). With package hierarchies, you can have image working with different forks, and even interoperate them. The idea was to keep own namespace(i.e. - globals and behaviors) for each package, and also keep a list of imported packages. Only single package should not have any imports - its a Kernel package. Any others have at least Kernel in imports. Now, how things going on: suppose you making own package and want to modify some classes/methods in package(s) you import. When you making changes, they going not to imported package, but in your package instead. This is much likely you adding an extensions with MC (adding category *MyPackage extensions to foreign class), but in much more clever way :) Keeping your changed behaviors and names in own package prevents from creating version conflicts with other packages which using old behaviors/classes. Your changes are visible only to your package or any other packages which importing yours. This is most important feature, which allows us to make different versions of tools to live in same image and coexist without conflicts. There of course must be a good tools to support development in such environment. Since any changes you making must go to some package (like with changesets), developer must always know to which package he's doing changes. - for any package in system, which haves at least a single export (imported by another package, or marked as a 'release' package), you are unable to modify it contents. Instead, you must keep changes with other package - either by creating a new version of it, or by adding changes to your own package, which make use of it. An update operation is pretty simple. Suppose i maintainer of package X, which currently imports packages Y 1.0 and Z 1.0. Now i want to update my package to use Y 2.0 and Z 3.0. I simply clicking 'update imports', and creating a new separate version of my package with replaced imports. Now i can run tests/debug e.t.c. When i considered that all is fine, now i can set it as default 'release' version and publish it. The overall idea is simple: make your code available/visible only to those who wants to use it (by imports). So, you don't need to harvest entire image to find out source of problem, and you will never fear installing updates , because they are unable to make existing code nonfunctional. -- Best regards, Igor Stasenko AKA sig. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Göran Krampe
Hi Göran, all.
On 9/17/07, Göran Krampe <[hidden email]> wrote:
Hi folks! We already have hierarchical categories in Squeak. For example, "Kernel-Chronology-Tests". I'm making hierarchical namespaces available, but you don't have to nest things more than one level deep if you don't like that style. - I personally don't like the "." notation for namespaces, especially Meh. I like the dots; they look tidy. If you can give me a good reason not to use them then I'm happy to change. - Imports are done in your code "per Namespace" which is immensely better To be honest, I've never really used shared pools, so I don't know much about how they're used. In my conversion (categories->namespaces) code, I turn a shared pool into a sub-namespace of the class they appear in (ooh... that could be a bug...). I haven't tested this yet. For the meanwhile I've left class pools as they are. - Your Namespaces are linked to a Package scheme, I personally would like (background for people: Package is a subclass of Namespace and forms the root of a namespace hierarchy). Why is this a bad thing? Could you be more specific? If anybody is interested, an old and very buggy version is available on the PackageUniverses. Install the "NamespacesBrowser" package and then evaluate "NamespaceBrowser example" (IIRC?) to open it. Newer versions which work better are available at http://www.squeaksource.com/SecureSqueak. Currently, I can file out and file in a package, manage them, create new classes save methods, open a workspace which only resolves globals from a particular namespace, and create instances of objects in those namespaces. Gulik. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Igor Stasenko
On 9/18/07, Igor Stasenko <[hidden email]> wrote:
Sorry Igor, but I never implemented having overrides of other Packages' classes in a Package. I can't work out how to do it! If anybody knows how without creating an environment for making obscene spaghetti code, please let me know. I admit this is a great loss to the Smalltalkiness of my approach - you can't add methods to String! For the meanwhile, a workaround is to copy the package where the overrided method would have been, modify it and update the imports to use it. My packaging system will make sure that the modified package will be loaded and used rather than the original (without modifying the original package which may also be installed in your image). An update operation is pretty simple. Suppose i maintainer of package This will all work. The "update imports" feature will be there soon. Regards, Gulik (I think I'll use "Gulik" as a handle considering how many "Michaels" there are in the world). |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
Hi!
> Hi Göran, all. > > On 9/17/07, Göran Krampe <[hidden email]> wrote: >> >> Hi folks! >> >> I just read through Michael van der Gulik's page: >> >> http://gulik.pbwiki.com/Namespaces >> >> Just stumbled over it btw, and I have only read it once and wrote down >> some notes compared to my own little "venture" in this area: >> >> http://swiki.krampe.se/gohu/32 >> >> Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and >> this is mainly addressed to Michael btw. >> >> Namespace comments: >> >> - I personally think hierarchical namespaces is "too much". I opted for >> single level namespaces and still think that is enough. > > We already have hierarchical categories in Squeak. For example, > "Kernel-Chronology-Tests". I'm making hierarchical namespaces available, > but > you don't have to nest things more than one level deep if you don't like > that style. Sure, I understand. I *still* would like to stay with a single level. :) My proposal also keeps the "good old global" level (SystemDictionary) in which I would presume most of the standard libraries would still live. > - I personally don't like the "." notation for namespaces, especially >> since we already use "." for statement separation. I still think "::" is >> the best I have seen, although granted - this is a tiny, tiny detail. > > Meh. I like the dots; they look tidy. If you can give me a good reason not > to use them then I'm happy to change. A *good* reason? Hehe, not really. I don't recall the details in lexer/parser etc - adding support for $: inside global names was rather simple - I have no idea if it is just as simple with $. My reasoning behind :: was that it "stands out" in the syntax - you will not accidentally mistake it for something else. The "." is IMHO not at all as clear. For example, what does this code say: self add: Kernel.Array new: 4 Is it the same as?: self add: Kernel. Array new: 4 > - Imports are done in your code "per Namespace" which is immensely better >> than like for example in Java where it is per class (well, per file, but >> anyway). It is still though the major difference with my proposal in >> which >> there are *no* explicit imports at all. >> >> - I agree that shared pools theoretically could be replaced with >> Namespaces, but then we actually have imports *per class*, which I >> really >> don't like. You may argue, "but we already have them!" - yes, I agree, >> but >> I don't like them anyway and in my proposal I opted out by simply >> ignoring/not touching them. :) > > > > To be honest, I've never really used shared pools, so I don't know much > about how they're used. In my conversion (categories->namespaces) code, I > turn a shared pool into a sub-namespace of the class they appear in > (ooh... > that could be a bug...). I haven't tested this yet. For the meanwhile I've > left class pools as they are. > > >> - Your Namespaces are linked to a Package scheme, I personally would >> like >> to keep these concepts separate. > > (background for people: Package is a subclass of Namespace and forms the > root of a namespace hierarchy). > > Why is this a bad thing? Could you be more specific? IMHO a package is a "deployment unit" more than anything else. A namespace on the other hand is a "pool of unique names" that we developers share with each other one way or the other. I can see a package both using and defining names in several namespaces. And I can see several packages defining names in the same namespace. Thus I don't see the need for making a hard connection between the two concepts. BUT... I do of course see many good reasons of finding and reasoning about dependencies between packages by simply looking at the global names they define or use. It has always seemed like the obvious "inputs and outputs" of a package and I bet that we could very easily find 90% of all dependencies just by looking at these names. regards, Göran |
Re: Quick comparison of two Namespaces proposals
|
|
On 9/18/07, Göran Krampe <[hidden email]> wrote:
Hmm. self add: Kernel.Array new: 4. self add: Kernel::Array new: 4. What do other people think? Keep in mind that I only expect people to use this syntax when the import list allows ambiguity in the names. Typically, you'd just see: self add: Array new: 4. because Kernel has been added to the import list. 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 change was this, in pseudo-diff format: Scanner>>xLetter "Form a word or keyword." | type c | buffer reset. [c _ hereChar asciiValue. + ((type _ typeTable at: c ifAbsent: [#xLetter]) == #xLetter or: [type == #xDigit]) + or: [(type == #period) and: [(typeTable at: (aheadChar asciiValue)) == #xLetter]]] - (type _ typeTable at: c ifAbsent: [#xLetter]) == #xLetter or: [type == #xDigit]] ... more method code. >> - Your Namespaces are linked to a Package scheme, I personally would I see nothing wrong with a deployment unit containing a pool of unique names. In my approach, a package does both use and define names in several namespaces. 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 executed locally). If you're talking about defining the same class in multiple packages, then why would you do this? If you're talking about having the same Namespace name (e.g "Collections.String") in multiple packages, then my approach handles that fine (note to self: write a test for this!). BUT... I do of course see many good reasons of finding and reasoning about If there's a need, it is quite easy to make a tool that can show all external dependencies of a package. It's currently quite quick to sort through every namespace in a package and see what the dependencies are. Gulik. |
Re: Quick comparison of two Namespaces proposals
|
|
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
> self add: Kernel.Array new: 4. > self add: Kernel::Array new: 4. > > What do other people think? +10 for :: Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted. - Bert - |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
Hi,
>>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. Your changes allow the following method to be compiled ... x.y ^42 and then ... 1 x.y. evaluates to 42, which is probably not what you intended Cheers, Andy |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Bert Freudenberg
On 9/18/07, Bert Freudenberg <[hidden email]> wrote: On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote: Vote registered. For the near future, there's no need to adopt namespaces into the official image. They can be loaded and used alongside standard Squeak objects. In the far future, if the tools are stable and people find it useful then it would be great to have them in the image. Gulik. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Andrew Tween
On 9/18/07, Andrew Tween <[hidden email]> wrote: Hi, Argh. I saw that too when I cut and paste. Thanks for pointing it out. Gulik. |
RE: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Bert Freudenberg
+1 for ::
Even if it is really self add: (Kernel::Array new: 4). :) Ron > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Bert Freudenberg > Sent: Tuesday, September 18, 2007 6:31 AM > To: The general-purpose Squeak developers list > Subject: Re: Quick comparison of two Namespaces proposals > > On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote: > > > self add: Kernel.Array new: 4. > > self add: Kernel::Array new: 4. > > > > What do other people think? > > +10 for :: > > Though I hope this won't become a bikeshed discussion of syntax, but > actually result in a Namespace solution getting adopted. > > - Bert - > > |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Göran Krampe
>
> - Imports are done in your code "per Namespace" which is immensely > better > than like for example in Java where it is per class (well, per > file, but > anyway). It is still though the major difference with my proposal > in which > there are *no* explicit imports at all. the problem with per namespace is that you can get unanticipated conflicts. here is a scenario that klaus from Smalltalk/x explained to me once you have two namespace N1 A N2 import N1 B method foo ^ B everthing compiles now you add a new class B in N1 and the system does not bark.... a while later you recompile the method foo and now you may be in trouble. I only have 2 min for this email so I let you imagine other scenario. But klaus told me that this was a problem in VW and C++ too. Stef |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Ron Teitelbaum
+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. On Dinsdag, 18 September 2007, Ron Teitelbaum wrote: > +1 for :: > > Even if it is really > > self add: (Kernel::Array new: 4). > > :) > > Ron > > > -----Original Message----- > > From: [hidden email] [mailto:squeak-dev- > > [hidden email]] On Behalf Of Bert Freudenberg > > Sent: Tuesday, September 18, 2007 6:31 AM > > To: The general-purpose Squeak developers list > > Subject: Re: Quick comparison of two Namespaces proposals > > > > On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote: > > > > > self add: Kernel.Array new: 4. > > > self add: Kernel::Array new: 4. > > > > > > What do other people think? > > > > +10 for :: > > > > Though I hope this won't become a bikeshed discussion of syntax, but > > actually result in a Namespace solution getting adopted. > > > > - Bert - > > > > > > > > |
Re: Quick comparison of two Namespaces proposals
|
|
On Sep 18, 2007, at 15:58 , Brent Pinkney wrote:
> +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. This is indeed elegant - however, it "hides" the classes from tools, like, if you want to find references to "Kernel Array". > The other solutions lack this elegance. Well, in Göran's version there simply is a global named #Kernel::Array which I find quite elegant too (if you like TSTTCPW). It's even hardly a "namespace" so much as it is a formalization of prefixes. - Bert - |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Brent Pinkney-2
On 18/09/2007, Brent Pinkney <[hidden email]> wrote:
> > +10000 for: > > self add: (Kernel Array new: 4). Nice :) Period has a potential conflict with expression separator, and double-colon could be kept for variadic messages or argument-related stuff (currently, when there is a colon, an argument is not far, so it would be nice to keep this association). What about underscore, since it's not used elsewhere in the syntax ;-) Kernel_Array looks like an identifier, Kernel _ Array can be a binary message... > 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. > > On Dinsdag, 18 September 2007, Ron Teitelbaum wrote: > > +1 for :: > > > > Even if it is really > > > > self add: (Kernel::Array new: 4). > > > > :) > > > > Ron > > > > > -----Original Message----- > > > From: [hidden email] [mailto:squeak-dev- > > > [hidden email]] On Behalf Of Bert Freudenberg > > > Sent: Tuesday, September 18, 2007 6:31 AM > > > To: The general-purpose Squeak developers list > > > Subject: Re: Quick comparison of two Namespaces proposals > > > > > > On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote: > > > > > > > self add: Kernel.Array new: 4. > > > > self add: Kernel::Array new: 4. > > > > > > > > What do other people think? > > > > > > +10 for :: > > > > > > Though I hope this won't become a bikeshed discussion of syntax, but > > > actually result in a Namespace solution getting adopted. > > > > > > - Bert - > > > > > > > > > > > > > > > > > > -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org |
|
|
Damien Pollet a écrit :
> On 18/09/2007, Brent Pinkney <[hidden email]> wrote: > >> +10000 for: >> >> self add: (Kernel Array new: 4). >> > > > What about underscore, since it's not used elsewhere in the syntax ;-) > Kernel_Array looks like an identifier, Kernel _ Array can be a binary message... > uppercase word have no meaning ? self add: (KERNEL Array new:4) cédrick |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Ron Teitelbaum
Oh no, are people really so strongly for ::? It make source code look
absolutely awful. The period looks a thousand times better, but I don't think there is a non-ambiguous way to do it. What about message style sytax? e.g. self add: (Kernel Array new: 4) ? That looks much better to my eyes, though it does force a trade off: do we find a way of complicating the compiler that the above is resolved at compile time, or do we take the run time lookup hit? In any event, please don't go with ::, and if you must at least please don't put this in the default image. On 9/18/07, Ron Teitelbaum <[hidden email]> wrote: > +1 for :: > > Even if it is really > > self add: (Kernel::Array new: 4). > > :) > > Ron > > > -----Original Message----- > > From: [hidden email] [mailto:squeak-dev- > > [hidden email]] On Behalf Of Bert Freudenberg > > Sent: Tuesday, September 18, 2007 6:31 AM > > To: The general-purpose Squeak developers list > > Subject: Re: Quick comparison of two Namespaces proposals > > > > On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote: > > > > > self add: Kernel.Array new: 4. > > > self add: Kernel::Array new: 4. > > > > > > What do other people think? > > > > +10 for :: > > > > Though I hope this won't become a bikeshed discussion of syntax, but > > actually result in a Namespace solution getting adopted. > > > > - Bert - > > > > > > > > |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Brent Pinkney-2
+1000000! Down with the hideous :: :)
On 9/18/07, Brent Pinkney <[hidden email]> wrote: > > +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. > > On Dinsdag, 18 September 2007, Ron Teitelbaum wrote: > > +1 for :: > > > > Even if it is really > > > > self add: (Kernel::Array new: 4). > > > > :) > > > > Ron > > > > > -----Original Message----- > > > From: [hidden email] [mailto:squeak-dev- > > > [hidden email]] On Behalf Of Bert Freudenberg > > > Sent: Tuesday, September 18, 2007 6:31 AM > > > To: The general-purpose Squeak developers list > > > Subject: Re: Quick comparison of two Namespaces proposals > > > > > > On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote: > > > > > > > self add: Kernel.Array new: 4. > > > > self add: Kernel::Array new: 4. > > > > > > > > What do other people think? > > > > > > +10 for :: > > > > > > Though I hope this won't become a bikeshed discussion of syntax, but > > > actually result in a Namespace solution getting adopted. > > > > > > - Bert - > > > > > > > > > > > > > > > > > > |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Michael van der Gulik-2
On 9/18/07, Michael van der Gulik <[hidden email]> wrote:
> > What do you mean by several packages defining names in the same namespace? He means: Namespace - a collection of symbols inside a space, Package - A group of symbols, etc. that form some kind of deployment unit via MC, etc. |
Re: Quick comparison of two Namespaces proposals
|
|
In reply to this post by Jason Johnson-5
On Sep 18, 2007, at 18:09 , Jason Johnson wrote:
> Oh no, are people really so strongly for ::? I'm rather strongly against ".". And not only because the dot is already too overloaded in Smalltalk. Dot-notation is becoming ubiquitous in "pop CS" to the point where people don't even admit there are alternatives. In one German state teaching "dot notation" to kids is made mandatory by the school administration, ruling out the use of Smalltalk as a teaching language. I kid you not. Having it creep into Squeak would make this individual sad. If this means anything to anybody ;) - Bert - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |