27 Nov
2007
27 Nov
'07
11:27 a.m.
On 27 nov. 07, at 02:02, Toon Verwaest wrote:
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.
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 :)
Stéphane Ducasse wrote:
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.
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?
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. 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.