On 27 nov. 07, at 02:02, Toon Verwaest wrote:
Stéphane Ducasse wrote:
>>> I thought about it and I would like to have
>>> java package -> extracted as package
>>> smalltalk package -> as package
>>> smalltalk namespace -> as namespace
>>> Is it what you had in mind?
>> I don't necessarily think that package equals namespace in Java
>> either. There are the same amount of namespaces as packages, but
>> unlike packages, the namespaces are not nested, right?
> Not really since java packages have more scope than Smalltalk ones.
> See what johan is saying.
Euhm... I am saying something very similar to what johan and you say,
Ok so I did not understand it.
in that piece. Johan just transforms this statement into saying
this information is "double", lets throw the namespace version away
(since it is not nested, while packages -are-, so packages are the
greater source of information); and move the package version as the
namespace version, since they also affect how classes are scoped.
This is ok on the one hand, however, if we would do analysis based on
this setting, considering namespaces to be scoped and lookup to go
more detailed to less detailed, this analysis on java applications
fail because unlike how it would appear, the namespaces aren't
I'm not sure that I get it. I have the impression that we need a
to understand how we could model the interaction between package and
But I do not find one besides I want to analyze references between
packages (and it may involved
namespaces in java and VW but not in Squeak for example).
>> Well on the other hand, namespaces are obviously deducable
>> packages, so I guess it makes sense to just have packages and write
>> code to get the namespace info (which is more or less important
>> because package belongsTo != namespace belongsTo for java).
This is also what I am saying here. An example:
package A contains package B. This results in having a package B
in a package A; but next to that, it results in 2 namespaces
and namespace A::B, which are not nested.
yes. for me a package contains entities: classes methods but their
names are looked in a flat
way. Now for a namespace it contains classes methods.... but names
are looked up in a scoped way.
So may be namespace is a kind of packages at the end.
Thus just replacing the word
package by namespace,... well... is fine by me since it seems logical.
But... handle with care.
So can you sum up in another email what would be your solution because
> In the past we duplicated all the logic for package in namespace too.
> And this is not cool.
So does anybody have an idea how to handle transitive closure of
I can only agree on this. Data and logic should be handled as
processor friendly as possible. Until recently I was working on a 1ghz
laptop with 300 meg of RAM. Can you imagine the horror?
Yes but may be this should not be our target application :)