Extending the framework

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

anonymous
Tue Apr 20 11:01:07 CDT 2004



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

>>I've decided to add my stick my stuff in the System.Windows.Form
>>namespace. ...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

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

Fredo
Tue Apr 20 11:13:50 CDT 2004

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" <anonymous@discussions.microsoft.com> wrote in message
news:E8A84E9F-E0A3-413D-ACAC-381467EFC95B@microsoft.com...
>
>
> ----- Fredo wrote: -----
>
> >>I've decided to add my stick my stuff in the System.Windows.Forms
> >>namespace. ...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?
>
> 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.Forms
>

John
Tue Apr 20 13:07:42 CDT 2004

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.
--
John Saunders
John.Saunders at SurfControl.com


"Fredo" <fredo68@hotmail.com> wrote in message
news:ca34c2ab44df3d7663090001fddf776e@news.meganetnews.com...
> 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" <anonymous@discussions.microsoft.com> wrote in message
> news:E8A84E9F-E0A3-413D-ACAC-381467EFC95B@microsoft.com...
> >
> >
> > ----- Fredo wrote: -----
> >
> > >>I've decided to add my stick my stuff in the System.Windows.Forms
> > >>namespace. ...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?
> >
> > 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.Forms
> >
>
>

Fredo
Tue Apr 20 14:08:45 CDT 2004

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
"John Saunders" <john.saunders at SurfControl.com> wrote in message
news:%23dO1hJwJEHA.3596@TK2MSFTNGP10.phx.gbl...
> 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.
> --
> John Saunders
> John.Saunders at SurfControl.com
>
>
> "Fredo" <fredo68@hotmail.com> wrote in message
> news:ca34c2ab44df3d7663090001fddf776e@news.meganetnews.com...
> > 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" <anonymous@discussions.microsoft.com> wrote in
message
> > news:E8A84E9F-E0A3-413D-ACAC-381467EFC95B@microsoft.com...
> > >
> > >
> > > ----- Fredo wrote: -----
> > >
> > > >>I've decided to add my stick my stuff in the
System.Windows.Forms
> > > >>namespace. ...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?
> > >
> > > 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.Forms
> > >
> >
> >
>
>

Bruno
Wed Apr 21 05:05:46 CDT 2004

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" <fredo68@hotmail.com> a écrit dans le message de
news:2cb6cb7f864521b2ab9e7ec6f578447b@news.meganetnews.com...
> 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
> "John Saunders" <john.saunders at SurfControl.com> wrote in message
> news:%23dO1hJwJEHA.3596@TK2MSFTNGP10.phx.gbl...
> > 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.
> > --
> > John Saunders
> > John.Saunders at SurfControl.com
> >
> >
> > "Fredo" <fredo68@hotmail.com> wrote in message
> > news:ca34c2ab44df3d7663090001fddf776e@news.meganetnews.com...
> > > 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" <anonymous@discussions.microsoft.com> wrote in
> message
> > > news:E8A84E9F-E0A3-413D-ACAC-381467EFC95B@microsoft.com...
> > > >
> > > >
> > > > ----- Fredo wrote: -----
> > > >
> > > > >>I've decided to add my stick my stuff in the
> System.Windows.Forms
> > > > >>namespace. ...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?
> > > >
> > > > 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.Forms
> > > >
> > >
> > >
> >
> >
>
>

John
Wed Apr 21 08:04:44 CDT 2004

"Fredo" <fredo68@hotmail.com> wrote in message
news:2cb6cb7f864521b2ab9e7ec6f578447b@news.meganetnews.com...
> 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.

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!
--
John Saunders
John.Saunders at SurfControl.com



>
> Pete
> "John Saunders" <john.saunders at SurfControl.com> wrote in message
> news:%23dO1hJwJEHA.3596@TK2MSFTNGP10.phx.gbl...
> > 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.
> > --
> > John Saunders
> > John.Saunders at SurfControl.com
> >
> >
> > "Fredo" <fredo68@hotmail.com> wrote in message
> > news:ca34c2ab44df3d7663090001fddf776e@news.meganetnews.com...
> > > 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" <anonymous@discussions.microsoft.com> wrote in
> message
> > > news:E8A84E9F-E0A3-413D-ACAC-381467EFC95B@microsoft.com...
> > > >
> > > >
> > > > ----- Fredo wrote: -----
> > > >
> > > > >>I've decided to add my stick my stuff in the
> System.Windows.Forms
> > > > >>namespace. ...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?
> > > >
> > > > 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.Forms
> > > >
> > >
> > >
> >
> >
>
>