Hi!

> Andreas Raab <andreas.raab at 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