Computational Theology Gilad Bracha's Sun Weblog

Posted by eu on April 04, 2006 at 03:13 PM PDT #

Posted by Gilad Bracha on April 04, 2006 at 05:20 PM PDT #

Posted by Ionutz on April 04, 2006 at 11:52 PM PDT #

Posted by Dave on April 05, 2006 at 05:10 AM PDT #

It's probably both (1) too complex and (2) too open-ended and rule-based to be part of the language, but you might take a look at Macker for ideas:

http://innig.net/macker/

It lets you define pattern-based rules that enforce exactly the kinds of large-scale modularity you're talking about. An interesting effect of its pattern-based approach is that modularity rules can cut across packages in interesting ways, and can limit both ends of the dependency -- i.e. "only database classes can use this database API," instead of a superpackage's more limited of "anybody anywhere can access this database API."

That said, the more hierarchical approach you're outlining makes a lot more sense as a language feature.

Aside 1: I think the annotation approach Inigo suggests is promising.

Aside 2: Should superpackages nest?

Posted by Paul Cantrell on April 05, 2006 at 12:45 PM PDT #

Posted by Dalibor Topic on April 06, 2006 at 06:49 AM PDT #

If you don't want a package to be visible to the entire world but only to a specific scope, what about to add a new 'protected' class modifier where the class isn't just visible in the single package containing it (as using the default modifier), but also in the sub-packages and in the 'root' package of the hierarchy? A simple example:

com.pany.api
com.pany.api.internal

In this case, we could think about the package 'internal' containnig only 'protected' classes, i.e. those we use in the whole API, but not exposing them to the entire world.

The 'root' package could be 'com' or maybe the first package in the hierarchy containing a class. In our example probabily 'com' and 'pany' wouldn't contain anything, so that the root package could be 'api'. This way we could use the 'internal' package since from the 'api' to the inside of the hierarchy, but not outside of it.

I have a project which have some classes I would like to put into a separate package, since they are used in the whole project (package visibility don't works), but I wouldn't like to expose them to the user. Actually the only thing I can do is suggesting the user for don't using that package, using name convention such as calling this package 'support' or 'private'.

I hope something good for us raises from your idea :)

Posted by Renato on April 06, 2006 at 02:29 PM PDT #

Posted by Carsten Saager on April 07, 2006 at 03:34 AM PDT #

Posted by Gilad Bracha on April 07, 2006 at 03:03 PM PDT #

package superpackage;

/** Collection of a public classes (imported with one import statement) */
public class SuperPackage0 {
    public static class Public0 {}
    public static class Public0a {}
}


package superpackage;

/**
 * Collection of a package class and an internal class
 * (imported with one import statement)
 */
public class SuperPackage1 {
    static class Package1 {}
    private static class Internal1 {}
}

package superpackage;

// import other super packages - one import per collection
import static superpackage.SuperPackage0.*;
import static superpackage.SuperPackage1.* ;

/** Demonstrate package access */
public class SuperPackage2 {
    static class Package2 {}
    private static class Internal2 {}
    private static class Test {
        Public0 publicAccessAnotherSuperPackage = new Public0();
        Public0a publicAccessAnotherSuperPackageA = new Public0a();
        Package1 packageAccessAnotherSuperPackage = new Package1();
        // Internal1 internalAccessAnotherSuperPackage = new Internal1(); - No Access!!!!
        Package2 packageAccessOwnSuperPackage = new Package2();
        Internal2 internalAccessOwnSuperPackage = new Internal2();
    }
}

public static package SuperPackage1 {
    class Package1 {}
    private class Internal1 {}
}

Posted by Howard Lovatt on April 09, 2006 at 05:08 PM PDT #

Gilad replied by email (by email because this site was down) to my post above about using static class members as a super package. His points were:

1. Using static classes in this way is a bit ugly (especially at the binary level) and a bit beyond many developers.

2. It doesn't provide VM enforcement of all the access restrictions that appear at the language level.

3. It doesn't nest.

All of which are of course correct, but I don't think they are a show stopper (but see below). The static packages have other advantages, in partricular anything static can be included. This is very useful for static factories for generics, e.g.:

package superpackage;

import static java.lang.System.*; // using an existing super package!

public class Tuples {
    protected Tuples() {} // Nearest to: no instances, but can still extend
    public static class T1< E1 > {
        public final E1 e1;
        public T1( final E1 e1 ) { this.e1 = e1; }
        public String elementsAsString() { return "e1=" + e1; }
        @Override public String toString() {
            return "[" + elementsAsString() + "]";
        }
    }
    public static < E1 > T1< E1 > t( final E1 e1 ) {
        return new T1< E1 >( e1 );
    }
    public static class T2< E1, E2 > extends T1< E1 > {
        public final E2 e2;
        public T2( final E1 e1, final E2 e2 ) {
            super( e1 );
            this.e2 = e2;
        }
        @Override public String elementsAsString() {
            return super.elementsAsString() + ", e2=" + e2;
        }
    }
    public static < E1, E2 > T2< E1, E2 > t( final E1 e1, final E2 e2 ) {
        return new T2< E1, E2 >( e1, e2 );
    }
    // Etc.
    public static void main( final String[] notUsed ) {
        out.println( t( 'A', 'B' ) ); // Very nice syntax!
    }
}

Which prints <code>[e1=A, e2=B]</code>.

In light of Gilad's comments, maybe a slight language extension would be useful:

1. Allow <code>package</code> to be used like <code>class</code> (suggested above), e.g.:

public package {
  // Only static members
  // No constructors
  // Can be extended - adds concept of extending a package
  // Illegal to make an instance of it
  // But otherwise behaves like a class with static members
}

2. Allow <code>import</code> to appear inside a block so that it becomes block structured. Allow it to be placed anywhere in the block, not just at start; imported memembers are available throughout the block, just like other members.

3. Add <code>export</code> that is syntactically like the block <code>import</code> described above and if a package or class is imported then the exported classes etc. are also imported.

4. Allow <code>import export [static] package_name_pattern;</code> to mean that the members are both imported and exported.

Posted by Howard Lovatt on April 10, 2006 at 07:21 PM PDT #