Borland and me: We both want less code and more pictures!

[David Bayley]

Mike Mitchell wrote:

>> The availability of re-usable, protocol rich, components across
>> company boundaries, is something that has driven the popularity of
>> OOP languages. Even the anti-OO Mike Mitchell agrees with this
>> point, in that he advocates the easy re-use of other people's OO
>> components (so long as he doesn't have to write them himself!).
>
> But it's not the OOP aspect of those components that interests me,
> it's the components themselves. [...]

Yes it is the OO aspects of those components, you just don't realise it.
A component is a physical file that defines one or more Objects, and all
their associated meta-data.

> [...] Were VBX components written according
> to OOD principles?

Yes, they were. There is possibly a criticism that VBX/OCX components
are "Object-Based", rather than full blown "Object-Oriented", but I
think this is nit picking around the essence of OO.

> I lift the hood on my car and study the alternator. It makes juice for
> the battery. How it works internally interests me not one iota. If it
> breaks I can fit a new part for 50 bucks. End of story.

Bingo! Apply the same principles to your own modules, it really isn't
that difficult. There are even visual modelling tools around that I
guess you will find appealing, but they are rather expensive at the
moment.

--
David

[W.E. (Bill) Goodrich, PhD]

In article <3d6beb2c@10.1.10.29>,
"Tom Shelton" <toms@dakcs.com> writes:

> "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
> news:3d6bea9f.1221944@news.devx.com...

> > On Tue, 27 Aug 2002 11:15:03 -0600, "Tom Shelton"
> > <toms@dakcs.com> wrote:

> > >And there Mike is the beauty of OOP. It is so wonderful you
> > >finally got it! Welcome to the fold!

> > Excuse I, Mr Clever ****! Show me where I got down and dirty
> > with classes! Show me where I had to plan for my inheritance!
> > Show me where I first designed my object hierarchy! Those
> > components could be written in hand-coded assembler for all I
> > know (or care). I just use the results, and that's all I want to
> > know (or do).

> Again, you get it!

But apparently you don't. Or choose not to. He is very explicitly
pointing to the difference between modular programming (which he
supports) and OOP (which he doesn't). You (and others here) keep
trying to blur that distinction and muddy the debate by incorrectly
characterizing OOP as an improved version of modularity and thereby
claiming the benefits of modularity for OOP.

> That is the whole point of OOP - code reuse.

No, that is the whole point of modularity. The elements which
differentiate OOP from modularity actively weaken the benefits and
complicate the mechanics of code reuse. As he has repeatedly pointed
out.

> The user of your library cares nothing about implementation - only
> the interface and the results.

In modular programming that would be true. In OOP, the user also
cares about issues of inheritance, overloading, fragile base classes,
etc. Unlike a modular Black Box, the OOP libraries are white and gray
boxes. The issues of the "interface" of a class are far more complex
than those for a Black Box module. And the ability to corrupt the
behavior of class "methods" is far more easily available than any
ability to corrupt the behavior of black box modules. And the issues
surrounding the "results" are similarly impacted.

> It is modular programming taken to the next step.

No, it is modular programming corrupted and weakened by faddish
constructs. Contrary to your characterization, classes, inheritance,
overloading, etc. - those elements which differentiate OOP from
standard Modular Programming - weaken modularity.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Tom Shelton]

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
news:3D6C4291.63A22D8C@netzero.net...
> In article <3d6beb2c@10.1.10.29>,
> "Tom Shelton" <toms@dakcs.com> writes:
>
> > "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
> > news:3d6bea9f.1221944@news.devx.com...
>
> > > On Tue, 27 Aug 2002 11:15:03 -0600, "Tom Shelton"
> > > <toms@dakcs.com> wrote:
>
> > > >And there Mike is the beauty of OOP. It is so wonderful you
> > > >finally got it! Welcome to the fold!
>
> > > Excuse I, Mr Clever ****! Show me where I got down and dirty
> > > with classes! Show me where I had to plan for my inheritance!
> > > Show me where I first designed my object hierarchy! Those
> > > components could be written in hand-coded assembler for all I
> > > know (or care). I just use the results, and that's all I want to
> > > know (or do).
>
> > Again, you get it!
>
> But apparently you don't. Or choose not to. He is very explicitly
> pointing to the difference between modular programming (which he
> supports) and OOP (which he doesn't). You (and others here) keep
> trying to blur that distinction and muddy the debate by incorrectly
> characterizing OOP as an improved version of modularity and thereby
> claiming the benefits of modularity for OOP.

Nothing muddy about it - OOP IS an improved version of modular programming.

> > That is the whole point of OOP - code reuse.
>
> No, that is the whole point of modularity. The elements which
> differentiate OOP from modularity actively weaken the benefits and
> complicate the mechanics of code reuse. As he has repeatedly pointed
> out.

Not. There isn't much difference between a poorly written module and a
poorly written class. Though a well written class provids a lot more saftey
then a module.

> > The user of your library cares nothing about implementation - only
> > the interface and the results.
>
> In modular programming that would be true. In OOP, the user also
> cares about issues of inheritance, overloading, fragile base classes,
> etc. Unlike a modular Black Box, the OOP libraries are white and gray
> boxes. The issues of the "interface" of a class are far more complex
> than those for a Black Box module. And the ability to corrupt the
> behavior of class "methods" is far more easily available than any
> ability to corrupt the behavior of black box modules. And the issues
> surrounding the "results" are similarly impacted.

Bill, I can tell you have never worked with OOP. Most OOP languages draw a
strict line between interface and implementation. Providing very strict
access control to methods and fields. Something that is often not available
in more modular/procedural programming languages. Yes, you can get your
self in trouble if your not careful. I don't think anyone has ever said you
couldn't, but overall the benifits, IMHO and experience, far outway the
"pitfalls". If anything, OOP tends to force the developer to spend more
time in the design phase of the project - which is a good thing if you ask
me. VB and other procedural type languages tend to encourage the
design-as-you-code philosphy, and we both know what kind of mess that can
result in.

> > It is modular programming taken to the next step.
>
> No, it is modular programming corrupted and weakened by faddish
> constructs. Contrary to your characterization, classes, inheritance,
> overloading, etc. - those elements which differentiate OOP from
> standard Modular Programming - weaken modularity.

Bull crap, you can hardly call OOP a fad - it is a concept almost as old as
I am. But, hey in VB.NET you don't have to use OOP if you don't want to...
It still allows the same old object based, mixed mode, programming style of
VB.CLASSIC. And despite you and MM's tired claims to the contrary, I think
it has been amply shown that VB.NET makes most tasks simpler then
VB.CLASSIC. I can tell you, that now that I've been working almost
exclusively with C# (I know, I know, but that is the .NET language the
company I work for standardized on... Thank goodnes...) for the last few
months, I simply dread every time I have to open one of my VB5/6 programms
for maintenance.


Tom Shelton

[Zane Thomas]

On Tue, 27 Aug 2002 21:25:05 -0600, "W.E. (Bill) Goodrich, PhD"
<bgoodric@netzero.net> wrote:

>> It is modular programming taken to the next step.
>
>No, it is modular programming corrupted and weakened by faddish
>constructs.

I love it when you and your buddy Mikee so clearly expose your ignorance.
OOP has been around in various versions for well over 20 years. Smalltalk
and SCOOPS, for instance, predate c++ by several years. Object-oriented
languages and concepts were the subject of much research for a very long
time before they suddenly became fads to people like you.

If you don't want to stay current with programming technologies from the
80s then fine don't. But please try to scrape together $0.25 worth of
integrity and quit blathering on as if you know something about
programming ok?



--

*--------={ Fine Art for .NET }=--------*
| .Net Components @ www.abderaware.com |
*---------------------------------------*

Turn on, tune in, download.
zane a@t abderaware.com

[W.E. (Bill) Goodrich, PhD]

In article <3d6c463c@10.1.10.29>,
"Tom Shelton" <tom@mtogden.com> writes:

> "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
> news:3D6C4291.63A22D8C@netzero.net...

> > In article <3d6beb2c@10.1.10.29>,
> > "Tom Shelton" <toms@dakcs.com> writes:

> > > "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
> > > news:3d6bea9f.1221944@news.devx.com...

> > > > On Tue, 27 Aug 2002 11:15:03 -0600, "Tom Shelton"
> > > > <toms@dakcs.com> wrote:

> > > > >And there Mike is the beauty of OOP. It is so wonderful you
> > > > >finally got it! Welcome to the fold!

> > > > Excuse I, Mr Clever ****! Show me where I got down and dirty
> > > > with classes! Show me where I had to plan for my inheritance!
> > > > Show me where I first designed my object hierarchy! Those
> > > > components could be written in hand-coded assembler for all I
> > > > know (or care). I just use the results, and that's all I want
> > > > to know (or do).

> > > Again, you get it!

> > But apparently you don't. Or choose not to. He is very explicitly
> > pointing to the difference between modular programming (which he
> > supports) and OOP (which he doesn't). You (and others here) keep
> > trying to blur that distinction and muddy the debate by incorrectly
> > characterizing OOP as an improved version of modularity and thereby
> > claiming the benefits of modularity for OOP.

> Nothing muddy about it - OOP IS an improved version of modular
^^^^^^^^

To use the local vernacular, you misspelled "degraded". Having lost
the very essence of modularity, it is no longer modular programming.

> programming.

> > > That is the whole point of OOP - code reuse.

> > No, that is the whole point of modularity. The elements which
> > differentiate OOP from modularity actively weaken the benefits and
> > complicate the mechanics of code reuse. As he has repeatedly
> > pointed out.

> Not.

Deny it all you choose - the facts remain the facts. And I notice that
you were unable to offer even one substantial refutation. Plenty of ad
hominem, scatology, unsupported assertion, and the like. But no
substance.

> There isn't much difference between a poorly written module and a
> poorly written class.

I notice you pad your bet there. And in so doing, invalidate your
argument. Let's be specific here: EVERY potential problem with a
"poorly written module" is ALSO a potential problem with each and
every method of a poorly written class. You cannot name an exception,
because there are none. By contrast, there are many potential problems
with poorly written classes that are NOT applicable to a (non OOP)
module - even a poorly written one. How many of those can you name?
Here, I'll give you one for free: Fragile Base Class.

> Though a well written class provids a lot more saftey
> then a module.

Wrong. And again, your choice of wording (comparing "well written
class" with undifferentiated "module") shows your own lack of
confidence in your argument. You play the "well written" game so that
any specific elements used to refute your claim can be waved aside
with "But a 'well written' class would not..."). Inheritance,
overloading, etc. render even well written classes less safe than
the corresponding modules. Even the Academics have started to admit
that.

> > > The user of your library cares nothing about implementation -
> > > only the interface and the results.

> > In modular programming that would be true. In OOP, the user also
> > cares about issues of inheritance, overloading, fragile base classes,
> > etc. Unlike a modular Black Box, the OOP libraries are white and gray
> > boxes. The issues of the "interface" of a class are far more complex
> > than those for a Black Box module. And the ability to corrupt the
> > behavior of class "methods" is far more easily available than any
> > ability to corrupt the behavior of black box modules. And the issues
> > surrounding the "results" are similarly impacted.

> Bill, I can tell you have never worked with OOP.

Not only is that a rather pointless ad hominem, it is incorrect. I
have worked extensively with OOP, and seen many of the disastrous
problems I have been describing. Badly done OOP is even harder to
debug and maintain than old fashioned "spaghetti code" - especially
when the original designer(s) and/or programmer(s) are no longer
available.

> Most OOP languages draw a strict line between interface and
> implementation.

So do most modular languages, such as C. But nothing prevents a
programmer from circumventing that "strict line" in the OO languages.
In fact, mechanisms such as inheritance make it easier to do so in
the OO languages than in the modular languages.

> Providing very strict access control to methods and fields.

And then providing convenient ways to circumvent them. Thereby
rendering them LESS safe than the purely modular languages.

> Something that is often not available in more modular/procedural
> programming languages.

Nonsense. Even assemblers have tools for defining scope, etc. While
the modular "access control" mechanisms allow fewer options for
extending access in elaborate ways, that tends to render them more
(rather than less) secure. And unlike those elaborate OO constructs,
the modular access control mechanisms add little or no overhead.

> Yes, you can get your self in trouble if your not careful.

Exactly. More to the point, you can get yourself - and your
successors on the project - in trouble in more ways (and more
severely) in OOP than you can in MP. And in OOP you can get yourself
in trouble in ALL the same ways you can in MP, as well as in so many
ways which are unique to OOP.

> I don't think anyone has ever said you couldn't, but overall the
> benifits, IMHO and experience, far outway the "pitfalls".

Your mode of argument strongly indicates that your perception of those
benefits (and experiences) is heavily colored by your expectations -
your opinion. But as badly as you want to maintain that belief, your
doubts continue to leak out. You continue to "qualify" your claims and
attempt to shift the scope of the discussion (as below), as well as to
use ad hominem arguments and inappropriate language to draw attention
away from the substantial problems with your claims.

> If anything, OOP tends to force the developer to spend more time in
> the design phase of the project - which is a good thing if you ask
> me. VB and other procedural type languages tend to encourage the
> design-as-you-code philosphy, and we both know what kind of mess
> that can result in.

You *do* realize what you just wrote, don't you? You just declared OOP
inappropriate for RAD, for environments with evolving specs, and for the
VERY large percentage of IT and engineering shops in which the ratio
of design time to coding time is set by management fiat rather than
chosen by the programmer. Worse (from the standpoint of your thesis),
you have acknowledged MM's points about complexity and the fact that
OOP requires more design effort than MP.

If your work environment allows you the luxury of such extended design
phases, you could just as easily use that additional time to more
rigorously design an MP implementation. The argument that the tool
"forces" changes in management and programmer practice toward more
rigorous practices has been used - and refuted - since the early days
of "Structured Programming". In practice, "design-as-you-code" (with
minimal upfront design and incomplete specs) is far more prevalent
than extensive, lengthy, rigorous up-front design. And as long as
"time is money" in business, that will continue to be true. And in
such an environment, OOP is a recipe for disaster.

> > > It is modular programming taken to the next step.

> > No, it is modular programming corrupted and weakened by faddish
> > constructs. Contrary to your characterization, classes, inheritance,
> > overloading, etc. - those elements which differentiate OOP from
> > standard Modular Programming - weaken modularity.

> Bull crap,

There you go with your scatology. All that does is reinforce the idea
that your belief is emotional rather than rational.

> you can hardly call OOP a fad - it is a concept almost as old as
> I am.

I didn't realize you were that young. That explains some things. The
application of the OOP specific elements (as opposed to the MP
elements which you lump together with them) to general problem areas
rather than the relatively narrow and specialized areas of AI,
simulation, and the like is both relatively recent and distinctly
faddish. And as with most such fads, it is primarily supported by
emotional testimonials, subjective claims, and contrived comparisons
to unrealistic "samples" of other methodologies.

> But, hey in VB.NET you don't have to use OOP if you don't want to...

Really? I can define UDTs without them becoming Objects? And use them
as variable types rather than objects? I can use variants for my
"flexible" variables rather than using Objects?

> It still allows the same old object based, mixed mode, programming
> style of VB.CLASSIC.

Not quite. It can't do such "mixed mode" things as populating
contiguous UDT variables from - and saving them to - binary files. In
fact, there are quite a few such elements of VB.CLASSIC programming
that it does not allow.

> And despite you and MM's tired claims to the contrary, I think
> it has been amply shown that VB.NET makes most tasks simpler then
> VB.CLASSIC.

No at all. It has only been shown that it makes certain narrow
categories of tasks (such as ASP projects) simpler. OTOH, it HAS been
shown that it makes a wide variety of tasks and applications more
difficult or outright impossible. For instance, a program to read a
..WAV file, chart the samples, and allow manipulation of individual
data points (trivial in VB6) is far more complicated in VB.NET, and
impossible if the program has to run on Win95 machines in addition to
later systems.

> I can tell you, that now that I've been working almost exclusively
> with C# (I know, I know, but that is the .NET language the company
> I work for standardized on... Thank goodnes...)

Isn't it interesting how many of the most vocal and assertive
supporters of VB.NET are using C# instead?

> for the last few months, I simply dread every time I have to open
> one of my VB5/6 programms for maintenance.

Not surprising. Given the proclivities you have exhibited here, your
attempts to coerce VB5/6 into your notion of OOP must be nightmarish
to behold - much less to maintain.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Tom Shelton]

[snip pompus, insulting, and clueless arguments]

Bill we obviously disagree on the worth of OOP. But who cares, you don't
have to use it in VB.NET anymore then you have to in VB.CLASSIC. You can
continue to create modules and use them just like in VB.CLASSIC.

By the way, I use C# in .NET for 2 reasons:

1. My company standardized on it for the simple reason that we are primarily
a Unix shop. Until .NET I was basically the only full time windows guy in
the company. When .NET came out, we decided to create a Windows interface
for our Unix software - but since most of the guys are C/C++/Java guys it
made sense for use to use a C-style language.

2. I like it better. Simply because I prefer C-style syntax.

I'm not sure what other peoples reasons are.

Tom Shelton

[Patrick Troughton]

Well, there you go!

/Pat

"Keith" <keith@nospam_softwire.com> wrote:
>Well, I'm probably not the one you were looking for, but I guess I'll
>de-lurk for a moment. VS.Net was easier for us to integrate into for a
>couple of reasons. 1) MS provided support for integration as a product
>feature, rather than as and add-on to an existing product. This allowed
the
>integration to be deeper, so we can become more a part of VS than just an
>addition. (2) When you went under the hood, you can see a bit of the history
>of VB6. It did not present a consistent interface, and things were not
>always as they appeared. For example, the controls in VB6 appeared to be
COM
>objects, but they actually have a wrapper for extended properties. These
>objects don't really act quite like they should, and don't expose interfaces
>that are supposed to be there. I believe this just reflects that COM was
>added into VB afterwards, and they kept their control code rather than
>totally rewriting it. There were a number of areas where VB6 caused us to
>scratch our heads, and some, like control arrays, that we just couldn't
>support.
>
>In general, .Net has been a much more stable, efficient environment for
us,
>and I would suspect that MSs experience with VB addins and designers helped
>in their making it so. BTW, the subject of this thread was not lost on me.
>Any guesses as to how similar Delphi and VS are in terms of integration,
>given some of the common personnel? Just wondering Back to lurking.
>Keith

[W.E. (Bill) Goodrich, PhD]

In article <3d6d6f7c@10.1.10.29>,
"Tom Shelton" <tom@mtogden.com> writes:

.... a typical response from someone faced with the fact that he
cannot factually refute statements which threaten a cherished
belief. But no matter how hard you try to hide that fact from the
others here, you cannot hide the facts from yourself: you are unable
to name even one "unsafe" aspect of modular programming which does
not apply equally to the equivalent OOP. Not one. Nor can you hide
from yourself the emotional reaction that inability raises in you.

The facts remain. Best practices modular programs are at least as
safe as best practices OOP. Well written "standard practice" modular
programs are at least as safe as well written "standard practice" OOP.
Poorly written OOP programs are significantly less safe than poorly
written modular programs - there are more ways they can be unsafe. And
badly written OOP programs can be far more disastrous than badly
written modular programs, with misuse of classes, overloading, etc.

Your emotional reaction to those facts should tell you something.

> Bill we obviously disagree on the worth of OOP.

More on the dangers of OOP. You are willfully blind to their extent.
and I am not. And that affects evaluation of the risk/benefit ratio.

> But who cares,

Apparently, you do. You have invested a lot of emotion in your
attempts to evangelize OOP, and you react emotionally every time those
attempts faulter in the face of contradictory facts.

If you simply stuck to your "I like it better" argument, no one could
really refute you. But when you try making more objective claims,
such as increased safety, you are going to be challenged. And it is
going to take more than personal insults and mindless repetition of
buzzwords to answer those challenges.

> you don't have to use it in VB.NET anymore then you have to in
> VB.CLASSIC.

Wrong. Data structures - especially UDTs - are no longer "pure data".
They have been transformed into "objects", with the corresponding
drawbacks.

But the more interesting aspect of your statement is your shift from
your claims about "OOP" to other (also untrue) claims about VB.NET.
You have used such attempted shifts before, when you have faced your
inability to factually advance your argument.

> You can continue to create modules and use them just like in
> VB.CLASSIC.

Wrong. Since I cannot create data structures and use them "just like
in VB.CLASSIC" I cannot create and use modules in the same way.



--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Robert Lantry]

It's so fun watching you split hairs, further reducing any point you had
drivel. The greatest part of all is, given enough time, you argue yourself
right out of your own position.

You're brilliant Bill.


"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
news:3D73B68D.92681647@netzero.net...
> In article <3d6d6f7c@10.1.10.29>,
> "Tom Shelton" <tom@mtogden.com> writes:
>

[Tom Shelton]

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
news:3D73B68D.92681647@netzero.net...
> In article <3d6d6f7c@10.1.10.29>,
> "Tom Shelton" <tom@mtogden.com> writes:
>
> ... a typical response from someone faced with the fact that he
> cannot factually refute statements which threaten a cherished
> belief. But no matter how hard you try to hide that fact from the
> others here, you cannot hide the facts from yourself: you are unable
> to name even one "unsafe" aspect of modular programming which does
> not apply equally to the equivalent OOP. Not one. Nor can you hide
> from yourself the emotional reaction that inability raises in you.

No, it is the typical response from someone who is just fed up with your
double speak and hair splitting, as well as your insulting condecending
tone - Oh, great Bill, gift of the gods to all mortal programmers! If you
want to have a more in depth disscussion on this then fine. I have an open
mind. I personally like the OOP approach. Maybe because of my experience
with procedural languages such as C. In C the typical libary of functions
uses a struct and a bunch of functions that work on that struct. The struct
members are completly exposed to the client programmer - even if you don't
want them to touch them. The only way you have to enforce this is through
documentation - in C++ and other OO languages, you simply turn the object
into a class. Then you have total control over what members the client has
access to, as well as the freedom to change the underlying implementaion
without breaking client code. Not so with a struct. In reality a class is
not much more than a struct with access control and methods bound to it.

Does OOP have problems, sure. I tend to agree with you when it comes to
implementaion inheritance (to distinguish from interface inheritance, which
I think is fine). And I think this is generally true in the OO comunity.
Implementation inheritance can lead to some nasty problems if not used
correctly. In general, plain old delegation is the way to reuse an
implementation. That said, implentation inheritance is a valid tool and is
nice to have when used effectively.

Your other comments about VB.NET just show your ignorance of the product.
You can create and use a UDT in the same way as in VB.CLASSIC (except for
fixed size arrays and strings) and you access them in the same way. If your
worried about inheritance - don't. UDT's (structures) in .NET do not
participate in inheritance. Again, a VB.NET programmer does not need to
know very much more, if any more, about OOP then he did in VB.CLASSIC.
VB.NET is a mixed mode language - sort of like C++. You often use objects,
but you don't have to implement your own. How they are handled on the IL
level is, IMHO, irrelavent.

Tom Shelton

[Jason]

I must say that I personally find OOP to be a great improvement over modular,
procedural programming. When you get right down to it, passing around structures
to functions and using odd naming conventions usually turns out to be a hard
way of implementing OO, with the caveat that it is easy to break encapsulation
and difficult to implement inheritance (which is useful if used correctly
- and carefully).

I have seen bad OO designs. Yes. They usually stem from way too much planning
and too little doing, from academics who understand UML and not their customers'
needs. I have also seen good OO designs. Good OO designs can hide millions
of lines of complex code in ways that make them simple to use for developers.
Take a look at the "java.util" package in Java, or the System.IO packages
in .NET. They tackle some very difficult problems, but they aren't hard
to understand or use.

And, by the way, you can use these kinds of libraries using "best practices,"
or you can use "quick-and-dirty" programming, and the code ends up looking
much the same. No need for special naming conventions that make the code
nearly unreadable to the uninitiated, you know?

Just like anything else, you can do bad OO and you can do good OO. For really
big programs, I find that it is easier to do good OO than good modular procedural
programming. Just my 2 cents.

[Kunle Odutola]

W.E. (Bill) Goodrich, PhD wrote:
> In article <3d6d6f7c@10.1.10.29>,
> "Tom Shelton" <tom@mtogden.com> writes:
>
> ... a typical response from someone faced with the fact that he
> cannot factually refute statements which threaten a cherished
> belief. But no matter how hard you try to hide that fact from the
> others here, you cannot hide the facts from yourself: you are unable
> to name even one "unsafe" aspect of modular programming which does
> not apply equally to the equivalent OOP. Not one. Nor can you hide
> from yourself the emotional reaction that inability raises in you.

1. To implement an ADT that is similar but not identical to an exisitng ADT,
you *have* to copy and paste a lot of code.

OOP: With OOP you have the option of white-box inheritance
(implementation inheritance) or black-box inheritance
(delegation/composition or interface inheritance).

2. Given an ADT, there is no easy way to find all operations that apply to
it (all it's creation/destruction/accessor/mutator/service functions).
Typically, a text search of the source code base is required.

OOP: With OOP, all the operations are part of the definition of it's
expanded ADT concept - the object/class.

3. Developing and using containers (array, lists, stacks, trees, graphs etc)
that can store multiple datatypes requires "code hackery".

OOP: It's trivial. Implement a container that can store anything and use
the appropriate type of inheritance to create sub-classes that can store
whatever subset takes your fancy. It's so trivial most OO systems include
them for free.

3. Because data structures are not bound to the operations that are valid
for them and, there is no acces control, it is easy (and a common occurence
in reality) to break the "contract" for the correct use of all and any ADT
(well-designed or not).

OOP: Try doing that to a well-defined object!

There are more but this will do for the moment.


> The facts remain. Best practices modular programs are at least as
> safe as best practices OOP.

You assume OOP does not have any new tools to deal with problems with MP and
ypu are wrong in that respect.

> Well written "standard practice" modular
> programs are at least as safe as well written "standard practice" OOP.

I have already shown that to be false above.

>> you don't have to use it in VB.NET anymore then you have to in
>> VB.CLASSIC.
>
> Wrong. Data structures - especially UDTs - are no longer "pure data".
> They have been transformed into "objects", with the corresponding
> drawbacks.

No. Structs in VB.NET are "value types". They can be "boxed" into "reference
types" (aka.objects) and treated as such but, they aren't objects. If we
were discussing Smalltalk, you would be right but, I do not recall *any*
drawbacks to Smalltalk because of it's everything is an object purity. Can
you present any?

>> You can continue to create modules and use them just like in
>> VB.CLASSIC.
>
> Wrong. Since I cannot create data structures and use them "just like
> in VB.CLASSIC" I cannot create and use modules in the same way.

Yes you can. If you used VB.NET that is....

Kunle

[W.E. (Bill) Goodrich, PhD]

In article <3d73e0e4@10.1.10.29>,
"Tom Shelton" <tom@mtogden.com> writes:

> "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in
> message news:3D73B68D.92681647@netzero.net...

> > In article <3d6d6f7c@10.1.10.29>,
> > "Tom Shelton" <tom@mtogden.com> writes:

> > ... a typical response from someone faced with the fact that he
> > cannot factually refute statements which threaten a cherished
> > belief. But no matter how hard you try to hide that fact from the
> > others here, you cannot hide the facts from yourself: you are unable
> > to name even one "unsafe" aspect of modular programming which does
> > not apply equally to the equivalent OOP. Not one. Nor can you hide
> > from yourself the emotional reaction that inability raises in you.

> No, it is the typical response from someone who is just fed up
> with your double speak and hair splitting, as well as your
> insulting condecending tone - Oh, great Bill, gift of the gods to
> all mortal programmers!

There you go again - foaming at the keyboard because someone had the
temerity to expose the flaws in your ex cathedra pronouncements about
OOP. Which part was the "hair splitting" - the part where I indicated
that your "safety" pronouncement was 100% wrong, or the part where I
noted the difference between debating modalities (OOP, MP, etc.) and
debating aspects of specific programming languages (e.g. VB.NET)? And
how is my "tone" any more insulting than your recent characterizations?

> If you want to have a more in depth disscussion on this then fine.

That would make a pleasant change.

> I have an open mind.

You have not demonstrated that so far.

> I personally like the OOP approach.

That is fine, as far as it goes. The problem comes in when you try to
translate that personal preference into arguments concerning its
objective value as a general purpose approach.

> Maybe because of my experience with procedural languages such as C.

And once again, you go from discussion of a modality (OOP) to
discussion of a language. And in the process, entirely avoid the issue
of OOP vs MP.

> In C the typical libary of functions uses a struct and a bunch of
> functions that work on that struct.

Often more than one struct. And often, it made more sense to make the
functions operate on a passed struct.

> The struct members are completly exposed to the client programmer -
> even if you don't want them to touch them.

Nonsense. Any competent C programmer knew to use blocking to limit
the scope of the variables. If you chose to ignore that mechanism,
you were doing the same thing as declaring your class members
"public" in your sainted VB.NET. And again, the language specifics
have nothing to do with the modality issues. Modular programming
as a modality calls for such scope limitation on variables.

> The only way you have to enforce this is through documentation

Nonsense. You could (and we did) enforce it by use of blocking. You
could have solved your entire problem with a simple pair of curly
brackets.

> - in C++ and other OO languages, you simply turn the object into a
> class.

And in C, you just block the variable to the appropriate scope.

> Then you have total control over what members the client has access
> to,

Producing LESS, rather than more, safety than the all or nothing
protection of C blocking. Not to mention the additional complexity
and overhead, and the potential for significant cascade problems
from changes to those permissions.

> as well as the freedom to change the underlying implementaion
> without breaking client code.

In theory, perhaps. In practice, it provides a mechanism for MASSIVE
disruption of the client code if handled the least bit wrong. As
opposed to the MP model of the IPO Black Box, which DOES allow the
freedom to change the underlying implementation without breaking
client code.

Let's take the classic instance of changing a data member to a
put/get pair of methods. And then have the get method do something
more than just return the value of the variable. Trouble, right here
in River City. Various kinds of conditional execution statements,
procedure (/sub/function/method/etc.) calls, and other elements which
would not even be expected to access the value under the circumstances
at hand will invoke the method anyway - with undesirable (and
difficult to trace) results.

> Not so with a struct.

With a struct, the issue of "changing the underlying implementation"
is largely limited to retyping elements, rearranging fields, and
adding/removing them. And - when shifting from platform to platform -
changing the size of individual elements (e.g. 16/32 bit integers). All
apply equally to the OOP classes. But as noted above, the classes
allow far more dangerous issues to imperil the client code.

> In reality a class is not much more than a struct with access
> control and methods bound to it.

Not "much more" - just enough more to seriously reduce the safety of
classes relative to that of equivalent combinations of structs and
functions. Especially if those structs and functions were implemented
in MP fashion.

> Does OOP have problems, sure. I tend to agree with you when it
> comes to implementaion inheritance (to distinguish from interface
> inheritance, which I think is fine). And I think this is generally
> true in the OO comunity.

As you say, you "think" that is so. In practice, there are two major
parts of the "OO community" - those thoughtfully and strictly using
the OOD/OOP modality, and those doing time-pressured, any way
programming using OO tools. The latter group - the equivalent of the
non-OO ones you keep trying to compare OOP to - is the breeding
ground for the kinds of problems I have been citing. And by and
large, they outnumber the "thoughtful" group by a wide margin in the
professional programming community. More so, when you remove
"independent contractor/consultants" from the mix.

> Implementation inheritance can lead to some nasty problems if not
> used correctly.

And that is inherent to OOP. Thus it is one element of the "OOP is
less safe than MP" argument.

> In general, plain old delegation is the way to reuse an
> implementation.

And reuse of properly modular code is even simpler. And safer.

> That said, implentation inheritance is a valid tool and is
> nice to have when used effectively.

And horrific when later changed in an inappropriate way - a maintenance
issue some of us have had to deal with.

> Your other comments about VB.NET just show your ignorance of the
> product.

No, just your own blindness with regard to it.

> You can create and use a UDT in the same way as in VB.CLASSIC

Here you make a claim...

> (except for fixed size arrays and strings)

....and here you refute it all by yourself. Interesting that when I
point out that there are such differences, it is "ignorance of the
product" but somehow YOUR statements to the same effect are not. And
those are not exactly trivial exceptions. However, there is more.

> and you access them in the same way.

Not quite. In VB6, structures occupy contiguous blocks of memory,
allowing certain useful (but politically incorrect) speedups. Such
techniques cannot be used with VB.NET.

> If your worried about inheritance - don't.

I'm not. There are enough other problems to relegate that one to a low
position on the list.

> UDT's (structures) in .NET do not participate in inheritance.

Unless, of course, you are trying to define a UDT which contains
another UDT. The resulting mess is quite interesting.

> Again, a VB.NET programmer does not need to know very much more,
> if any more, about OOP then he did in VB.CLASSIC.

There you go again with the weasel words. What is "not much" to you
may be VERY much to the sorts of non-Programmers (subject area experts
with little or no CS background) who have done so well with VB.Classic.
And then there is the little matter of learning - and understanding -
all those necessary details of the CLR (most, if not all, of which are
solely documented in OOP terms).

> VB.NET is a mixed mode language - sort of like C++.

Far less so than VB6.

> You often use objects, but you don't have to implement your own.

As long as you don't use any UDTs or equivalents of the VB.Classic
Variant data type.

> How they are handled on the IL level is, IMHO, irrelavent.

For the types of applications you limit yourself to, perhaps. For the
types of applications I have spent much of my career on, it is VERY
relevant - as shown in the "UDT vs class" discussion above.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Kunle Odutola]

W.E. (Bill) Goodrich, PhD wrote:

>> The struct members are completly exposed to the client programmer -
>> even if you don't want them to touch them.
>
> Nonsense. Any competent C programmer knew to use blocking to limit
> the scope of the variables.

This isn't about variable visibility and scoping. The definitions of those
structs are available to all clients -- <quote>The struct *members*
are...</quote>.

With any rebuff, pls please post an example of using C's mechanism for
dealing with this issue.

Kunle

[W.E. (Bill) Goodrich, PhD]

In article <3d76898c@10.1.10.29>,
"Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk>
writes:

> W.E. (Bill) Goodrich, PhD wrote:

> >> The struct members are completly exposed to the client programmer -
> >> even if you don't want them to touch them.

> > Nonsense. Any competent C programmer knew to use blocking to limit
> > the scope of the variables.

> This isn't about variable visibility and scoping. The definitions
> of those structs are available to all clients -- <quote>The struct
> *members* are...</quote>.

Try not to make your trolling quite so obvious. Or is it your
illiteracy? Even the limited snippet you quoted established that the
issue was whether the client can "touch" them. If the struct is not
available to the client, the individual members are unavailable as
well.

> With any rebuff, pls please post an example of using C's mechanism
> for dealing with this issue.

Do not distribute the source code. The precompiled .obj (or system
local equivalent) file does not expose those definitions.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*