newbie - can't use child namespaces without full qualification, eh?

  • Thread starter Thread starter Peter Row
  • Start date Start date
P

Peter Row

Hi,

BACKGROUND TECH:
WinXP Pro SP1, VS.NET Ent 2003, .NET 1.1

I am more familar with VB.NET but am about to start on a C# project.
So I started on a simple console app that would let me get my feet wet.

Any how I came across this annoying issue when using classes from
different namespaces in my console application.

At the top of my only code file I have these imports:

using System;
using System.Text;
using System.Xml;
using System.IO;

In code in order to declare an XslTransform object I have to say:

System.Xml.Xsl.XslTransform srcXslt;

If I try to say:

Xsl.XslTransform srcXslt;

I get a compile error saying it doesn't recognise Xsl as a class or
namespace. A quick note here is that it doesn't auto-syntax when I
type the period after Xsl either.

I got a colleaguge whose main .NET language is C# to try it and he got
the same problem.

Is there some weird C# configuration option or is this something that
Microsoft decided would make people like VB.NET more?

In VB.NET if I say:

Imports System
Imports System.Text
Imports System.Xml
Imports System.IO

And then in code say:
Dim srcXslt As Xsl.XslTransform

Then that compiles without problem.

The reasons this is annoying to me (and I imagine others) should be
obvious. The only way round it is to either (a) fully qualify the
declaration
(i.e. lots of pointless typing) or (b) add a using statement for every
child namespace I want to use.

Regards,
Peter
 
Just add

using System.Xml.Xsl;

to

using System;
using System.Text;
using System.Xml;
using System.IO;

and it should work to XslTransform without any problem.

HTH

Yves
 
Hi,

You've missed the point of what I was saying.

I have included:
using System.Xml;

Since the Xsl namespace is a child of System.Xml I should
be able to write the code:
Xsl.XslTransform myTransform;

but I can't due to namespace/class not recognise compile
error, the question is why can't I? I can in VB.NET.

Regards,
Peter
 
Hi,

You've missed the point of what I was saying.

I have included:
using System.Xml;

Since the Xsl namespace is a child of System.Xml I should
be able to write the code:
Xsl.XslTransform myTransform;

but I can't due to namespace/class not recognise compile
error, the question is why can't I? I can in VB.NET.

Plus I don't understand what you mean "makes the rules simpler".

How does having to write:
System.Xml.Xsl.XslTransform myXTVar;
or
using System.Xml.Xsl;

any simpler than being able to say:
using System.Xml;

Xsl.XslTransform myXTVar;

Imagine that for the sake of argument I have the following structure:

MyNamespace
|_ ChildNS1
| |_GrandChildNS1
| | |_GreatGrandChildNS1
| | | |_MyClassA
| | |
| | |_ MyClassB
| |_MyClassC
|_ MyClass D

Now at the top of my code file I say:

using MyNamespace.ChildNS1.GrandChildNS1;

I "SHOULD" be able to say:
MyClassB myVarB;
GreatGrandChildNS1.MyClassA myVarA;

However the 2nd line will fail unless I explicitly use the
GreatGrandChildNS1 with a using statement or unless I declare
the variables with:

MyNamespace.ChildNS1.GrandChildNS1.GreatGrandChildNS1.MyClassA myVarA;

IMO both are undesirable.
Why this child namespace issue doesn't work in C# but does in
VB.NET is mystery

Regards,
Peter
 
...
You've missed the point of what I was saying.
Click to expand...

No, I think you missed the point made by Eric gunnerson in the article Jon
provided.

In case the link got wrapped or couldn't be followed, you can try this:

http://tinyurl.com/26d6a
I have included:
using System.Xml;

Since the Xsl namespace is a child of System.Xml I should
be able to write the code:
Xsl.XslTransform myTransform;
Click to expand...

If you read the article again you'll see that the behaviour you're asking of
"using" doesn't apply to nested *namespaces*. To repeat what phoenix said,
if you want to be able to use XslTransform without the full qualification,
you'll have to provide the namespace it's in:

using System.Xml.Xsl;

// Bjorn A
 
Peter Row said:
You've missed the point of what I was saying.
Click to expand...

No, I haven't.
I have included:
using System.Xml;

Since the Xsl namespace is a child of System.Xml I should
be able to write the code:
Xsl.XslTransform myTransform;

but I can't due to namespace/class not recognise compile
error, the question is why can't I? I can in VB.NET.
Click to expand...

VB.NET has different rules to C#. In C#, namespaces aren't really in a
hierarchy - they're just a flat set of names, basically.
Plus I don't understand what you mean "makes the rules simpler".
Click to expand...

Making namespaces hierarchical makes it harder to describe how names
are looked up. Not a lot harder, but harder - and without adding value,
IMO.
How does having to write:
System.Xml.Xsl.XslTransform myXTVar;
or
using System.Xml.Xsl;

any simpler than being able to say:
using System.Xml;

Xsl.XslTransform myXTVar;
Click to expand...

It makes it simpler to *read* the code (IMO), and it makes it simpler
to describe the rules of how names are looked up.

Why this child namespace issue doesn't work in C# but does in
VB.NET is mystery
Click to expand...

It's not a mystery - I gave you a link to an article where the C# team
explained why they'd done it that way!
 
Hi Jon,

Once again you provide the answers and take the time to point
stuff out. Probably the best MVP I've come across in recent times.

Sorry I was sort of reading your post whilst thinking about another
C# / XML problem so I didn't actually see/visit the link.

I have now read it.
Hmmm.... not sure whether it sways me or not.
Surely the simplification that it makes by doing it this way
(i.e. not having to look through all the child NS') is only
a one off saving that only affects the compiler.

I mean surely (in VB.NETs case) the searching of the imported
namespaces is done at compile time so it doesn't really save any-
thing since at runtime they have all been resolved.

Your comment on makes the code easier to read IMO is
negligable and since the programmer does not have to
describe how the names are looked up since the compiler
does it then I can't really see the point in why C# hasn't
been given this ability.

Code readability at the end of the day is in the eye of the
beholder and down to the programmer how readable they
think their code needs to be, which I guess is a question
of personal coding style. So by not allowing this ability
MS is enforcing a coding style and nothing else. That is
unless I am completely wrong about when the names
are resolved (which I very well could be).

Regards,
Peter
 
Peter Row said:
Once again you provide the answers and take the time to point
stuff out. Probably the best MVP I've come across in recent times.
Click to expand...

Many thanks - that's made my afternoon :)
Sorry I was sort of reading your post whilst thinking about another
C# / XML problem so I didn't actually see/visit the link.
Click to expand...

Righto - easily done :)
I have now read it.
Hmmm.... not sure whether it sways me or not.
Surely the simplification that it makes by doing it this way
(i.e. not having to look through all the child NS') is only
a one off saving that only affects the compiler.
Click to expand...

Well, and the user. To really know a language, you need to know all its
rules. Now, you need to work out what the precedence is if you've got
hierarchies. If you've got:

using A;
using B;

and someone types C.Foo, and there are namespaces C, A.C, and B.C,
which does it look in? Just C, just A.C, or all of them? What if
there's a class called C (in either the "current" namespace or A or B
or the unnamed namespace) which has a nested class in called Foo?

It's certainly more complicated to work out the precise rules for them
- and then learn them!

It also gives a false sense of hierarchy which .NET itself doesn't have
- there's no concept of one namespace really "owning" or being the
parent of another one.
I mean surely (in VB.NETs case) the searching of the imported
namespaces is done at compile time so it doesn't really save any-
thing since at runtime they have all been resolved.
Click to expand...

It certainly makes no difference to run-time efficiency, that's true.
Your comment on makes the code easier to read IMO is
negligable and since the programmer does not have to
describe how the names are looked up since the compiler
does it then I can't really see the point in why C# hasn't
been given this ability.

Code readability at the end of the day is in the eye of the
beholder and down to the programmer how readable they
think their code needs to be, which I guess is a question
of personal coding style. So by not allowing this ability
MS is enforcing a coding style and nothing else. That is
unless I am completely wrong about when the names
are resolved (which I very well could be).
Click to expand...

Yes, MS are effectively enforcing a coding style - as any language
specification does with other things, of course. In my view, they're
enforcing a pretty reasonable one though - either you use a "short"
name (just the type name without namespace) or the fully qualified name
with the namespace.

Perhaps it's my Java background suggesting that this is a good thing
though.
 
Hi,
Many thanks - that's made my afternoon :)
Click to expand...
No problem, credit where credit's due.
snip
Click to expand...
Well, and the user. To really know a language, you need to know all its
rules. Now, you need to work out what the precedence is if you've got
hierarchies. If you've got:

using A;
using B;

and someone types C.Foo, and there are namespaces C, A.C, and B.C,
which does it look in? Just C, just A.C, or all of them? What if
there's a class called C (in either the "current" namespace or A or B
or the unnamed namespace) which has a nested class in called Foo?
Click to expand...
Isn't that the whole point of being able to give a namespace an alias?
To remove the ambiguity.
It's certainly more complicated to work out the precise rules for them
- and then learn them!
Click to expand...
Hmm... with VB.NET it works and I didn't have to learn anything.
All I know is that if I include to namespaces and both declare ClassA
there will be a clash and I have to alias one.

Plus I think VB.NET does not go more than one level done.
So if I include: System.Xml it lets me say Xsl.XslTransform, but
say Xsl had another namespace (foo) and a class (bar) I wouldn't
be able to say foo.bar, I'd have to say Xsl.foo.bar
It also gives a false sense of hierarchy which .NET itself doesn't have
- there's no concept of one namespace really "owning" or being the
parent of another one.
Click to expand...
Is this an opinion, because I totally disagree.
If you view System with the object viewer and start expanding the
namespaces etc... you get a hierarchy.

I know that it is possible for a namespace to be implemented by more
than 1 DLL, but the physicalities of where the namespace is
implemented is irrelevant.

Xsl NS is in Xml and Xml is in System, hence you have
System
|_ Xml
|_ Xsl
To me that is a heirarchy.
snip

Yes, MS are effectively enforcing a coding style - as any language
specification does with other things, of course. In my view, they're
enforcing a pretty reasonable one though - either you use a "short"
name (just the type name without namespace) or the fully qualified name
with the namespace.

Perhaps it's my Java background suggesting that this is a good thing
though.
Click to expand...
For the subject of this discussion I don't think MS' enforced style is
reasonable.

It should be down to the programmer. As it is in VB.NET.

Regards,
Peter
 
Isn't that the whole point of being able to give a namespace an alias?
To remove the ambiguity.
Click to expand...

I personally don't like using namespace aliases for readability
reasons, but that's a different discussion.
Hmm... with VB.NET it works and I didn't have to learn anything.
Click to expand...

You did, otherwise you wouldn't know that it works. You found out by
trying, but it was still a case of learning - and I suspect that you
don't know the exact rules in detail.
All I know is that if I include to namespaces and both declare ClassA
there will be a clash and I have to alias one.

Plus I think VB.NET does not go more than one level done.
So if I include: System.Xml it lets me say Xsl.XslTransform, but
say Xsl had another namespace (foo) and a class (bar) I wouldn't
be able to say foo.bar, I'd have to say Xsl.foo.bar
Click to expand...

Are you sure though? You've just pretty much demonstrated my point -
the language is more complex, and that extra complexity means you don't
actually know what will work or not. The fewer things which exist like
that in a language, the better (IMO, and obviously only to a sensible
degree).
Is this an opinion, because I totally disagree.
If you view System with the object viewer and start expanding the
namespaces etc... you get a hierarchy.
Click to expand...

That's just a way of viewing the namespaces though - .NET itself
doesn't care about them.

You could decide to view a dictionary by expanding each node (so to see
ant you'd expand a, then n under that, then t) - that doesn't mean that
"antagonist" is really in a hierarchy under "ant" - it's just a way you
*could* view the list of words.
I know that it is possible for a namespace to be implemented by more
than 1 DLL, but the physicalities of where the namespace is
implemented is irrelevant.
Click to expand...

Not sure why that's relevant.
Xsl NS is in Xml and Xml is in System
Click to expand...

No it's not. There's no concept of one namespace being "in" another (as
far as I'm aware, at least) - there's just a list of namespaces. There
is no relationship between the System.Xml and System namespaces other
than the first six letter of "System.Xml" being "System". There's no
sense of one "enclosing" another, or anything like that - not as far as
the .NET framework itself is concerned. A language *may* choose to
impose a hierarchical structure on that list for some purposes, but it
certainly doesn't have to, and the hierarchy does not form a real
conceptual relationship between namespaces.

Thinking about it, actually C# does allow you to *declare* namespaces
in a somewhat hierarchical manner, which I believe to be a bit of a
shame to be honest - again it's belying the truth as far as the class
libraries and CLR is concerned - that namespaces just have names.
hence you have
System
|_ Xml
|_ Xsl
To me that is a heirarchy.
Click to expand...

It's just one representation of data. Just because something can be
viewed as a hierarchy doesn't make it a *conceptual* hierarchy.
For the subject of this discussion I don't think MS' enforced style is
reasonable.

It should be down to the programmer. As it is in VB.NET.
Click to expand...

I think we'll have to agree to disagree.
 
Hi,
snip

I personally don't like using namespace aliases for readability
reasons, but that's a different discussion.
Click to expand...
I agree, I had never used a NS alias either.
You did, otherwise you wouldn't know that it works. You found out by
trying, but it was still a case of learning - and I suspect that you
don't know the exact rules in detail.
Click to expand...
What I mean is I didn't sit down and think "now how does this work".
Based on my definition of a heirarchy I coded the way I thought it should
work and (in VB.NET at least) it did.
Are you sure though? You've just pretty much demonstrated my point -
the language is more complex, and that extra complexity means you don't
actually know what will work or not. The fewer things which exist like
that in a language, the better (IMO, and obviously only to a sensible
degree).
Click to expand...
True I don't know exactly how the VB.NET compiler knows what to do
but for the subject of the original subject, I totally understood what would
happen based on my definition of a heirarcy.
That's just a way of viewing the namespaces though - .NET itself
doesn't care about them.
Click to expand...
If .NET doesn't care about namespaces, what is the point to them?
Why must you say System.Xml.Xsl.XslTransform???
Perhaps because .NET does take notice of Namespaces, i.e. to
resolve declarations.
You could decide to view a dictionary by expanding each node (so to see
ant you'd expand a, then n under that, then t) - that doesn't mean that
"antagonist" is really in a hierarchy under "ant" - it's just a way you
*could* view the list of words.


Not sure why that's relevant.
Click to expand...
Because it doesn't matter if, for example, the System.Xml namespace is
implemented in 1 DLL or 100 DLLs from the code point of view
there is just System.Xml namespace and anything in it.
No it's not. There's no concept of one namespace being "in" another (as
far as I'm aware, at least) - there's just a list of namespaces. There
is no relationship between the System.Xml and System namespaces other
than the first six letter of "System.Xml" being "System". There's no
sense of one "enclosing" another, or anything like that - not as far as
the .NET framework itself is concerned. A language *may* choose to
impose a hierarchical structure on that list for some purposes, but it
certainly doesn't have to, and the hierarchy does not form a real
conceptual relationship between namespaces.
Click to expand...
What do you mean there is no relationship?
It all fits into a hierarchy where in the case given Xml is in System.
The fact this hierarchy many not be physically manifested in the same
way as I describe is irrelevant since at the lines of code level it
"conceptually"
is.
Thinking about it, actually C# does allow you to *declare* namespaces
in a somewhat hierarchical manner, which I believe to be a bit of a
shame to be honest - again it's belying the truth as far as the class
libraries and CLR is concerned - that namespaces just have names.
Click to expand...
Precisely i.e.
Namespace MyProject
Class Foo.....

Namespace ChildNS
Class Bar

Thus we have a heirarchy:
MyProject.Foo
MyProject.ChildNS.Bar

1 thing inside another, which in this case happens to be in the same
code but could be in code in a different file/DLL.
I think we'll have to agree to disagree.
Click to expand...
Yes that would seem the best thing.

Thanks for the good nature of the banter.

Regards,
Peter
 
What I mean is I didn't sit down and think "now how does this work".
Based on my definition of a heirarchy I coded the way I thought it should
work and (in VB.NET at least) it did.
Click to expand...

And that's left you with what is in my view an erroneous view of
namespaces - namely that they form a hierarchy.
If .NET doesn't care about namespaces, what is the point to them?
Why must you say System.Xml.Xsl.XslTransform???
Perhaps because .NET does take notice of Namespaces, i.e. to
resolve declarations.
Click to expand...

..NET itself uses namespaces just to allow types with names which are
otherwise the same. I'm not even sure that "namespace" is a concept
within the CLR at all - a type has a full name, which includes the
namespace. The BCL *does* have the concept of a namespace, however, as
the Type.Namespace property shows.

I've left this in because it's an important example.
Because it doesn't matter if, for example, the System.Xml namespace is
implemented in 1 DLL or 100 DLLs from the code point of view
there is just System.Xml namespace and anything in it.
Click to expand...

Yes, and I never disagreed with that at all.
What do you mean there is no relationship?
It all fits into a hierarchy where in the case given Xml is in System.
The fact this hierarchy many not be physically manifested in the same
way as I describe is irrelevant since at the lines of code level it
"conceptually" is
Click to expand...

I've never argued anything about the physical relationship being
important. I'm saying that the System namespace and the System.Xml
namespace are no more hierarchical than the word "ant" and
"antagonist" are. They have no relationships beyond the coincidence of
one starting with the name of the other. If System.Xml were to change
its name to "Foo", there would be absolutely no difference - there is
no hierarchy other than whatever one a language *chooses* to impose.
The CLR doesn't care that one name starts with the other. It's an
artificial hierarchy which can be used by *humans* to make things
easier (i.e. to show groupings and subgroupings) but it *is* still
artificial.

Compare this with the hierarchy of, say, a nested type to its enclosing
type, which affects access control.
Precisely i.e.
Namespace MyProject
Class Foo.....

Namespace ChildNS
Class Bar

Thus we have a heirarchy:
MyProject.Foo
MyProject.ChildNS.Bar
Click to expand...

As I say, I think that C# allowing that is a bad idea (and the idea of
putting two types from different namespaces in the same source file is
a bad idea too). It's promoting the idea of a hierarchy which is
entirely artificial.
Yes that would seem the best thing.
Click to expand...

It doesn't stopp us from continuing to discuss it for a while, of
course :)
Thanks for the good nature of the banter.
Click to expand...

Likewise.
 
Hi,
big snip
Click to expand...
I've never argued anything about the physical relationship being
important. I'm saying that the System namespace and the System.Xml
namespace are no more hierarchical than the word "ant" and
"antagonist" are. They have no relationships beyond the coincidence of
one starting with the name of the other. If System.Xml were to change
its name to "Foo", there would be absolutely no difference - there is
no hierarchy other than whatever one a language *chooses* to impose.
The CLR doesn't care that one name starts with the other. It's an
artificial hierarchy which can be used by *humans* to make things
easier (i.e. to show groupings and subgroupings) but it *is* still
artificial.
Click to expand...
Ah ha!!!
This is precisely my point!
From a *human* point of view it is a heirarchy. The fact that the CLR
doesn't see it that way is completely irrelevant. I don't care what the
CLR is doing underneath, all I need to know is what the code I'm
typing does. Well unless you were writting so really really complex
freaky code.

Regards,
Peter

P.S. Do you know much about .NET, XML/XSLT in conjunction
with C#? If so any chance you checking out my post on the
microsoft.public.xml group?
 
Ah ha!!!
This is precisely my point!
From a *human* point of view it is a heirarchy. The fact that the CLR
doesn't see it that way is completely irrelevant.
I don't care what the CLR is doing underneath, all I need to know is what
the code I'm typing does. Well unless you were writting so really
really complex freaky code.
Click to expand...

On the contrary - I want my model of the world to be as similar to the
CLR model as possible, within reasonable bounds. Having namespaces at
all is a reasonable bound to me - imposing a hierarchy on them isn't.
Clearly you disagree about where the bounds are set - but the fact that
remains that in *.NET* terms (rather than VB.NET terms) namespaces do
*not* form a hierarchy. Any hierarchy a language may wish to impose is
up to that language - it is *not* a .NET concept. I'm glad that C#
doesn't impose that hierarchical view (except for declaration, and I
wish it didn't impose it there), you wish it did.
P.S. Do you know much about .NET, XML/XSLT in conjunction
with C#? If so any chance you checking out my post on the
microsoft.public.xml group?
Click to expand...

I don't know much about it, to be honest - and I don't monitor the XML
group.
 
Back
Top