xml-dev - Re: Java class != XML entity

[Dean Roddey <roddey@us.ibm.com>]

>I was writing about Java source files, the relevant scoping region for
>package declarations. A Java file is a _compilation_ unit, not a class,
>since it is possible (if not favored practice) to put several classes into
>one source file. I agree that entities and include files are somewhat
>similar, and that explains some of the problems with entities: potential
>name clashes or namespace prefix capture by the entity referencing context.

>Part of my point is in direct agreement with your point; all such
>analogies are hazardous and should be treated like radiactive material
>-- potentially useful, and potentially deadly.

I think though that drawing from the existing body of experience is still
important, right? When I was
polled about the namespace draft by our folks, I said I thought it should go
forward because the
issues of scoping were well proven in existing programming languages. However,
I (being still kind
of new to the XML world) did not fully understand the new spec. If I had
understood that it was not
suggesting the use of namespaces in a way anything like that of the languages I
had experience
with, I probably would have said the opposite.

Back to the C++ example... As someone rightly pointed out, its model is that of
the "declare them all
up front" genre. Scoping is not used to nest invocations of namespaces, but to
nest the use of
instances of types. And, it did not sink into my tiny reptilian brain that
namespaces would be
named by every individual user of them as apposed to being given a name and
being used that
way forever more by everyone.

So the existing spec would be like this (in unreal pseudo code):

using namespace Hubba as Bubba;

Bubba::SomeType foo()
{
    if (blah blah blah)
    {
        using namespace Jean as Bubba;
        return Bubba::SomeType(0);
    }
}

So is this 'legal' or not? It would depend upon the particular namespace mapped
to Bubba at
the time where the foo() method was prototyped I guess. But visually, I would
be hard pressed
to figure it out myself according to how convoluted a path I got foo() into my
program by.

I wouldn't want a progrmaming language that worked that way particularly, nor
would I use it that
way if it did provide those services. It would present all of the same problems
that everyone else
has brought up. I (and my compiler) could never know what Bubba::SomeType
really meant
without a lot of effort that isn't worth what you get out of it.

It seems to me, if you were to follow the previous experience forward, you
would have to go
back to the "declare'em all up front" mechanism, and apply scoping only to
those things that
previous experience has shown it useful for, which would be 'variables'