VB 1-3 Form - "functionally challenged"

[Rich]

Bob,

Again, a VB form is NOT an object in the pure sense. How can I inherit from
a VB 1-3 form? At very best it is a "functionally challenged" object. VB
users loosely using terms has caused VB users to be looked down on as hackers,
novices or a plethora of other unprofessional terms.

At this point, the PCers have not yet taken over VB terminology. Say and
think what you want. As I said before, just be careful where you say it.
It could tarnish your credibility.

I was simply attempting to help clarify some things. It seems like some of
the people here have minds like concrete - permanently set and all mixed
up. Then again, these people help keep my hourly rates high! I appreciate
you guys! :-)

Rich



--------------------------------------------------------------------------

Bob O`Bob <bob@cluestick.org> wrote:
>Rich wrote:
>>
>> If it was object based, where, in the VB 1-3 IDE, could you create a class
>> module? You could not.
>
>
>Wrong. On the File menu, the choice is "New Form"
>
>
>
> Bob
>--
>Life makes SO much less sense when you're sane.

[Mike Mitchell]

On 4 Sep 2001 05:02:28 -0700, "Rich" <nomail@nomail.com> wrote:

>Again, a VB form is NOT an object in the pure sense. How can I inherit from
>a VB 1-3 form? At very best it is a "functionally challenged" object. VB
>users loosely using terms has caused VB users to be looked down on as hackers,
>novices or a plethora of other unprofessional terms.

See, this is me being looked down upon as a hacker, a novice, a script
kiddie, a user of "toy" languages, or whatever else. Now do you see
the one finger I'm holding up?

MM

[Mark Alexander Bertenshaw]

Rich -

> Again, a VB form is NOT an object in the pure sense. How can I inherit
from
> a VB 1-3 form? At very best it is a "functionally challenged" object. VB
> users loosely using terms has caused VB users to be looked down on as
hackers,
> novices or a plethora of other unprofessional terms.

Have a look around the vb.oop newsgroup, and tell me that the guys there are
hackers, novices, and unprofessional. Whilst in many cases I believe there
_are_ people like Mike Mitchell who seem to have violent (and silly)
reactions to OOP, I know a lot of VB programmers who are completely clued
up, and know how to engineer software using OO methodologies.

In my course on Object Oriented concepts (and although this is ....way.....
back, I still have the notes), the three concepts that were made a language
object oriented are:

* Encapsulation
* Inheritance
* Polymorphism

Encapsulation is the most important concept, since it is ensures that a user
of a component (meant in the most generic sense) cannot access its data
directly. VB 1-3 did not allow this in VB code, but it did allow this for
3rd party components via the concept of VBX controls (which were accessed
via properties, which are essentially get_ and put_ methods in disguise).
This, and the availability of built in objects within the language is why I
would consider VB1-3 to be object based.
VB4 and onwards had the concept of Classes built into the language, which
finally did allow proper encapsulation in the language. However, I suppose
you could argue that this isn't 100% percent, since there are no language
mechanism for parameterised constructors. But then again, this is an
implementation dependent thing, and not essential, just very useful.

Inheritance is the ability to use a class that uses the features of another
class without having to rewrite that original class. In a way, this is a
kind of higher level version of the reusability of a function in an
old-fashioned procedural library. Now, how you achieve this i.e. the
implementation is what is usually is what people fight about. A lot of
people (including you, obviously) would say that unless this feature is
implemented in a language transparently, achieved by a combination of
compiler and run-time jiggery pokery, then that language is not using
inheritance. I would counter this and say that this view is far too
implementation concerned, and in fact my classes where I used encapsulation
and delegation are also using inheritance. In fact, my form of inheritance
is better, since it more controllable, now I don't have to mess around with
keywords like super *8-). Basically, languages such as smalltalk and java
are simply hunting for methods up and down the vtables behind your back, and
this can get very, very confusing.
So, by this token, VB4-6 implement inheritance, since you are easily able to
reuse your implementation of a class (or form). (Don't worry, I'm not going
to extend this definition to VB1-3 since reusing a form in another form is
only relevant in an MDI situation).

Finally, Polymorphism. This is generally the idea that an objects will be
able react differently to the same method, depending on the context in which
it is sent. There are two forms in which this normally takes. The version
which is used even in non-OO languages such as Ada is the ability to have a
number of methods, with the same method name, but with different parameters
distinguishing them. C++, and I think, Java use this mechanism. A more
recent extension of the same concept is the idea of interfaces which can be
implemented by a class with the intention to allow a class to be used _as_
another class. Java does this, and so does VB 5 and 6 - admittedly only
because it relies on COM.

So, you can understand why I believe that VB 4-6 to increasing extents are
in fact object-oriented languages. When it comes down to it, the essential
principle is encapsulation, and I think that VB does a pretty good job of
that. The implemtation inheritance angle is usually the "fatal flaw" by
many OOP "believers", but I think that it sometimes isn't all that great.
The neatest compromise is VB's implemtation of polymorphism which I think is
a fantastic feature - and pretty essential when doing COM programming.

> At this point, the PCers have not yet taken over VB terminology. Say and
> think what you want. As I said before, just be careful where you say it.
> It could tarnish your credibility.

PCers?

>
> I was simply attempting to help clarify some things. It seems like some of
> the people here have minds like concrete - permanently set and all mixed
> up. Then again, these people help keep my hourly rates high! I appreciate
> you guys! :-)

A tad patronising, maybe? Remember that from other people's point of view,
it is you who has the sedimented mind!

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software
Brentford
UK

[Joe \Nuke Me Xemu\ Foster]

"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message <news:3b957e6b@news.devx.com>...

> In my course on Object Oriented concepts (and although this is ....way.....
> back, I still have the notes), the three concepts that were made a language
> object oriented are:
>
> * Encapsulation
> * Inheritance
> * Polymorphism
>
> Encapsulation is the most important concept, since it is ensures that a user
> of a component (meant in the most generic sense) cannot access its data
> directly. VB 1-3 did not allow this in VB code, but it did allow this for
> 3rd party components via the concept of VBX controls (which were accessed
> via properties, which are essentially get_ and put_ methods in disguise).

Guess again! Modules could and did have private variables. Encapsulation
was around long, long before OOP, despite the best efforts of the Pure OOP
crowd to claim otherwise. Sure, Types are global, but that can be fixed by
passing around an index into a private array, instead of instances of the
Type. As for managing this array, the same "double the size" techniques
seen in such things as STL's vectors and Java's StringBuffer worked just as
well in VB3.

> This, and the availability of built in objects within the language is why I
> would consider VB1-3 to be object based.
> VB4 and onwards had the concept of Classes built into the language, which
> finally did allow proper encapsulation in the language. However, I suppose
> you could argue that this isn't 100% percent, since there are no language
> mechanism for parameterised constructors. But then again, this is an
> implementation dependent thing, and not essential, just very useful.

Pffft. Make the class public, but not publicly creatable, requiring the
use of the object factories provided.

> Inheritance is the ability to use a class that uses the features of another
> class without having to rewrite that original class. In a way, this is a
> kind of higher level version of the reusability of a function in an
> old-fashioned procedural library. Now, how you achieve this i.e. the
> implementation is what is usually is what people fight about. A lot of
> people (including you, obviously) would say that unless this feature is
> implemented in a language transparently, achieved by a combination of
> compiler and run-time jiggery pokery, then that language is not using
> inheritance. I would counter this and say that this view is far too
> implementation concerned, and in fact my classes where I used encapsulation
> and delegation are also using inheritance. In fact, my form of inheritance
> is better, since it more controllable, now I don't have to mess around with
> keywords like super *8-). Basically, languages such as smalltalk and java
> are simply hunting for methods up and down the vtables behind your back, and
> this can get very, very confusing.

Not much additional run-time jiggery pokery is needed if interface
inheritance is already supported.

> So, by this token, VB4-6 implement inheritance, since you are easily able to
> reuse your implementation of a class (or form). (Don't worry, I'm not going
> to extend this definition to VB1-3 since reusing a form in another form is
> only relevant in an MDI situation).

VB4 lacked Implements. It didn't lack, however, an add-in providing
implementation inheritance. Sure, it was a kludge, but it got the job
done by quittin' time.

> Finally, Polymorphism. This is generally the idea that an objects will be
> able react differently to the same method, depending on the context in which
> it is sent. There are two forms in which this normally takes. The version
> which is used even in non-OO languages such as Ada is the ability to have a
> number of methods, with the same method name, but with different parameters
> distinguishing them. C++, and I think, Java use this mechanism. A more

That's "overloading".

> recent extension of the same concept is the idea of interfaces which can be
> implemented by a class with the intention to allow a class to be used _as_
> another class. Java does this, and so does VB 5 and 6 - admittedly only
> because it relies on COM.

VB4 could as well, because of late binding. "Callback objects", anyone?

--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Larry Linson]

"Rich" <nomail@nomail.com> wrote:

> Again, a VB form is NOT an object in the pure
> sense. How can I inherit from a VB 1-3 form? At
> very best it is a "functionally challenged" object.

I don't believe anyone claimed what you deny. We just repeated _Microsoft's_
assertion that those versions were "object based", which they were. If I
understand correctly, most of the code implementing VB was/is C++ code. Neither
Microsoft nor Bob claimed that VB users had full access to object functionality,
but that's apparently not the criterion for being object based.

> VB users loosely using terms has caused VB users
> to be looked down on as hackers, novices or a
> plethora of other unprofessional terms.

Well, not all advocates of OO are, as you have shown yourself to be, arrogant
and condescending, so we don't need to warn all of them that acting in that
manner might cause them to be looked down on as jerks, or worse. Still, if
you believe that our bandying about the term "object based" makes us look
less than credible, you'd best pass that information on to the Boys and Girls
in Redmond who wrote VB and who've been telling the world since the early
1990s that "VB is not object-oriented, but it is object-based".

> I was simply attempting to help clarify some
> things. It seems like some of the people here
> have minds like concrete - permanently set and
> all mixed up. Then again, these people help keep
> my hourly rates high! I appreciate you guys! :-)

Well, well, not only is he confused about terminology and arrogant and condescending
to anyone who doesn't accept his personal definitions, he's another "rate
braggart", as well. You'd have a lot more credibility, even with the crowd
who agree with you that object-obsession is the answer to every question,
if you'll find a coach and take some humility lessons.

[Mark Alexander Bertenshaw]

"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
<news:3b957e6b@news.devx.com>...
>
>> In my course on Object Oriented concepts (and although this is ....way.....
>> back, I still have the notes), the three concepts that were made a language
>> object oriented are:
>>
>> * Encapsulation
>> * Inheritance
>> * Polymorphism
>>
>> Encapsulation is the most important concept, since it is ensures that
a user
>> of a component (meant in the most generic sense) cannot access its data
>> directly. VB 1-3 did not allow this in VB code, but it did allow this
for
>> 3rd party components via the concept of VBX controls (which were accessed
>> via properties, which are essentially get_ and put_ methods in disguise).
>
>Guess again! Modules could and did have private variables. Encapsulation
>was around long, long before OOP, despite the best efforts of the Pure OOP
>crowd to claim otherwise. Sure, Types are global, but that can be fixed
by
>passing around an index into a private array, instead of instances of the
>Type. As for managing this array, the same "double the size" techniques
>seen in such things as STL's vectors and Java's StringBuffer worked just
as
>well in VB3.

Ye gads, Joe! And I thought _I_ was stretching a point. Yes, you _could_
implement encapsulation via private data in modules. But you are missing
the fundemental difference between procedural and OO mechanisms. If you
have an object reference, you can _only_ affect data in that one instance.
If you try to do a similar thing using procedural mechanisms, then you must
either pass in an array index or a pointer to all the fake "methods" you
create in your module. Of course, the funny thing is that all OO languages
manage their topsy-turvey approach by passing an invisible "this" pointer
as the first parameter in all methods. You can have fun with this if you
follow the Curland book ...

>> This, and the availability of built in objects within the language is
why I
>> would consider VB1-3 to be object based.
>> VB4 and onwards had the concept of Classes built into the language, which
>> finally did allow proper encapsulation in the language. However, I suppose
>> you could argue that this isn't 100% percent, since there are no language
>> mechanism for parameterised constructors. But then again, this is an
>> implementation dependent thing, and not essential, just very useful.
>
>Pffft. Make the class public, but not publicly creatable, requiring the
>use of the object factories provided.

Yes, I do know this, and regularly implement this pattern. The point is
that it isn't built into the VB4-6 languages (although it is in .NET ...).

>> Inheritance is the ability to use a class that uses the features of another
>> class without having to rewrite that original class. In a way, this is
a
>> kind of higher level version of the reusability of a function in an
>> old-fashioned procedural library. Now, how you achieve this i.e. the
>> implementation is what is usually is what people fight about. A lot of
>> people (including you, obviously) would say that unless this feature is
>> implemented in a language transparently, achieved by a combination of
>> compiler and run-time jiggery pokery, then that language is not using
>> inheritance. I would counter this and say that this view is far too
>> implementation concerned, and in fact my classes where I used encapsulation
>> and delegation are also using inheritance. In fact, my form of inheritance
>> is better, since it more controllable, now I don't have to mess around
with
>> keywords like super *8-). Basically, languages such as smalltalk and
java
>> are simply hunting for methods up and down the vtables behind your back,
and
>> this can get very, very confusing.
>
>Not much additional run-time jiggery pokery is needed if interface
>inheritance is already supported.

Indeed.

>> So, by this token, VB4-6 implement inheritance, since you are easily able
to
>> reuse your implementation of a class (or form). (Don't worry, I'm not
going
>> to extend this definition to VB1-3 since reusing a form in another form
is
>> only relevant in an MDI situation).
>
>VB4 lacked Implements. It didn't lack, however, an add-in providing
>implementation inheritance. Sure, it was a kludge, but it got the job
>done by quittin' time.

What was this?

>> Finally, Polymorphism. This is generally the idea that an objects will
be
>> able react differently to the same method, depending on the context in
which
>> it is sent. There are two forms in which this normally takes. The version
>> which is used even in non-OO languages such as Ada is the ability to have
a
>> number of methods, with the same method name, but with different parameters
>> distinguishing them. C++, and I think, Java use this mechanism. A more
>
>That's "overloading".

Sigh. Completely correct. My excuse: it was 2:00 AM, and I felt that I
should finish the reply before I fell asleep.

>> recent extension of the same concept is the idea of interfaces which can
be
>> implemented by a class with the intention to allow a class to be used
_as_
>> another class. Java does this, and so does VB 5 and 6 - admittedly only
>> because it relies on COM.
>
>VB4 could as well, because of late binding. "Callback objects", anyone?

True ... but a bit crude.


--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software
Brentford
UK

[Bob]

"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
news:3b95fffc$1@news.devx.com...
>
> "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
> >"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
<snip>
> >VB4 lacked Implements. It didn't lack, however, an add-in providing
> >implementation inheritance. Sure, it was a kludge, but it got the job
> >done by quittin' time.
>
> What was this?
>

There was a 3rd party product that scanned VB code looking for special
comments and generating VB code that attempted to simulate implementation
inheritance. I had the misfortune of being forced to use this product on a
large project and it truly was a case of the cure being worse than the
disease.

Bob

[Mike Mitchell]

On Wed, 5 Sep 2001 02:29:26 +0100, "Mark Alexander Bertenshaw"
<mark.bertenshaw@virgin.net> wrote:

>Have a look around the vb.oop newsgroup, and tell me that the guys there are
>hackers, novices, and unprofessional. Whilst in many cases I believe there
>_are_ people like Mike Mitchell who seem to have violent (and silly)
>reactions to OOP, I know a lot of VB programmers who are completely clued
>up, and know how to engineer software using OO methodologies.

Where is the evidence that business applications are "better" when
written the pure OOP way compared with the traditional procedural way?
How many business apps do you imagine are done the OOP way compared
with the traditional procedural way? How do you explain the fact that
70% of applications written in Visual Basic do not employ objects
derived from classes the authors have written? If so many non-OOP
applications have been written, which they obvously have been, over
the past twenty years, do you suppose that *all* of them have failed?
If not (for to posit otherwise would be ludicrous), this must mean
that a non-OOP written application can be 100% successful in all
aspects and by all standards of measurement that could equally be
applied to an OOP version. Therefore, by definition, standard,
traditionally produced applications in business are capable of being
100% successful. To my mind, that is all the justification I need.

MM

[Joe \Nuke Me Xemu\ Foster]

"Bob" <tooslow42@yahoo.com> wrote in message <news:3b96400e$1@news.devx.com>...

> "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
> news:3b95fffc$1@news.devx.com...
> >
> > "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
> > >"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
> <snip>
> > >VB4 lacked Implements. It didn't lack, however, an add-in providing
> > >implementation inheritance. Sure, it was a kludge, but it got the job
> > >done by quittin' time.
> >
> > What was this?
> >
>
> There was a 3rd party product that scanned VB code looking for special
> comments and generating VB code that attempted to simulate implementation
> inheritance. I had the misfortune of being forced to use this product on a
> large project and it truly was a case of the cure being worse than the
> disease.

What was this? I don't recall Sheridan's ClassAssist working this way.
IIRC, ClassAssist had its own class files, from which it would generate
CLS files via copying (and perhaps renaming) inherited members into the
subclasses. One might get significant EXE/DLL code bloat, but run-time
performance need not suffer when A inherits from B, which inherits from
C, which inherits from D, etc etc etc.

--
Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Bob]

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3b97a7ab@news.devx.com...
> "Bob" <tooslow42@yahoo.com> wrote in message
<news:3b96400e$1@news.devx.com>...
>
> > "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in
message
> > news:3b95fffc$1@news.devx.com...
> > >
> > > "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
> > > >"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in
message
> > <snip>
> > > >VB4 lacked Implements. It didn't lack, however, an add-in providing
> > > >implementation inheritance. Sure, it was a kludge, but it got the
job
> > > >done by quittin' time.
> > >
> > > What was this?
> > >
> >
> > There was a 3rd party product that scanned VB code looking for special
> > comments and generating VB code that attempted to simulate
implementation
> > inheritance. I had the misfortune of being forced to use this product on
a
> > large project and it truly was a case of the cure being worse than the
> > disease.
>
> What was this? I don't recall Sheridan's ClassAssist working this way.
> IIRC, ClassAssist had its own class files, from which it would generate
> CLS files via copying (and perhaps renaming) inherited members into the
> subclasses. One might get significant EXE/DLL code bloat, but run-time
> performance need not suffer when A inherits from B, which inherits from
> C, which inherits from D, etc etc etc.
>
> --
> Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45
<http://www.xenu.net/>

Joe,

Yes, I'm talking about ClassAssist. It has been 5 years since I've used it,
but if I remember correctly, it looked for special comments in your code and
pulled in the appropriate code from an Access database that frequently got
corrupted and had to be manually corrected. It wasn't so much that the
concept was bad, but the implementation was horrible.

The C++ types running the project loved it. Those of us who had to use it on
a daily basis celebrated the day we got rid of it.

Bob

[Mark Alexander Bertenshaw]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3b96367e.13848026@news.devx.com...
> On Wed, 5 Sep 2001 02:29:26 +0100, "Mark Alexander Bertenshaw"
> <mark.bertenshaw@virgin.net> wrote:
>
> >Have a look around the vb.oop newsgroup, and tell me that the guys there
are
> >hackers, novices, and unprofessional. Whilst in many cases I believe
there
> >_are_ people like Mike Mitchell who seem to have violent (and silly)
> >reactions to OOP, I know a lot of VB programmers who are completely clued
> >up, and know how to engineer software using OO methodologies.
>
> Where is the evidence that business applications are "better" when
> written the pure OOP way compared with the traditional procedural way?

Mike - if you mean evidence as in surveys and studies in journals, etc. - I
haven't the slightest idea, although I would be as interested as you to know
more. I am talking purely from my experience from writing software, and
more specifically, from writing Visual Basic software. In my previous
statements, I never said that traditional procedural methods made
applications that were in any way "worse". I just believe, from comparing
my experiences working on serious projects in VB3 and VB5, that the OO
features in VB5 make writing business software easier, and far, far neater.

> How many business apps do you imagine are done the OOP way compared with
the traditional procedural way?

> How do you explain the fact that 70% of applications written in Visual
Basic do not employ objects derived from classes the authors have written?

Haven't the foggiest. If developers haven't taken advantage of these
features, then that suggests that either they had a very good reason not to,
or they are the kind of lazy programmers I would rather not work with. As
you can probably guess, in all but the most simplest of projects, I think
the latter more likely.

> If so many non-OOP
> applications have been written, which they obvously have been, over
> the past twenty years, do you suppose that *all* of them have failed?

Don't be silly - you are trying to characterise my argument as saying only
OO projects can work. Apart from the fact that this is not what I said, OO
methodology has only really seriously taken off in the last 10 years, so
your 20 year period is pointless.

> If not (for to posit otherwise would be ludicrous), this must mean
> that a non-OOP written application can be 100% successful in all
> aspects and by all standards of measurement that could equally be
> applied to an OOP version. Therefore, by definition, standard,
> traditionally produced applications in business are capable of being
> 100% successful. To my mind, that is all the justification I need.

Mike - this is the kind of sophistry that gives you a really bad karma on
these newsgroups. For every good point you might make, these flourishes
demolishes any kind of credibility you may have had up to that point.

>
> MM

Regards,

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software
Brentford
UK