Hi!
Andreas Raab andreas.raab@gmx.de writes:
J J wrote:
You bring up good points, but how would you implement something like this in smalltalk? A "compilation unit" (and thus a lookup context) in python is a file. A "compilation unit" in smalltalk is a method.
Sure, but this is not about a "compilation unit" it's about a scope. Such a scope can easily be defined, system categories or Monticello packages are good candidates.
It might work out well to equate all of these things. Packages, categories, and naming prefixes would be the same thing.
I do not know for sure whether this would all work out, but it seems fine on the surface. The result would be easy to think about, because programmers would not have to split hairs about, e.g., categories versus packages. It should also produce shorter code, because you could have one declaration (package foo) instead of three (package foo, namespace foo, category foo).
-Lex
I agree that simplicity/unification is good in principle. One problem would be that it would "force" us to have more namespaces than we actually need. For example, I think base Squeak should just be one namespace - the "Smalltalk one" which has no prefix.
So if we equal namespace to either package or category that would instead create tons of them.
IMHO we have four concepts here that are different even though they may seem similar:
- Categories. This is a pure organisational unit so that we can find stuff more easily. Sure, PI today "uses" them to create Packages, but that is just a trick, albeit a nice one since it creates a mapping between categories and packages which is actually pretty nice.
- Packages. Manifested as PIs and used practically as MC packages. This is a "developer unit" IMHO.
- Namespace. As I said I think it is about a group of humans maintaining a space of unique names. An example is a project like Seaside operating much on its own with a group of developers. Another example is official basic Squeak.
- Module. The best definition of a module that I can recall was the one saying that it is a "separately deployable unit". It is about deployment. We don't have this today IMHO. Package (above) comes closest with its MC's, but it is still more of a developer construct instead of a distribution construct.
So would we want one or more of these to unite/overlap? I can't say I do actually, but would easily like to be convinced otherwise. :) Possibly Categories could be removed of course, they fill the least function and Packages more or less fits the bill there.
regards, Göran