Re: Packages as first class entities

Daniel Bonniot wrote:

> It looks like you are giving special meaning to one class inside a 
> package, and then providing special syntax to instantiate that class. 
> This is rather complexifying the language by adding a special case 
> rather than making it similar at all scales. I rather see classes and 
> packages as orthogonal concepts (packages providing namespaces and 
> visibility restrictions).

I agree. What I'm thinking about is adding one more role to packages, 
seeing them as bigger objects.
About the "special case" issue, could be natural for a package to be an 
Object. So you could have a composite of packages/classes but maybe is 
too early to really evalute this idea.

The starting point is that a class is a little bigger than a method. The 
next step of growth is not in the language but only in the design/docs 
of the app.
You can carefully define the public classes of a package, or define a 
facade over a group of classes, but in this way you do not really define 
a new level.

For me is strange to think about a List of Facades: facades do not 
contains anything, so your list is only a list of "proxy" for something 
external.

Subsystems, modules, components, are "abstract" terms, you cannot define 
some property of a subsystem (abstract?, version?, implements?) with code.

> What I imagine could be needed to better support this is a more 
> powerfull visibility system that public/private. For instance, 
> visibility inside a certain group of packages. A possible way would be 
> to support hierarchical packages ("packages of packages"). I would 
> love to hear ideas, concrete proposals and links to research about this.

I'll look on google for something similar.
In the meantime these are a couple of ideas to bring back the discussion 
to something a little concrete

- one/some classes could be tagged with a special keyword 
(facade/component/?). These classes will act as bigger blocks, they will 
read config files, open connections, create a lot of other classes, etc.
When you do a

Map m = new HashMap();

many things could happen inside the constructor, and you could like to 
specify a lot of details about the internal working of the class. But 
usually you accept the behavior of that class or try another class.
The same should be for

Database db = new Database();

in the constructor a driver is loaded, a connection pool could be 
started, an exception handling policy defined, ecc.
If you need to config these things you can choose to use another 
Database implementation (new NoPoolDb) or, better, config something in 
the default config file/class for that class.
For example each "big" class can have, by default an associated 
className.property file in the same dir or an optional className_Config 
class.

For example: to startup hibernate you need about 5/15 or more lines of 
code. That code in most case I think is not really application specific. 
Each project will cut and past again the same 5/15 lines. I think that 
to add an HibernateStartupUtil is not the solution.
You should write new Hibernate() or new PooledHibernate() and accept all 
defaults (as you do with normal object creation).

To me, at first sight, these looks like things that belongs to a library 
(spring or something) and not to a programming language. At the same 
time I feel that spring exists because the language is not doing enough, 
is too low level.

Ok, stop.


Bye

Lorenzo



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20