headers
Slawomir Lisznianski | 6 Sep 23:12

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:

> For clarity, I would recommend that types like Integer, Float and Matrix 
> above be in separate files. The rotate function would then be:
> 
> namespace Math
> {
>   namespace Algorithm
>   {
>     Math.Matrix rotate( Math.Matrix mat, Math.Float deg );
> 
>     // other common algorithms here...
>   }
> }
> 

Actually, since Algorithm, Matrix and Float share common parent 
namespace, it would be even simpler than my example:

namespace Math
{
   namespace Algorithm
   {
     Matrix rotate( Matrix mat, Float deg );

     // other common algorithms here...
   }
}

Now, let's assume that the user decided to add a type within an inner
(Continue reading)

Permalink | Reply |
headers
edA-qa | 7 Sep 17:59

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> The problem above is that class Matrix in Math.Algorithm clashes with 
> Matrix (primary) in an enclosing namespace Math. What now? Well, in my 
> opinion this is a bad design and compiler should complain. Users 
> shouldn't be allowed nesting namespaces and re-define outer 
> classes/namespaces within inner namespaces. C++ is less strict today. In 
> general, I'd rather have an annoying language than unsafe-- of course 
> within reason.

Clashing names don't tend to happen by way of design, they come about 
through using various libraries and maintaing your own library over time.

In the case of a math library, perhaps Matrix wasn't defined before 
since it wasn't used at the global level, but in one of the 
sub-namespaces, for Algorithms, one programmer defined a simple Matrix 
for his use.

Later on in the project somebody realizes they need a global Matrix, so 
he defines it in the outer namespace.  Does it make sense that providing 
this outer definition then suddenly makes the inner code no longer work?

There is also very good reason to allow libary users to nest namespaces, 
it is a point that Java has failed very poorly on (I'm going through 
this in my work now): libraries should encapsulate their entire 
infrastructure and support system in order to prevent version clashes 
and lookup problems.

That is to say, in projects it is sometimes good to use an #Include 
statement inside your own namespace in order to completely isolate any 
symbols I may need.  This allows me to treat the library as truly an
(Continue reading)

Permalink | Reply |
headers
Slawomir Lisznianski | 8 Sep 03:45

Re: Proposal for Include files/headers

edA-qa wrote:
> Later on in the project somebody realizes they need a global Matrix, so 
> he defines it in the outer namespace.  Does it make sense that providing 
> this outer definition then suddenly makes the inner code no longer work?

It's impossible to answer this question without practical context. My 
first impression is that having two Matrix classes under the same hood 
(some higher-level namespace) is generally a bad idea.

> That is to say, in projects it is sometimes good to use an #Include 
> statement inside your own namespace in order to completely isolate any 
> symbols I may need. 

Only header-contained libraries, such as STL, can be nested this way. 
Symbols exported from objects have "original" namespaces mangled in.

> This allows me to treat the library as truly an 
> isolated component -- whereas if somehow it was polluting a common 
> namespace I would have problems.

As explained, in practice, the scope of repackaging is limited to 
template libraries.

   I think we're slowly swinging away from any potential solution, 
which, admittedly, is not clear to me right now. At this point, we have 
just about two options. One, we can leave it as is, and not worry about 
it for the time being-- as Rajesh suggested in his post. Two, try to 
come up with a list of things that we agree on or consider essential and 
then try again. I can start with a few, feel free to add/remove:
(Continue reading)

Permalink | Reply |

Gmane