Re: But is it Object-Oriented?

>In my proposal, I suggested to have the default visibility be private so that
>there would be no "private" keyword which people would find to be confusing.  
>
Why would 'private' be confusing?

>To
>make something visibile to the whole package, a "package" keyword would be used,
>and to make it visible to everything, a "public" keyword would be used.
>  
>
Then you will have to teach people that the default visibility is 
private. It's not impossible, but it's some effort.

Personally, I think 'package' is a reasonable default. It forces you to 
think carefully about what to export publicly by stating it explicitely, 
but it leaves flexibility about how you organize things inside the 
package. This is not problematic, because a package is a set of features 
that are developed together. Units/files can be used to split the 
package into smaller units that are easier to work on, but it should be 
easy to reorganize the internals of your package, since that won't 
affect the clients of the package. In this view, private is still useful 
when you want to make sure that some feature is only used in the ways 
you see before your eyes (the unit), so that you can reason about its 
invariants.

>>In addition to the manual, it would indeed be great to have several 
>>tutorials/introductions, targetting different audiences. Currently, the 
>>user manual might have this Java flavour because such info is also 
>>needed, and it is not presented elsewhere. The more we have of this kind 
>>of material, the more we can make sure that the manual is "neutral". 
>>It's a question of manpower. It you and/or others would like to write a 
>>tutorial targetting people familiar with functional languages, that 
>>would be a great contribution.
>>    
>>
>
>That makes a lot of sense. 
>  
>
:-)

>>There is a fair amount of interest around Nice. I don't think there 
>>would be half of it if the language was a traditional research language, 
>>with a brand new syntax and close to no libraries, however pure and 
>>clever that language may be.
>>    
>>
>
>I love marketting. :)
>  
>
I don't! :-)

It's a fact, though, that learning a new way of doing things has a 
"cost" in time and brain cells. So there is a question of balancing 
between being innovative when it's worth it, and being conservative when 
it does not matter much.

>What I meant by both of my previous sentenses above is that there doesn't seem
>to be much modularity in Nice because its module system as not been designed
>yet. 
>
That's not exact. That part of my dissertation is written :-)

And the module system is implemented too, apart from enforcing visibility.

>First, there is the visiblity issue. Also, there should be a mechanism for
>describing the interdependencies between modules. In Cecil, they have "module Z
>extends module Y" which is important for their multimethod coverage checking (if
>you have only "module X extends module Y then X cannot extend any generic
>functions or classes from module Y"). 
>
In Nice there is also a mechanism to describe relationships between 
packages, it's written 'import Y;' inside package Z. It's not the same 
semantics as Cecil, though.

>Finally, there isn't documentation that
>tells me what kinds of changes break the binary interface of a module.
>  
>
True. Although I still think that this is a lower-level aspect than the 
semantics of the language. So I would rather handle this later. Does 
that cause any practical problem?

The golden rule is that if you modify a package in anything more than 
changing the statements implementing a method, you should recompile 
importing packages too. That's done very simply by always compiling your 
'root' package, since nicec will automatically find all the imported 
packages and recompile them if needed.

>I agree. I have been thinking about doing that. But then also I have been
>thinking that maybe Nice should just adopt the whole O'Caml (or similar) module
>system. If so, then I don't waste time doing a visibility modifiers
>implementation that will be replaced later.
>  
>
Do you mean the part about having a separate syntax for defining the 
interface, rather than annotating the source code with public/private? 
Or rather the presence of functors (functions from modules to modules)?

Daniel



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click