Extending the framework

  • Thread starter Thread starter Fredo
  • Start date Start date
F

Fredo

I'm curious about what people think about this idea.

I've been creating new classes derived from DataGridColumnStyle to support
some of the column types I need (combo boxes, pictures, etc).

First of all, I find it terribly annoying that these aren't part of the .NET
Framework to begin with. Including only two styles when it's really not that
difficult to add more just doesn't really make sense to me.

Anyway, my question is as follows: I'm following the same naming convention
as MS and I've decided to add my stick my stuff in the System.Windows.Forms
namespace. Is there anything wrong with that? I know it could cause problems
if there is a name collision in future versions of .NET, but besides that,
is there any other downside?

It doesn't appear MS has any intentions on adding new ones for Longhorn (at
least as far as the current SDK documentation is concerned), so I don't
expect namespace collisions anytime soon.

Pete
 
----- Fredo wrote: ----

Seeing as though this is the sole purpose of namespaces, it would also seem to be the only downside. It's not something I would choose to do, however, as the resulting namespace would be misnamed; Something written by a thrid party is not part of the system, after all

I would use something like: MyTopLevelNamespace.Windows.Form
 
I thought of that, but there are so many libraries that have
mylibraryname.Windows.Forms, and it's just one more "using" statement for me
to write.

You said the resulting namespace would be misnamed. How do you mean? Why
wouldn't it be part of "System"? Sure, it won't be in
System.Windows.Forms.dll, but you'll find a lot of stuff in .NET that isn't
in a DLL by the same name as the namespace. For example, the
System.Windows.Forms.Design namespace is largely broken into
System.Windows.Forms.dll and System.Design.dll.

Adding new stuff to an existing namespace using different DLLs shouldn't
result in any misnaming that I'm aware of.

Pete
Charlie Williams said:
----- Fredo wrote: -----
any other downside?

Seeing as though this is the sole purpose of namespaces, it would also
Click to expand...
seem to be the only downside. It's not something I would choose to do,
however, as the resulting namespace would be misnamed; Something written by
a thrid party is not part of the system, after all.
 
As a general rule, I've learned that one shouldn't play with someone else's
toys without their permission. This includes namespaces.

The reason for namespaces is to limit the number of possible name
collisions. If you create a class "xColumn" in the System.Windows.Forms
namespace, you have no reason to believe that Microsoft isn't creating a
class with the exact same name, and with a totally different meaning. This
is because you (probably) don't know the people at Microsoft who are
responsible for System.Windows.Forms, and can't ask them about their
"xColumn" intentions.

On the other hand, if you create the same class within the
MyCompany.Windows.Forms namespace, you're much more likely to know the
prople responsible for adding names to that namespace, and can ask them
about "xColumn"

Namespaces and other such constructs are all about limiting the creation of
new names to a community of people who are likely to mean the same thing
when they refer to those names. Different namespaces are for different
communities of people, in particular, communities whose members are likely
to mean something different when they refer to the same name.
 
Well, you're correct for the most part. I do, however, have reason to
believe that the classes I will be introducing, won't collide with updates.
At least in the next couple of years, I'm fairly certain. That's because the
documentation for Longhorn doesn't introduce them. If it were in the
longhorn docs, then I wouldn't do it. Longhorn is at least a couple years
off now.

Pete
 
I would still follow John's advice. Why do you insist on having your classes
inside System.Windows.Forms rather than YourCompany.Windows.Forms, like
everyone else does?

Having one more "using" at the top of every file is not enough to justify
this. My feeling is that your scheme is ok as long as you have a small
project and you are the only one using your classes but as soon as you have
to work with a group of people, it will create major confusions: people not
knowing whether a bug is on MS side or on your side, classes not found in
the documentation tree, System classes not found on a target machine because
your DLL is not installed, etc. You are looking for trouble.

Bruno.
 
Fredo said:
Well, you're correct for the most part. I do, however, have reason to
believe that the classes I will be introducing, won't collide with updates.
At least in the next couple of years, I'm fairly certain. That's because the
documentation for Longhorn doesn't introduce them. If it were in the
longhorn docs, then I wouldn't do it. Longhorn is at least a couple years
off now.
Click to expand...

Statements like the above often invoke bad karma. The gods of karma read
things like the above and may deliberatly introduce namespace collisions
just to spite you!
 
Back
Top