Bill Medland schrieb:
>> Ed schrieb:
>>> Michael Rauscher skrev:
[quoted text clipped - 30 lines]
> But then isn't someone in a year or two going to ask for the next layer
> outside the group?
Example?
One might declare a package to belong to more than to one group by comma
separated lists, e.g.
package abc group a.b.c, d.e.f;
Also, I could image the usage of wildcards, e. g. to have a package to
belong to immediate subgroups in namespace a.b one could write
package abc group a.b.*;
Or to have a package to belong to all subgroups in namespace a.b one
could write:
package abc group a.b.**;
Why not?
(I've to mention that I haven't really brainstormed on the "solutions" I
gave, so this and the previous are just my short-term thoughts)
> Why not go with the equivalent of the C++ "friend" concept, with explicit
> specification of "non-normal" relationships.
AFAIK C++'s "friend" concept exposes all fields/methods even if they're
private.
> (However I do wonder what is going on in the design if two packages are
> having to work together so deeply that they have informal relationships
> that cannot be permitted for the general public)
You can always declare anything to be public, that isn't the point. The
key is information hiding.
If there's some information (field/method) that should be available only
to a few other packages, why should I allow the public to access it?
Bye
Michael
Bill Medland - 04 Oct 2006 01:44 GMT
> Bill Medland schrieb:
>>
[quoted text clipped - 17 lines]
>>> should be enough. No need to have "physical" things like (JAR-)files,
>>> directories etc.
>> Why not go with the equivalent of the C++ "friend" concept, with explicit
>> specification of "non-normal" relationships.
>
> AFAIK C++'s "friend" concept exposes all fields/methods even if they're
> private.
I vaguely remember being able to do it at the method level (and a quick look
at Stroustrup suggests I am not going out of my mind)
>> (However I do wonder what is going on in the design if two packages are
>> having to work together so deeply that they have informal relationships
>> that cannot be permitted for the general public)
>
> You can always declare anything to be public, that isn't the point. The
> key is information hiding.
from whom?
> If there's some information (field/method) that should be available only
> to a few other packages, why should I allow the public to access it?
Why should information be made available to other packages but not to the
public? If the classes are tightly enough related to warrant access to
each other why are they not in the same package?
> Bye
> Michael

Signature
Bill Medland
Michael Rauscher - 04 Oct 2006 02:47 GMT
Bill Medland schrieb:
>>> Why not go with the equivalent of the C++ "friend" concept, with explicit
>>> specification of "non-normal" relationships.
[quoted text clipped - 3 lines]
> I vaguely remember being able to do it at the method level (and a quick look
> at Stroustrup suggests I am not going out of my mind)
How can one declare which class may access this method?
>>> (However I do wonder what is going on in the design if two packages are
>>> having to work together so deeply that they have informal relationships
[quoted text clipped - 3 lines]
>
> from whom?
From other parts of the system, of course. Do you make all of your
members public or do you declare your instance variables private? From
whom do you want to hide them?
>> If there's some information (field/method) that should be available only
>> to a few other packages, why should I allow the public to access it?
>
> Why should information be made available to other packages but not to the
> public? If the classes are tightly enough related to warrant access to
> each other why are they not in the same package?
Because relationships aren't limited to only two classes?
Bye
Michael
Bill Medland - 04 Oct 2006 18:04 GMT
> Bill Medland schrieb:
>>>> Why not go with the equivalent of the C++ "friend" concept, with
[quoted text clipped - 6 lines]
>
> How can one declare which class may access this method?
OK. I apologise. I got it the wrong way around. You are right; it exposes
the whole class to a specified friend. However it is to a specified
friend, which is the bit that I believe is important. (And we could even
suggest a further restriction that friendliness could be attached to fields
or methods of a class rather than the whole class).
>>>> (However I do wonder what is going on in the design if two packages are
>>>> having to work together so deeply that they have informal relationships
[quoted text clipped - 7 lines]
> members public or do you declare your instance variables private? From
> whom do you want to hide them?
Some things you want to hide from the general public; some things you even
want to hide from your colleagues. Some things are exported capability of
your package, others are shared among the members of the package and others
are restricted to the class. See below.
>>> If there's some information (field/method) that should be available only
>>> to a few other packages, why should I allow the public to access it?
[quoted text clipped - 4 lines]
>
> Because relationships aren't limited to only two classes?
Huh? I never said they were. However if there is a relationship between two
members of two distinct packages that is not permitted between the general
public and the member then I suggest the packaging is wrong.
> Bye
> Michael

Signature
Bill Medland
z-man - 05 Oct 2006 08:02 GMT
>> Bill Medland schrieb:
[snip]
>>>>> (However I do wonder what is going on in the design if two packages are
>>>>> having to work together so deeply that they have informal relationships
[quoted text clipped - 19 lines]
> members of two distinct packages that is not permitted between the general
> public and the member then I suggest the packaging is wrong.
If you limit your reasoning to the established orthodox language
semantics from mama Sun, then you're undoubtedly right to say so.
But considering that, as Ed suggests [1], when projects grow there could
be some necessity to unclutter single bloated packages splitting them
into omogeneous "sub"packages though keeping tight connections among
them. I think that's just a matter of scope granularity and there's no
scandal to request a mid-level (elegant) expansion.
[1] http://www.edmundkirwan.com/servlet/fractal/frac-page54.html
z-man - 05 Oct 2006 13:53 GMT
>>>>> (However I do wonder what is going on in the design if two packages are
>>>>> having to work together so deeply that they have informal relationships
[quoted text clipped - 19 lines]
> members of two distinct packages that is not permitted between the general
> public and the member then I suggest the packaging is wrong.
Real-world examples from authoritative projects where just a weak
comment enforces the proper access to public (though semantically
internal) class members (what an awkward workaround! -- are all THEY
stupid or are YOU wrong?):
org.apache.ojb.broker.Identity constructors [1]
org.apache.xml.utils.StringToStringTable [2]
iwork.state.ReflectionLocalVariable [3]
hp.opencall.media.sms.tl.Parameter [4]
com.gemstone.persistence.collections.CuHashMap [5]
com.saxonica.schema.SchemaTypeImpl [6]
org.eclipse.tptp.platform.analysis.core.history.AnalysisHistory [7]
...
[1] http://db.apache.org/ojb/api/org/apache/ojb/broker/Identity.html
[2]
http://xml.apache.org/xalan-j/apidocs/org/apache/xml/utils/StringToStringTable.html
[3]
http://iwork.stanford.edu/docs/javadoc/iwork/state/ReflectionLocalVariable.html
[4]
http://techsolutions.hp.com/en/6154/hp/opencall/media/sms/tl/Parameter.html
[5]
http://www.facetsodb.com/downloads/facets/doc/api/com/gemstone/persistence/colle
ctions/CuHashMap.html
[6]
http://www.saxonica.com/documentation/javadoc/com/saxonica/schema/SchemaTypeImpl.html
[7]
http://download.eclipse.org/tptp/4.2.0/javadoc/Platform/public/org/eclipse/tptp/
platform/analysis/core/history/AnalysisHistory.html
Bill Medland skrev:
> (However I do wonder what is going on in the design if two packages are
> having to work together so deeply that they have informal relationships
> that cannot be permitted for the general public)
> --
> Bill Medland
For an example, see:
http://www.edmundkirwan.com/servlet/fractal/frac-page54.html
.ed
--
www.EdmundKirwan.com - Home of The Fractal Class Composition.
Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html