User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Larry Serflaten on 7 Sep 2009 00:46 "Ralph" <nt_consulting64(a)yahoo.com> wrote > I get annoyed everytime I hear the expression "VB cannot do *real* > inheritance". <snipped for brievity> I'd agree with that sentiment. VB can't do 'real' inheritance. For me inheritance includes the implementation as well as the interface. VB's 'interface inheritance' is more like interface duplication, from which you get polymorphism. When a VB class implements an interface, it has to implement all the members of that interface, even where the code is a duplication of whats in the base class. Even if the class delegates to an internally held base class, its still a duplication in that the world calls on an inheirited member, and the class in turn calls on the base class member. A process that is duplicated for every level of inheiritance. Another thing which doesn't sit right with me, if B inheirits A, and C inheirits B, then the C object should be able to called like an object of type A. Something VB's 'interface inheiritance' doesn't do. In other words, it doesn't go multi-levels, like 'true' inheiritance should.... <insert>2 cents</insert> LFS
From: Ralph on 7 Sep 2009 04:52 Larry Serflaten wrote: > "Ralph" <nt_consulting64(a)yahoo.com> wrote > >> I get annoyed everytime I hear the expression "VB cannot do *real* >> inheritance". > <snipped for brievity> > > I'd agree with that sentiment. VB can't do 'real' inheritance. > > For me inheritance includes the implementation as well as the > interface. > > VB's 'interface inheritance' is more like interface duplication, from > which you get polymorphism. When a VB class implements an interface, > it has to implement all the members of that interface, even where the > code is a duplication of whats in the base class. > > Even if the class delegates to an internally held base class, its > still a duplication in that the world calls on an inheirited member, > and the class in turn calls on the base class member. A process that > is duplicated for every level of inheiritance. > > Another thing which doesn't sit right with me, if B inheirits A, > and C inheirits B, then the C object should be able to called > like an object of type A. Something VB's 'interface inheiritance' > doesn't do. In other words, it doesn't go multi-levels, like 'true' > inheiritance should.... > > <insert>2 cents</insert> > LFS Agree on all counts. But appreciate that what you are describing are all coding constructs, or tools, that may be available to an OOPL to make an OO programmer's life easier and aid in producing a better representation in code of a particular OOA/OOD model. It has no impact on whether VB, as feature limited as it is as an OOPL, can or can not do *real* inheritance. Nor more specifically have any impact on whether or not the OP can implement a solution in VB. -ralph
From: Larry Serflaten on 7 Sep 2009 05:36 "Ralph" <nt_consulting64(a)yahoo.com> wrote > But appreciate that what you are describing are all coding constructs, or > tools, that may be available to an OOPL to make an OO programmer's life > easier and aid in producing a better representation in code of a particular > OOA/OOD model. It has no impact on whether VB, as feature limited as it is > as an OOPL, can or can not do *real* inheritance. I don't get it. You describe what inheiritance is, and say VB can't do that, but don't agree that VB doesn't do real inheiritance??? eg: --- Note that this "inheritance" only exists in code, when the program runs there is no object created from Class A or Class B - all we get is a "C" object. VB doesn't support that kind of short-cut. --- That's no shortcut, that is inheiritance, which you agree VB doesn't do.... LFS
From: Ralph on 7 Sep 2009 11:44 Larry Serflaten wrote: > "Ralph" <nt_consulting64(a)yahoo.com> wrote > >> But appreciate that what you are describing are all coding >> constructs, or tools, that may be available to an OOPL to make an OO >> programmer's life easier and aid in producing a better >> representation in code of a particular OOA/OOD model. It has no >> impact on whether VB, as feature limited as it is as an OOPL, can or >> can not do *real* inheritance. > > I don't get it. You describe what inheiritance is, and say VB can't > do that, but don't agree that VB doesn't do real inheiritance??? > > eg: --- > Note that this "inheritance" only exists in code, when the program > runs there is no object created from Class A or Class B - all we get > is a "C" object. > > VB doesn't support that kind of short-cut. > --- > > That's no shortcut, that is inheiritance, which you agree VB doesn't > do.... > Yes that is "inheritance" - one kind of implementation tool, a convenient programming construct (and sorry a short-cut) for achieving some desired result. The VB OOPL doesn't support that construct, but you can still achieve the desired result. So does that mean VB doesn't support *real* inheritance? You are suggesting that it doesn't as you define specific constructions as the only *real* "inheritance". I'm only pointing out that one construct is no more *real* than another in implementing an OO solution. Inheritance as a concept is so simple, and as a construct so handy, that it has become a mainstay of most OOPLs. But dwelling on inheritance, or in particular labeling one code construct as more *real* than another tends to cloud the *real* aspects of an OO solution - object associations (messaging) and specialization. All supported or *doable* in VB with or without constructs available in other OOPLs. Thus IMHO, when someone says ""VB cannot do real inheritance", what they are really saying is the VB OOPL cannot support a particular coding construct which is true. But unfortunately what they are often also implying with the use of the term *real* is that VB is somehow equally unable to provide an OO solution. To do so is to misunderstand what inheritance really is and lose sight of the *real* fundamentals of OO. -ralph
From: Larry Serflaten on 7 Sep 2009 16:17
"Ralph" <nt_consulting64(a)yahoo.com> wrote > Thus IMHO, when someone says ""VB cannot do real inheritance", what they are > really saying is the VB OOPL cannot support a particular coding construct > which is true. But unfortunately what they are often also implying with the > use of the term *real* is that VB is somehow equally unable to provide an OO > solution. OK I now understand what you disagree with. But you when you take things at face value, the statement it true. If I give you a DLL that exposes a class and that class has multiple interfaces, you can't inheirit from that class and get all the other implemented interfaces. A full OOPL would be able to to that. So it is entirely accurate to say VB doesn't support real inheiritance. It does go part way with interface inheiritance, but it is a limited implementation. What you seem to be saying (using another scenareo) is that you'd disagree with the statement that VB doesn't support pointers. That also is true, at face value. But we all know that anything passed by reference is actually passing a pointer, so you'd say VB does support pointers, just not the 'construct' that most would want to use. (eg; pointer arithmetics). There is a difference in what is supported, and what is able to be done. When someone says something isn't supported, you take a position that they are saying it can't be done. I'd suggest we stick with face value. If they say it isn't supported, they mean it isn't supported. If they say it can't be done, they mean it can't be done.... <shrug> LFS |