Re: Packages as first class entities

Hi Lorenzo,

> Then I jumped back to nice (I'm dreaming about a ruby on rails in nice ;)

:-)

> ) and started to think to the role that packages have in nice.
> If I understood correctly, nice packages are more important entities than
> java packages, they are bigger and more "concrete".

Yes. One important distinction with Java is that in Nice packages can contain 
methods.

> In some book I do not remember (Wirfs-Brock?) there was something like this
> "you should consider a group of classes as the minimal element of design,
> the single class is not enough".

That fits quite well with Nice, indeed.

> Ok, I come to the point. I was thinking if packages could be real entities
> of the language, with a well defined interface and behavior.
> Suppose you was to use/embed another program in your code, something like
> hsql for example.
> You have to write something like this
> 
> com.xyz.App app = new com.xyz.App(new AppConfig("configFile"));
> app.start();
> 
> In this example App is just one class of the package, it have nothing special,
> but it's clear that it's what keep together all the other classes.
> So I'm thinking to something like this
> 
> com.xyz app = new com.xyz("configFile");
> app.start();

I'm not sure I see the benefit (I'll ignore the fact that you avoid using the 
AppConfig class, as this is something you could already do in Nice using a 
custom constructor).

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

> internally the "package constructor" will use the same code of the previous
> example.
> I think the difference here is that the idea of an higer level of aggregation
> is explicit, is not something that come from the docs, and that you need
> to be careful to follow

You should be able to use visibility to express the higher-level of 
aggregation. And note that you would still need docs to document how to use 
your package.

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.

Feel free to give more info if I have misunderstood your idea, or provide more 
examples to help us better understand your needs.

Cheers,

Daniel


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