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 that since 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 from more detailed to less detailed, this analysis on java applications would fail because unlike how it would appear, the namespaces aren't actually scoped.
I'm not sure that I get it. I have the impression that we need a scenario to understand how we could model the interaction between package and namespace 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 from java 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 nested in a package A; but next to that, it results in 2 namespaces namespace A 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 I'm confused.
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 relationship.
I can only agree on this. Data and logic should be handled as memory and 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 :)