Differences between revisions 4 and 5
Revision 4 as of 2004-09-25 22:16:24
Size: 1680
Comment:
Revision 5 as of 2009-09-20 22:01:36
Size: 1680
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
At the risk of violating ["YAGNI"], perhaps better scoping rules are needed. That is, something reminiscent of Java's protected modified, where a extension point would be visible within sub-modules. But what defines a sub-module? A module which has the current (exporting) module's id as a prefix? At the risk of violating [[YAGNI]], perhaps better scoping rules are needed. That is, something reminiscent of Java's protected modified, where a extension point would be visible within sub-modules. But what defines a sub-module? A module which has the current (exporting) module's id as a prefix?

Problem Description

HowardLewisShip, Apr 26 2004, 1.0-alpha-4

In many cases, a particular module will include a number of services and configurations that are internal to that module. Whether for concerns about instability in an API, minimizing knowledge needed by users of a module, or some type of security concern, it makes sense that (sometimes) services and configuration points be visible only within a specific module.

Proposed Solution

Add a visibility attribute to <configuration-point> and <service-point>. It would default to public, but could be set to private.

There would need to be some number of API changes to faciliate this as well.

Discussion

At the risk of violating YAGNI, perhaps better scoping rules are needed. That is, something reminiscent of Java's protected modified, where a extension point would be visible within sub-modules. But what defines a sub-module? A module which has the current (exporting) module's id as a prefix?

KnutWannheden: The solution (it's really a workaround) to the corresponding problem in Ant (private targets) is to prefix the target name with a dash (e.g. <target name="-internal"/>). The target can't be invoked because the Ant command line frontend would parse it as an option (which doesn't exist). I suppose a pragmatic solution like this wouldn't work in HiveMind nor would it be desirable...

To minimize the knowledge needed by the user maybe a best practice would often suffice. The private and public parts could be split into two modules, as common in Java with .internal and .impl packages.

http://issues.apache.org/jira/browse/HIVEMIND-58

PrivatesProposal (last edited 2009-09-20 22:01:36 by localhost)