Martin Wirblat <sql.mawi at t-link.de> wrote:
> Hi Göran,
> 
> >> Namespaces may lower the signal to noise ratio of our source code.
> >
> >Again - though I assume you read it - note how the "rendering" 
> >mechanism I described will always render references in their "minimal 
> >form". If the image only contains unique class names (or other named 
> >objects) then all references will be unqualified when you read the 
> >source. 
> 
> The main reason why the signal to noise ratio drops, is that people 
> will refrain from giving things more descriptive names. That the 
> source code may or may not get cluttered with meaningless information 
> ( the namespace info ) is secondary. So we are losing the signal 
> independently of the noise becoming louder. 

Calling the namespaces "meaningless" is a bit harsh I think. Also - I am
not as certain as you are that people will refrain from giving things
descriptive names.

> >> Given how fast people here are starting to talk about nested 
> >> namespaces or "partitioning" the whole image into many namespaces, 
> >> I guess implementing namespaces will not automagically "clean up" 
> >> names in the future, it will probably do the opposite. 
> >
> >My proposal was a flat list of Namespaces. No nesting. And how many
> >Namespaces we would use for our standard packages is also up for
> >discussion.
>  
> Yes, but I just wanted to repeat your warnings about what will "crash 
> down the hill on us". Your idea of having many small namespaces in the 
> Full image showed me, how fast one can become intrigued by the 
> "coolness" of namespaces. ( Starting out critical and then becoming 
> converted without recognizing it. Well, not really ;-) 

Eh... you lost me. "Many small namespaces in the Full image?" I assume
you are talking about the "many small packages"? I still think that is a
good idea, at least much smaller than the current image.

> My gut feeling was and is that the official Full image should be only 
> one single namespace. Of course the question then arises, what the 
> goal of such namespaces is. And surely this will have some drawbacks,

I am not sure I disagree with that. I mean - that is what it is today.
But I still want to chop it up into well separated *packages* that can
have their own releases cycles etc. As Andreas says - those things
aren't one-to-one.
 
> but it will ensure best that people try to name meaningful. Perhaps it 
> will even invite to merge similar classes. As you said, namespaces 
> lure people into reinventing the wheel all the time. 

Yes. But it seems to me that my proposal "preserves" that value.

> >Anyway, now my posting sounds like a "defense" but I am not sure you
> >really were critical at all. :) :)
> 
> No, I just hooked into your post at what I consider to be the culprit 
> of namespaces. Your proposal seems to take care of this special 
> problem, but I think the question is still: Are the advantages greater 
> than the problems? 

Dunno. :) But personally I have used the "prefix approach" which is a
workaround that gives me a kindof namespace - and it would be better to
to do something "proper". Currently I think people are a bit "hesitant"
to claim certain class names because we instinctively feel that they may
be prone to conflicts.

> Special note: I would drop "shy". It complicates things ( bitten by 
> the hidden ) and is a step in the wrong direction, it allows the lazy 
> programmer to circumvent the search for a proper name. 

Well, perhaps. Not sure.

> regards
> Martin

regards, Göran