Odd question

[Daggeron]

Well more just curious. Right now for my treeview I need to store more information
with the node then simply name etc. So what I've done is I've created a
class with the information I need then I'm just attaching it on each nodes
TAG field. What I'm trying to figure out is if thats a good way todo it
or not? Heh

Thanks

-Dag

[Jacob Grass]

Dag-

I prefer to create my own treenode class (derived from treenode), add the
appropriate properties, override the clone method to accommodate for it and
voila. . .

--
Jacob Grass
Microsoft .NET MVP

"Daggeron" <sirdaggeron@yahoo.com> wrote in message
news:3c73d689$1@10.1.10.29...
>
> Well more just curious. Right now for my treeview I need to store more
information
> with the node then simply name etc. So what I've done is I've created a
> class with the information I need then I'm just attaching it on each nodes
> TAG field. What I'm trying to figure out is if thats a good way todo it
> or not? Heh
>
> Thanks
>
> -Dag

[Daggeron]

Hrm thank you. I'll try that out.

"Jacob Grass" <JGrass@AbilitiSolutions.com> wrote:
>Dag-
>
>I prefer to create my own treenode class (derived from treenode), add the
>appropriate properties, override the clone method to accommodate for it
and
>voila. . .
>
>--
>Jacob Grass
>Microsoft .NET MVP
>
>"Daggeron" <sirdaggeron@yahoo.com> wrote in message
>news:3c73d689$1@10.1.10.29...
>>
>> Well more just curious. Right now for my treeview I need to store more
>information
>> with the node then simply name etc. So what I've done is I've created
a
>> class with the information I need then I'm just attaching it on each nodes
>> TAG field. What I'm trying to figure out is if thats a good way todo
it
>> or not? Heh
>>
>> Thanks
>>
>> -Dag
>
>

[Rob Teixeira]

This is certainly the "cheapest" way to get it done - and it works, so there's
technically nothing wrong with it. Of course, you could subclass the TreeNode
class and add your custom members to it (as Jacob points out), and that does
make it look more professional. It also allows you to use some interesting
polymorphism patterns. However, it's not entirely necessary.

-Rob

"Daggeron" <sirdaggeron@yahoo.com> wrote:
>
>Well more just curious. Right now for my treeview I need to store more
information
>with the node then simply name etc. So what I've done is I've created a
>class with the information I need then I'm just attaching it on each nodes
>TAG field. What I'm trying to figure out is if thats a good way todo it
>or not? Heh
>
>Thanks
>
>-Dag

[Michael Culley]

I'm reading dan applemans book 'moving to vb.net'. In it he says that
inheritance is practicly useless and he has only every used it 6 times in
his entire life (including other languages besides .net). He says that he
does inherit existing objects in dot net but has never found a use for
making an inheritable class himself. Ever since he gave webclasses a glowing
review I doubt everything he says. Should I doubt this?

--
Michael Culley
www.vbdotcom.com


"Daggeron" <sirdaggeron@yahoo.com> wrote in message
news:3c73d689$1@10.1.10.29...
>
> Well more just curious. Right now for my treeview I need to store more
information
> with the node then simply name etc. So what I've done is I've created a
> class with the information I need then I'm just attaching it on each nodes
> TAG field. What I'm trying to figure out is if thats a good way todo it
> or not? Heh
>
> Thanks
>
> -Dag

[Rob Teixeira]

That just sounds weird! I'm going to comment causiously since I don't know
the context of text.
First of all, inheritance is VERY useful, since it provides a way to automatically
do a single-point maintenance of common reusable class behavior, which at
the same time cuts down on the amount of written source code. There are dangers
about inheritance where behaviours that are overriden and subsequently change
can cause rippling issues throughout derived classes (as an example), so
you have design and code carefully.
Still, anyone who's really used it will tell you it can definitely be useful.

As for not creating inheritable classes...
Well, again, this all boils down to design. I seem to remember that in Java
1.1, there were some classes that weren't inheritatble, and members that
were marked as final (not overridable) (some of the collection classes come
to mind) that caused programmers no end of frustration. When you design good
reusable code, there's no reason it shouldn't be inheritable.

-Rob

"Michael Culley" <mike@vbdotcom.com> wrote:
>I'm reading dan applemans book 'moving to vb.net'. In it he says that
>inheritance is practicly useless and he has only every used it 6 times in
>his entire life (including other languages besides .net). He says that he
>does inherit existing objects in dot net but has never found a use for
>making an inheritable class himself. Ever since he gave webclasses a glowing
>review I doubt everything he says. Should I doubt this?
>
>--
>Michael Culley
>www.vbdotcom.com

[Jacob Grass]

I recall reading that as well. . . I think from a Windows Forms perspective,
inheritance is one of the top 5 improvements to VB on my list. . . I have
also created a number of abstract classes and such for various apps and they
have proved very useful. . .

--
Jacob Grass
Microsoft .NET MVP

"Michael Culley" <mike@vbdotcom.com> wrote in message
news:3c740d70@10.1.10.29...
> I'm reading dan applemans book 'moving to vb.net'. In it he says that
> inheritance is practicly useless and he has only every used it 6 times in
> his entire life (including other languages besides .net). He says that he
> does inherit existing objects in dot net but has never found a use for
> making an inheritable class himself. Ever since he gave webclasses a
glowing
> review I doubt everything he says. Should I doubt this?
>
> --
> Michael Culley
> www.vbdotcom.com
>
>
> "Daggeron" <sirdaggeron@yahoo.com> wrote in message
> news:3c73d689$1@10.1.10.29...
> >
> > Well more just curious. Right now for my treeview I need to store more
> information
> > with the node then simply name etc. So what I've done is I've created a
> > class with the information I need then I'm just attaching it on each
nodes
> > TAG field. What I'm trying to figure out is if thats a good way todo it
> > or not? Heh
> >
> > Thanks
> >
> > -Dag
>
>

[Kathleen \(MS MVP\)]

Michael,

Dan says a lot, so naturally a lot of what he says gets taken out of context
and some of it he has to take back later <g>

Can you tell me wher ehe says this so I can read it and comment more
intelligently.

There are certainly things that you create that you won't inherit further
from (everything in .NET is inherited from something else). But there are
places to further inherit from your classes.

I don't use it, however, in the classic business object sense. Few business
objects are logically derived from other business objects, and rarer yet is
the payback for forcing inheritance down SQLServer's throat. That may have
been the context in which Dan was speaking.

Kathleen

[Rob Teixeira]

Since this is all theory, I can theoretically cause a lot of the same kinds
of bugs/problems even if I use interface implementation and delegation. Honestly,
I think the dangers about inheritance are way overblown - most likely to
underplay the lack of the feature in certain languages.

In fact, you don't even need OOP to reproduce some of the problems. I could
do the same thing if i'm not careful about special-case diverging module
functions.

-Rob


"Tim Overbay" <toverbay@pbsj.com> wrote:
>Moving to VB.NET: Chapter 5, page 57.
>
>I think he was arguing that most of the benefits of inheritance can be
>gained more safely through interface inheritance and delegation. I'd have
to
>reread the chapter to be sure, though.
>
>Tim

[Tim Overbay]

Moving to VB.NET: Chapter 5, page 57.

I think he was arguing that most of the benefits of inheritance can be
gained more safely through interface inheritance and delegation. I'd have to
reread the chapter to be sure, though.

Tim

"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3c7411de$1@10.1.10.29...
>
>
> That just sounds weird! I'm going to comment causiously since I don't know
> the context of text.
> First of all, inheritance is VERY useful, since it provides a way to
automatically
> do a single-point maintenance of common reusable class behavior, which at
> the same time cuts down on the amount of written source code. There are
dangers
> about inheritance where behaviours that are overriden and subsequently
change
> can cause rippling issues throughout derived classes (as an example), so
> you have design and code carefully.
> Still, anyone who's really used it will tell you it can definitely be
useful.
>
> As for not creating inheritable classes...
> Well, again, this all boils down to design. I seem to remember that in
Java
> 1.1, there were some classes that weren't inheritatble, and members that
> were marked as final (not overridable) (some of the collection classes
come
> to mind) that caused programmers no end of frustration. When you design
good
> reusable code, there's no reason it shouldn't be inheritable.
>
> -Rob

[Zane Thomas [.NET MVP]]

On Thu, 21 Feb 2002 08:09:18 +1100, "Michael Culley" <mike@vbdotcom.com>
wrote:

>I'm reading dan applemans book 'moving to vb.net'. In it he says that
>inheritance is practicly useless and he has only every used it 6 times in
>his entire life (including other languages besides .net).

That's his problem - and an absurd statement on its face.

I'm working on a little game program with my 13yo son. We first had - as
I pretended to not know better <g> - Player and Orc classes. As they
became fleshed out the duplication of code provided a natural path for me
to explain abstracting the common parts out into an Actor class from which
Player and Orc now derive.

A simple example, which simply refutes Appleman's claim.


>He says that he
>does inherit existing objects in dot net but has never found a use for
>making an inheritable class himself.

I guess that says more about what he does than about the value of
inheritance itself. If he took a peek inside the framework he would see
that it uses inheritance. There are not deep inheritance trees - a good
thing imo; inheritance is used sensibly.


--
When freedom is outlawed
only outlaws will be free.

[Tim Overbay]

I agree. Inheritance doesn't cause problems, poor programming does.

Actually, after rereading most of that chapter, it looks like Dan is simply
trying to say, "Inheritance isn't necessary, but you gotta know what you're
doing before using it." Same thing with the chapter on Multithreading.

Tim

"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3c74213e$1@10.1.10.29...
>
>
> Since this is all theory, I can theoretically cause a lot of the same
kinds
> of bugs/problems even if I use interface implementation and delegation.
Honestly,
> I think the dangers about inheritance are way overblown - most likely to
> underplay the lack of the feature in certain languages.
>
> In fact, you don't even need OOP to reproduce some of the problems. I
could
> do the same thing if i'm not careful about special-case diverging module
> functions.
>
> -Rob
>
>
> "Tim Overbay" <toverbay@pbsj.com> wrote:
> >Moving to VB.NET: Chapter 5, page 57.
> >
> >I think he was arguing that most of the benefits of inheritance can be
> >gained more safely through interface inheritance and delegation. I'd have
> to
> >reread the chapter to be sure, though.
> >
> >Tim
>

[Kunle Odutola]

"Zane Thomas [.NET MVP]" <zane@mabry.com> wrote in message
news:3c8f27c9.83589046@news.devx.com...

> >I'm reading dan applemans book 'moving to vb.net'. In it he says that
> >inheritance is practicly useless and he has only every used it 6 times in
> >his entire life (including other languages besides .net).
>
> That's his problem - and an absurd statement on its face.

I don't know the context of his comments but I'd have to agree here. Given
that he's presumably used C++ for such a long time, it's pretty damning
too!

> I'm working on a little game program with my 13yo son. We first had - as
> I pretended to not know better <g> - Player and Orc classes. As they
> became fleshed out the duplication of code provided a natural path for me
> to explain abstracting the common parts out into an Actor class from which
> Player and Orc now derive.

I'd sure love to make MM a fly on the world in your sessions. He might learn
something ;-)

Kunle

[Stephen Russell]

I tend to subclass allot. I have the M$ base form. I then take that form
and add a few methods to that making it mine and one level from M$. From my
base form I then subclass an applications necessary form types, Search, Data
Entry, Page Frame, and Modal.

Now if M$ has a new version of the form I am protected. As I learn of my
initial designs shortcomings I can enhance my base form to give
functionality to every form in one swoop.

Every one of my application forms is now subclassed from my appBase forms.

Say there is a logo change. I just apply the change to my appBase and it
filters throughout the app because I did it in the appBase master form.

We have been doing this in VFP for 6 years.

__Stephen


"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3c7411de$1@10.1.10.29...
>
>
> That just sounds weird! I'm going to comment causiously since I don't know
> the context of text.
> First of all, inheritance is VERY useful, since it provides a way to
automatically
> do a single-point maintenance of common reusable class behavior, which at
> the same time cuts down on the amount of written source code. There are
dangers
> about inheritance where behaviours that are overriden and subsequently
change
> can cause rippling issues throughout derived classes (as an example), so
> you have design and code carefully.
> Still, anyone who's really used it will tell you it can definitely be
useful.
>
> As for not creating inheritable classes...
> Well, again, this all boils down to design. I seem to remember that in
Java
> 1.1, there were some classes that weren't inheritatble, and members that
> were marked as final (not overridable) (some of the collection classes
come
> to mind) that caused programmers no end of frustration. When you design
good
> reusable code, there's no reason it shouldn't be inheritable.
>
> -Rob
>
> "Michael Culley" <mike@vbdotcom.com> wrote:
> >I'm reading dan applemans book 'moving to vb.net'. In it he says that
> >inheritance is practicly useless and he has only every used it 6 times in
> >his entire life (including other languages besides .net). He says that he
> >does inherit existing objects in dot net but has never found a use for
> >making an inheritable class himself. Ever since he gave webclasses a
glowing
> >review I doubt everything he says. Should I doubt this?
> >
> >--
> >Michael Culley
> >www.vbdotcom.com
>
>

[Mark Hurd]

"Zane Thomas [.NET MVP]" <zane@mabry.com> wrote in message
news:3c8f27c9.83589046@news.devx.com...
> On Thu, 21 Feb 2002 08:09:18 +1100, "Michael Culley" <mike@vbdotcom.com>
> wrote:
>
> >I'm reading dan applemans book 'moving to vb.net'. In it he says that
> >inheritance is practicly useless and he has only every used it 6 times in
> >his entire life (including other languages besides .net).

> <snip> If he took a peek inside the framework he would see
> that it uses inheritance. There are not deep inheritance trees - a good
> thing imo; inheritance is used sensibly.

I see the framework as a good source of ideas here. Many classes are inherited
from Object that I wouldn't have necessarily expected to be, plus there are
some deep hierarchies (mainly Windows.Forms) that are extremely powerful.

Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)