How to emulate C# 'internal' access modifier?

[z-man]

Hi all

Is there a way to emulate the (cross-package) assembly access modifier
"internal" of C#?
I need to let some classes *within* the same assembly (you know: the
same JAR) to cooperate, despite belonging to distinct (yet omogeneous)
packages, the way it's achieved in C# assemblies using the "internal"
modifier.

This is an example:

package myProject.util;
import myProject.core.*;
public class Widget{
...

Proof proof = new Proof();
// Should call across the packages...
proof.setTitle("You method work, don't you?");
}

package myProject.core;
public class Proof
{
public String getTitle(){...}

// This is problematic...
void setTitle(String value){...}
}

Thank you for your advise!

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Is there a way to emulate the (cross-package) assembly access modifier
"internal" of C#?
I need to let some classes *within* the same assembly (you know: the
same JAR) to cooperate, despite belonging to distinct (yet omogeneous)
packages, the way it's achieved in C# assemblies using the "internal"
modifier.

Java does not support access control by deployment unit.

Best workaround could be one jar = one package and
default package visibility.

Arne

 

[z-man]

Java does not support access control by deployment unit.

Best workaround could be one jar = one package and
default package visibility.

Arne

Thank you, Arne!

The lack of such a scope modifier is, anyway, a shame, IMHO...

 

[opalpa]

Breaking access rules is questionable. Given that you want to do that
is it true that you want to do it for a handful of methods or do you
want to be able to access alot of methods?

Say that setTitle is the only one you need:

Can't you make:

package myProject.core;
public class BulletHole extends Proof {
public void externalTitleSet(String tit) {
validate(tit); // assuming setTitle is package private for a
reason
setTitle(tit);
}

}

The lack of such a scope modifier is, anyway, a shame, IMHO...

The lack of such a scope modifier means that deliberate choices I made
carefully are not ignored wholesale.

Cheers,
Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Michael Rauscher]

....

The lack of such a scope modifier is, anyway, a shame, IMHO...

No, it isn't. JARs aren't part of the Java language.

Bye
Michael

 

[Ed]

Michael Rauscher skrev:

No, it isn't. JARs aren't part of the Java language.

Bye
Michael

I think an access modifier between package-private and global would be
a great thing for Java; so that a class could be visible to a specified
group of packages and not to all others.

I don't know C#, but this internal modifier comes damn close: it's just
a pity that they link it to assmeblies (deployment units) rather than
to plain-ol' namespaces. I'd agree that thinking in jars isn't too
useful during design (though thinking in terms of deployment (on
multiple processors) is often crucial).

..ed

 

[Michael Rauscher]

Michael Rauscher skrev:


I think an access modifier between package-private and global would be
a great thing for Java; so that a class could be visible to a specified
group of packages and not to all others.

Yep and I agree that it shouldn't depend on JARs or deployment units.

It shouldn't be hard to introduce a namespace for grouping packages
together. A "group" keyword in conjunction with an "internal" keyword
should be enough. No need to have "physical" things like (JAR-)files,
directories etc.

package xyz group a.b.c;
internal class A {}

package abc group a.b.c;
class B {
A a;
}

Something like this would be a fine thing I think.

Bye
Michael

 

[z-man]

Yep and I agree that it shouldn't depend on JARs or deployment units.

It shouldn't be hard to introduce a namespace for grouping packages
together. A "group" keyword in conjunction with an "internal" keyword
should be enough. No need to have "physical" things like (JAR-)files,
directories etc.

package xyz group a.b.c;
internal class A {}

package abc group a.b.c;
class B {
A a;
}

Something like this would be a fine thing I think.

Bye
Michael

Yeah, that's the whole point!
I admit that my thought was simplistic, rough and inappropriate (I agree
that deployment units, both JARs and assemblies, are inappropriate for
language scoping).
Anyway, I think that your insight about package grouping solves the
whole problem with an elegant solution.

Wouldn't it be nice to submit such a proposal to the Community Process?

Best Regards.

 

[Ed]

z-man skrev:

Yeah, that's the whole point!
I admit that my thought was simplistic, rough and inappropriate (I agree
that deployment units, both JARs and assemblies, are inappropriate for
language scoping).
Anyway, I think that your insight about package grouping solves the
whole problem with an elegant solution.

Wouldn't it be nice to submit such a proposal to the Community Process?

One of the Sun boys had a proposal, I only heard about it from Mister
Hawtin the other day: I'm waiting to contact the Gilad when he next
accepts comments on his blog:
http://blogs.sun.com/gbracha/entry/developing_modules_for_development

And as a matter of interest, I had almost the exact same idea as Mister
Rauscher:
http://www.edmundkirwan.com/servlet/fractal/frac-page56.html

..ed

 

[Bill Medland]

Yep and I agree that it shouldn't depend on JARs or deployment units.

It shouldn't be hard to introduce a namespace for grouping packages
together. A "group" keyword in conjunction with an "internal" keyword
should be enough. No need to have "physical" things like (JAR-)files,
directories etc.

package xyz group a.b.c;
internal class A {}

package abc group a.b.c;
class B {
A a;
}

Something like this would be a fine thing I think.

Bye
Michael

But then isn't someone in a year or two going to ask for the next layer
outside the group?
Why not go with the equivalent of the C++ "friend" concept, with explicit
specification of "non-normal" relationships.

(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)

 

[Michael Rauscher]

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

 

[Michael Rauscher]

And as a matter of interest, I had almost the exact same idea as Mister
Rauscher:

That's no suprise to me as it's seems to be really obvious

Bye
Michael

 

[Bill Medland]

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)

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?

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

The lack of such a scope modifier is, anyway, a shame, IMHO...

A Java jar file is not a good unit to base
accessibility on, because classes can be added to
it later.

A .NET DLL is (as far as I know) immutable.

Arne

 

[Michael Rauscher]

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?

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?

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

 

[Ed]

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)

For an example, see:
http://www.edmundkirwan.com/servlet/fractal/frac-page54.html

..ed

 

[Bill Medland]

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).

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?

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.

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.

 

[z-man]

Bill Medland schrieb:

[snip]

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?

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.

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.

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]

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.

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.

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/...mstone/persistence/collections/CuHashMap.html
[6]
http://www.saxonica.com/documentation/javadoc/com/saxonica/schema/SchemaTypeImpl.html
[7]
http://download.eclipse.org/tptp/4....rm/analysis/core/history/AnalysisHistory.html