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

[Tom Shelton]

<Blah, Blah, Blah>

> > 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.

And you have?... sheese.

> > 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.

My comment was not meant to imply that it was... but you knew that. You
have mastered the art of arguing the irrelevant...

> > 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.

As if that is relavant to the discussion - and please explain how it makes
more sense to pass a struct then to call a method of a class.

> > 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.

Bill, you can not limit the accessability of a struct member in C. The
client programmers must have the definition of the struct, and are there for
able to access it's members directly. There is nothing in the language to
limit there access to those members. Please demenstrate how you can do
limit the scope of a struct member using blocks?

> > 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.

Please demonstrate how this is possible and still have valid code. You must
provide the definition of the struct, and there is no way in C to prevent
access to that's structs members. It is completly up to the client
programmer to make sure that they keep there mits off.

> > - 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.

Again that makes no sense. If you are creating a libary for use by
clients - then you must expose the functions and struct definitions -
usually in the form of a header file and the at least the precompiled
implementation in the form of a .o or libary file.

> > 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.

Again, when dealing with libaries - it is all nothing in C. The only part
of your code that can be protected in your libary is your implementation,
but all of the function definitions and struct definitions must be provided
so that the compiler can allocate the right amount of storage.

> > 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.

First of all just changing to a get/let pair from a publicly exposed
variable is going to disrupt client code. You should never expose field
values directly for this very reason. That's why properties in VB are so
cool - they give the feel of field access, but the implementation freedom of
a method.

I'd also like you to tell me, what the difference is between passing a
struct to a method in a module, compared to calling a method on a class. In
either case you are not privy to the implementation (unless you are the
author of the libary) and you have no idea what other methods the module is
going to call. And since classes are self contained namespaces - they do
not interact with any data outside what they contain.

> > 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.

how? when using Delegation it is the same as referencing a module from
another module.

> > 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.

You implied that they were totally different. I was saying they are not -
with a couple of exceptions.

> > 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.

<StructLayout(LayoutKind.Sequential)> - aren't attributes beautiful... Oh,
and by the way there is also a VBFixedArrayAttribute and
VBFixedStringAttribute as well... So, in reality you can create a struct
with the exact same layout as you can in VB.CLASSIC. Not only that, using
LayoutKind.Explicit - you can create unions as well.

> 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.

Do it all the time, not sure what your getting at here...

> > 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).

There you go with the word twisting again. You know exactly what I meant.
The Framework can be simply a large component library as far as the VB
programmer is concerned. For the vast majority of programmers that's all it
need be. If you want to do certain things like, create your own stream
classes then yes, your going to have to understand inheritance - but how
many VB programmers are going to create there own streams?

> > VB.NET is a mixed mode language - sort of like C++.
>
> Far less so than VB6.

Yes, becase VB.NET allows you to take advantage of the full OOP paradigm,
where as VB.CLASSIC only exposes a limited subset. If your implying that it
is because it lets you use more OOP constructs then please epxlain how that
makes it less a mixed mode? It just like C++ allows you to do plain C,
VB.NET lets you do VB.CLASSIC style programming.

> > 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 many times does this have to be explained - Object is a complete
replacement for Variant.

Dim o As Object

o = "Hello, World!"
o = 1
o = o + 2
.....

Can you give me one example of Variant usage that I can not duplicate using
Object? Besides, Variant is the devil...

> > 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.

All the UDT vs. Class disscussion above revealed is that you haven't used
VB.NET or the .NET framework to know what your talking about. I have not
found anything I could do in VB.CLASSIC that I can't do in VB.NET - and 98%
of the time easier.

Tom Shelton

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

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

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

> > 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.

> Bill, you have to publish the definitions to the client, or the
> code using them won't compile - that is what the purpose of a .h
> file.

Learn to read, Tom. I know that asking you to learn to think would be
too much too soon. If you do not want the client to "touch" the
structure, you do not add it to any .h file - there is no reason to
do so. And the whole "precompiled" thing seems to have slipped by
you entirely. Once again, in small steps:

1) Define the "limited access" structs and variables WITHIN blocks
(rather than before the first block) in the source for the module
in question. Make sure all of the functions which access those
limited-access vars and structs are also within the same blocks.

2) Compile the source into a .obj (or .o or whatever the local dialect
calls for) file.

3) Prepare a .h file which ONLY contains those variables and functions
which you want the client to touch.

4) distribute ONLY the .obj (or .o or whatever) file and the limited
.h file to the client.

The result of this is that the client has no direct access to the "no
access" structures and variables, and no access to the UDT definitions
in the module (except those deliberately added to the .h file). This
process prevents the client from touching those structure members which
you do not want them to touch. It does so on the basis of the whole
structure, rather than member by member - safer, but less flexible.

> The compiler has to know how much space to allocate for a struct of
> a type.

And it does - in step 2 above.

> I would sure like to see an example of exactly how you distribute
> a C code library that:

> 1. doesn't define functions and structs in a .h file for the client
> to reference.

Remembering that those are the structs that you were complaining that
you didn't WANT the client to touch. Try to stay on track, Tom.

> 2. doesn't distribute a .o or .a file so that the compiler can link
> the definitions to the implementations.

Learn to read, Tom. I very EXPLICITLY called for distribution of the
object file (whatever the designation: .obj, .o, whatever). Or are
you just trying to blow more smoke?


--

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]

> > Bill, you have to publish the definitions to the client, or the
> > code using them won't compile - that is what the purpose of a .h
> > file.
>
> Learn to read, Tom. I know that asking you to learn to think would be
> too much too soon. If you do not want the client to "touch" the
> structure, you do not add it to any .h file - there is no reason to
> do so. And the whole "precompiled" thing seems to have slipped by
> you entirely. Once again, in small steps:
>
> 1) Define the "limited access" structs and variables WITHIN blocks
> (rather than before the first block) in the source for the module
> in question. Make sure all of the functions which access those
> limited-access vars and structs are also within the same blocks.
>
> 2) Compile the source into a .obj (or .o or whatever the local dialect
> calls for) file.
>
> 3) Prepare a .h file which ONLY contains those variables and functions
> which you want the client to touch.
>
> 4) distribute ONLY the .obj (or .o or whatever) file and the limited
> .h file to the client.
>
> The result of this is that the client has no direct access to the "no
> access" structures and variables, and no access to the UDT definitions
> in the module (except those deliberately added to the .h file). This
> process prevents the client from touching those structure members which
> you do not want them to touch. It does so on the basis of the whole
> structure, rather than member by member - safer, but less flexible.

Bill - explain to me how this helps... It doesn't. Sure you can implement
structs and functions that can't be seen by the client, but you are still
marginalizing the issue. Look here is a simple example, say you have a
simple linked list.. You have all the functions necessary to manipulate
this list - how do you expose it so that the client doesn't screw with your
next pointer? YOU CAN'T. A great many C libraries use code that looks
something like this:

typedef struct MYSTRUCT s;
InitailizeTheStruct(&s);
DoStuffWithThStruct(&s);
printf("The value: %d", s.theValue);
CleanUpTheStruct(&s);

The reason for this is that often times there is state information in the
struct that needs to be kept, and there is no easy way to do that in the
library. So tell me genious, how do you keep joe c programmer from
accessing say s.State? YOU DON'T. You document it and say, don't access
s.State or call it s.Reserved or some such nonsense. With c++ it is a
simple matter:

MyClass s; // we just initialized it.
s.DoStuffWithTheClass(); // we did stuff
cout << "The value: " << s.theValue() << endl;

We have less code - at least for the client, and the class can keep it's own
state and there is no way joe c++ programmer can mess with your precious
state.

> > The compiler has to know how much space to allocate for a struct of
> > a type.
>
> And it does - in step 2 above.
>
> > I would sure like to see an example of exactly how you distribute
> > a C code library that:
>
> > 1. doesn't define functions and structs in a .h file for the client
> > to reference.
>
> Remembering that those are the structs that you were complaining that
> you didn't WANT the client to touch. Try to stay on track, Tom.

My point is that many times you need to keep state between calls to your
library. Where do you do that, hmmm? Well generally it's done by storing
it in the struct exposed to the client - since it would be hard to do it in
the library itself - probably not impossable, but difficult and probably
slow. So, tell me Bill how do you prevent the client from doing something
like:

myStruct.State = ALL_SCREWED_UP;

> > 2. doesn't distribute a .o or .a file so that the compiler can link
> > the definitions to the implementations.
>
> Learn to read, Tom. I very EXPLICITLY called for distribution of the
> object file (whatever the designation: .obj, .o, whatever). Or are
> you just trying to blow more smoke?

Simple misunderstanding, I see that now... It was just a misreading... I
apologize for that.

Tom Shelton

[Mark Hurd]

Tom Shelton <tom@mtogden.com> wrote:
>
> Bill, you can not limit the accessability of a struct member in C. The
> client programmers must have the definition of the struct, and are there for
> able to access it's members directly. There is nothing in the language to
> limit there access to those members. Please demenstrate how you can do
> limit the scope of a struct member using blocks?

Have a look at Handles in the WinAPI. Conceptually they are double pointers,
that is **WinStruct for some relevant Windows structure. However, most of them
are just seen as pointers to nominal struct with no useful content. I think
there's a C preprocessor macro called MAKEHANDLE in windows.h or some included
file.

Now, in general, we Windows programmers don't get any information about the
actual content of "WinStruct". We just get given APIs that return what we're
allowed to see. Of course, optimisations mean that sometimes WinStruct or part
of it is exposed.

And I should say that all of this is available to do in VB.NET too (except for
the whole decompilation problem).

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

[Tom Shelton]

"Mark Hurd" <markhurd@ozemail.com.au> wrote in message
news:3d76d2dc@10.1.10.29...
> Tom Shelton <tom@mtogden.com> wrote:
> >
> > Bill, you can not limit the accessability of a struct member in C. The
> > client programmers must have the definition of the struct, and are there
for
> > able to access it's members directly. There is nothing in the language
to
> > limit there access to those members. Please demenstrate how you can do
> > limit the scope of a struct member using blocks?
>
> Have a look at Handles in the WinAPI. Conceptually they are double
pointers,
> that is **WinStruct for some relevant Windows structure. However, most of
them
> are just seen as pointers to nominal struct with no useful content. I
think
> there's a C preprocessor macro called MAKEHANDLE in windows.h or some
included
> file.
>
> Now, in general, we Windows programmers don't get any information about
the
> actual content of "WinStruct". We just get given APIs that return what
we're
> allowed to see. Of course, optimisations mean that sometimes WinStruct or
part
> of it is exposed.
>
> And I should say that all of this is available to do in VB.NET too (except
for
> the whole decompilation problem).

Mark,

I understand what you are saying, and that is a good point. I can see where
this may work as a partial solution... You could put a similar member in a
struct to maintain some sort of state information, but that still doesn't
completly protect you from joe c programmer messing with the pointer...

Tom Shelton

[Phil Weber]

> So tell me genious...

<snicker>

[Mark Hurd]

Tom Shelton <tom@mtogden.com> wrote:
>
> I understand what you are saying, and that is a good point. I can see where
> this may work as a partial solution... You could put a similar member in a
> struct to maintain some sort of state information, but that still doesn't
> completly protect you from joe c programmer messing with the pointer...
>
> Tom Shelton

But this is a feature of strongly-typed languages with rules of scope, not OO
languages in general.

In VB.NET I can't adjust a private field because of scoping rules, which are
synchronised with (implied by?) the OO features.

BTW Note that I can use reflection to change a private value unless you've
implemented the right security too. And then there's changing the value in the
debugger... In general, encapsulation is only a methodology, most often not a
cast-iron guarentee.

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

[Tom Shelton]

"Mark Hurd" <markhurd@ozemail.com.au> wrote in message
news:3d7730c3@10.1.10.29...
> Tom Shelton <tom@mtogden.com> wrote:
> >
> > I understand what you are saying, and that is a good point. I can see
where
> > this may work as a partial solution... You could put a similar member in
a
> > struct to maintain some sort of state information, but that still
doesn't
> > completly protect you from joe c programmer messing with the pointer...
> >
> > Tom Shelton
>
> But this is a feature of strongly-typed languages with rules of scope, not
OO
> languages in general.
>
> In VB.NET I can't adjust a private field because of scoping rules, which
are
> synchronised with (implied by?) the OO features.

How? You can't access a private member outside of it's scope, and that
scope is the class. Maybe, I'm not following you here.

> BTW Note that I can use reflection to change a private value unless you've
> implemented the right security too. And then there's changing the value in
the
> debugger... In general, encapsulation is only a methodology, most often
not a
> cast-iron guarentee.

True... Even in C++ if you have a pointer to an object, you can get to it's
private members - and using reflection you can get to private data in
..NET... I see your point and agree, that it is possible to break
encapsulation in any OO language, but in general you have to specifically
try to do it. With a C style struct, you could do it by accident. Which is
where I see the use of objects as "safer".

Tom Shelton

[Mark Hurd]

Tom Shelton <toms@dakcs.com> wrote:
> "Mark Hurd" <markhurd@ozemail.com.au> wrote in message
> news:3d7730c3@10.1.10.29...
> >
> > But this is a feature of strongly-typed languages with rules of scope,
> > not OO languages in general.
> >
> > In VB.NET I can't adjust a private field because of scoping rules, which
> > are synchronised with (implied by?) the OO features.
>
> How? You can't access a private member outside of it's scope, and that
> scope is the class. Maybe, I'm not following you here.

My point is it is the scoping rules that are in play, not OO principles. Say a
freeware VB.NET was developed but they didn't implement
Public/Protected/Friend/Private -- everything was Public: It would still be
OO, just up to the programmer to honour encapsulation. That is variable access
is due to scope, not any OO "feature".

> > BTW Note that I can use reflection to change a private value unless you've
> > implemented the right security too. And then there's changing the value
> > in the debugger... In general, encapsulation is only a methodology, most
> > often not a cast-iron guarentee.
>
> True... Even in C++ if you have a pointer to an object, you can get to it's
> private members - and using reflection you can get to private data in
> .NET... I see your point and agree, that it is possible to break
> encapsulation in any OO language, but in general you have to specifically
> try to do it. With a C style struct, you could do it by accident. Which is
> where I see the use of objects as "safer".

Again, I see this as not due to objects, it is due to Private being a possible
access modifier. In C you couldn't hide (or restrict access) a struct member,
but if you rewrote the C program in VB.NET with Modules and Structures, it
could exactly duplicate the algorithm (unless pointers were used in
"interesting" ways) and reflect the wanted encapsulation.

> Tom Shelton

Hmmm.... C.NET could be the language you get when you convert VB.NET to use
{ and } and [] for arrays and drop Classes. Sounds like a good case for a
fairly straightforward translator... :-) *Lots of irony there*

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

[Kunle Odutola]

Mark Hurd wrote:
> Tom Shelton <tom@mtogden.com> wrote:
>>
>> Bill, you can not limit the accessability of a struct member in C.
>> The client programmers must have the definition of the struct, and
>> are there for able to access it's members directly. There is
>> nothing in the language to limit there access to those members.
>> Please demenstrate how you can do limit the scope of a struct member
>> using blocks?
>
> Have a look at Handles in the WinAPI. Conceptually they are double
> pointers, that is **WinStruct for some relevant Windows structure.
> However, most of them are just seen as pointers to nominal struct
> with no useful content. I think there's a C preprocessor macro called
> MAKEHANDLE in windows.h or some included file.

It doesn't limit the accessibility of the struct member. It just employs
some "code hackery" - in this case supplying alternative struct
definitions - to try and fix the problems in C. In any case, the struct
definition are *still* available if you are prepared to trawl the API header
files and look for them.

Kunle

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

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

[...]

> > > I have an open mind.

> > You have not demonstrated that so far.

> And you have?... sheese.

I was not the one claiming to have one in this thread.

> > > 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.

> My comment was not meant to imply that it was... but you knew that.

I love it when you try to play "revisionist history". It makes the
lack of merit of your original claims SO much more obvious. Let's take
a look at your comments which are under discussion. In deference to
Phil's delicate sensibilities, I will snip the quotes of my
statements and just present the relevant parts of yours.

In article <3d6c463c@10.1.10.29>, you wrote:

[...]

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

[...]

: 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.

[...]

: 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.

While we quickly disposed of your absurd little fantasies about
"forcing" changes in programming practices, we have spent the
subsequent time on your misplaced claims about "improved version" and
"a lot more safety" - BOTH of which clearly look like "arguments
concerning its objective value as a general purpose approach."

One thing that has become increasingly apparent is that you know
virtually nothing about Modular Programming. In fact, you seem unable
to distinguish MP from generic procedural programming.

Another thing that has become increasingly apparent is that you have
great difficulty separating discussion of modalities (MP, OOP, etc.
from discussion of tools you happen to associate with those
modalities.

Those two problems are making it increasingly difficult to have a
reasonable discussion of the issues. Add in your gratuitous insults
and attempts to change history, and your claim of an "open mind"
looks even more far fetched.

> You have mastered the art of arguing the irrelevant...

Not really. But you sure seem to be trying to do so.

> > > 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.

> As if that is relavant to the discussion - and please explain how
> it makes more sense to pass a struct then to call a method of a
> class.

Tell you what: I’ll give you one which also answers several of your
other attempted points. Let’s take a generic form of a very common
situation. You have a set of functions which operate on a sensitive
struct and something external (device, database, etc.). You want the
client to have access to some members of the struct, but not to
others. But the security of the not-access parts is extremely
important.

The first point to consider is whether it is absolutely vital that the
client have DIRECT access to any part of the struct - more important
than security of the other parts. If the answer is no (and it pretty
much always is), then we can go on and use the most secure and
flexible approach (used successfully for more than 3 decades,
especially in operating systems and the like) as follows:

1) Use blocking (as already discussed) to make the struct
local/private to the relevant subset of library/driver functions.

2) Define a UDT for a "public" structure containing only those parts
of the internal struct that you want the client to have access to.
If appropriate to the language, put the definition in a .h (or
equivalent) file.

3) Define any data structures you want the client to have full access
to, and add them to the appropriate file(s).

4) Create functions which accept pointers to such a public structure,
and which copy the relevant parts of the private structure to/from
those public structures in a controlled manner.

5) Compile to object form (with whatever name the language uses), and
distribute the object file, the .h (or whatever) file, and relevant
documentation.

This approach has several advantages over your beloved classes. Unlike
the classes, it totally isolates the client from implementation
changes (as long as they maintain the public interface and public
struct). Even changes to the private structure (as long as it still
includes the public parts). And since the client never gets ANY access
to the private structure, no amount of pointer manipulation will give
access to the non-public parts (unlike the "private" parts of many
classes). It also makes it convenient to implement such things as
read-only access, write-only access, range checked write, access
locking, special access rules, etc. transparently.

These (very common) modules provide a lot more safety than a class.

While there seems to be a little more overhead than your classes, that
is mostly an illusion. As much - generally more - overhead is involved
in the classes, but the languages hide much of it from view.

This is not exactly novel stuff. In fact, it is fundamental,
textbook Modular Programming.

> > > 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.

> Bill, you can not limit the accessability of a struct member in C.

Of course you can - by limiting the accessability of the entire
struct. If you are now saying that you want to SELECTIVELY limit
access to parts of the struct while allowing access to others, that
is a different issue (which is covered above).

> The client programmers must have the definition of the struct, and
> are there for able to access it's members directly.

ONLY if you are so careless - or confident - as to allow them direct
access to the struct itself. If you use the above (time proven)
approach, there is no such problem.

> There is nothing in the language to limit there access to those
> members.

There is nothing in C++ to prevent clients from using pointers to
access the so-called "private" members of a class, either. OTOH, the
common modular approach above absolutely prevents such access, short
of using an ICE or similar debugger.

> Please demenstrate how you can do
> limit the scope of a struct member using blocks?

See above.

> > > 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.

> Please demonstrate how this is possible and still have valid code.

See above.

> You must provide the definition of the struct,

ONLY if you want the client to have access to the struct. See above.

> and there is no way in C to prevent access to that's structs
> members.

There is no way in C++ to prevent access to a class‘s members,
either.

> It is completly up to the client programmer to make sure that they
> keep there mits off.

Unless you use the above approach, or something similar.

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

And realize that the client can use pointers to nullify your seeming
protections.

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

> Again that makes no sense.

Only because you are trying to shift the question. See above.

> If you are creating a libary for use by clients - then you must
> expose the functions and struct definitions -

ONLY for those functions and structs you want the client to have full
access to. There is no need whatsoever to expose definitions for any
functions or structs which are entirely internal to the library. In
fact, it would be stupid to do so.

> usually in the form of a header file and the at least the
> precompiled implementation in the form of a .o or libary file.

While the object file is necessary in either case, the header file
can be limited as above.

> > > 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.

> Again, when dealing with libaries - it is all nothing in C.

Exactly. As it should be, when safety is the primary issue.

> The only part of your code that can be protected in your libary is
> your implementation, but all of the function definitions and struct
> definitions must be provided so that the compiler can allocate the
> right amount of storage.

Again, see above. NOTHING need be provided to the client beyond the
relevant definitions for functions and/or structs you want the client
to have full access to.

> > > 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.

> First of all just changing to a get/let pair from a publicly exposed
> variable is going to disrupt client code.

Congratulations! You just invalidated your "freedom to change the
underlying implementaion" claim all by yourself. Of course, it was
already invalid, but you are learning.
BTW: this is another problem that does not exist for the modular
approach (above). It is already known that all read/write access to
the sensitive struct is via function calls (rather than the illusion
of direct data access).

> You should never expose field values directly for this very reason.

But as you are so fond of saying: nothing in the language prevents you
from doing so.

> That's why properties in VB are so cool - they give the feel of
> field access, but the implementation freedom of a method.

Again, a language issue rather than a modality issue.

> I'd also like you to tell me, what the difference is between passing
> a struct to a method in a module, compared to calling a method on a
> class.

For starters, it is completely clear that you are doing so in the
former case, but not necessarily in the latter case.

> In either case you are not privy to the implementation (unless you
> are the author of the libary) and you have no idea what other
> methods the module is going to call. And since classes are self
> contained namespaces - they do not interact with any data outside
> what they contain.

Well, that is certainly false. Unless you are trying to claim that it
is impossible to include "outside data" of ANY sort in ANY method
call, a condition clearly not enforced in any OO language. And not
practical in many cases.

[points you couldn’t refute snipped]

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

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

> how?

Look at the module described above. You just link it and use it.
That is pretty simple. As for safety, it has the advantages
described above.

> when using Delegation it is the same as referencing a module from
> another module.

Unless you are using it in an otherwise unrelated program. Unlike
the OO apologists (who are trying to redefine "reuse" in convoluted
ways), this is clean and simple reuse. "Drop and click" as the
camera people say.

> > > 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.

> You implied that they were totally different.

No, just *significantly* different. And they are.

> I was saying they are not - with a couple of exceptions.

Significant differences. Which just reinforce my point.

> > > 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.

> <StructLayout(LayoutKind.Sequential)> - aren't attributes
> beautiful... Oh, and by the way there is also a
> VBFixedArrayAttribute and VBFixedStringAttribute as well... So, in
> reality you can create a struct with the exact same layout as you
> can in VB.CLASSIC.

Yes, you can go to those lengths - sometimes. When they work. But
the point at hand is that you cannot just "create and use a UDT in
the same way as in VB.CLASSIC" as you claimed. In VB.CLASSIC, you do
not need to play those games to get that result.

> Not only that, using LayoutKind.Explicit - you can create unions
> as well.

As opposed to C, where you can do so directly with a fundamental
language feature. Aren’t language comparisons wonderful? You are
certainly fond of them.

[your admission of cluelessness snipped]

> > > 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).

> There you go with the word twisting again. You know exactly what
> I meant.

By now, I seriously doubt that you even know what you meant. The
fact remains that your little claim presupposes things that are
not yours to suppose.

> The Framework can be simply a large component library as far as
> the VB programmer is concerned.

A "large component library" that is documented SOLELY in OO terms.
Unlike the APIs and the like, which are widely documented in simple,
procedural terms. Even the controls are explained in procedural
terms, various places. That is NOT true of your "simply a large
component library" CLR.

> For the vast majority of programmers that's all it
> need be.

But to understand and use it, they need a basic understanding of
OOP concepts and the like. That is the part you keep trying to
ignore.

> If you want to do certain things like, create your own stream
> classes then yes, your going to have to understand
> inheritance - but how many VB programmers are going to create
> there own streams?

In order to do much of anything, they are going to have to be
able to understand the CLR documentation. In order to do that,
they have to understand OOP concepts - contrary to your assertion.

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

> > Far less so than VB6.

> Yes, becase VB.NET allows you to take advantage of the full
> OOP paradigm,

More to the point, REQUIRES you to make use of it for far more
things.

> where as VB.CLASSIC only exposes a limited subset.

And requires far less use of it.

> If your implying that it is because it lets you use more OOP
> constructs

I’m not. I am stating that it is because it REQUIRES the use of
OOP constructs for far more things.

[...]

> > > 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 many times does this have to be explained - Object is a complete
> replacement for Variant.

How many times does it have to be explained that it COMBINES that
characteristic with the other bit? That is rather different than
JUST being a "replacement for Variant".

> Can you give me one example of Variant usage that I can not
> duplicate using Object? Besides, Variant is the devil...

Nice try, but that kind of backwards argument doesn’t work. How
about the things OTHER than Variants that are now "Objects"? Why
do you keep trying to duck that issue?

> > > How th220 45952 <3d786453.448565@news.devx.com> article retrieved - head and body follows
From: kylix_is@yahoo.co.uk (Mike Mitchell)
Newsgroups: vb.dotnet.discussion
Subject: Re: MMFAN Retires
Date: Fri, 06 Sep 2002 08:17:59 GMT
Message-ID: <3d786453.448565@news.devx.com>
References: <3d782b47$1@10.1.10.29>
X-Newsreader: Forte Free Agent 1.21/32.243
NNTP-Posting-Host: 217.134.24.202
X-Trace: 6 Sep 2002 00:53:34 -0700, 217.134.24.202
Lines: 12
Path: 10.1.10.29
Xref: 10.1.10.29 vb.dotnet.discussion:45952

On 5 Sep 2002 21:12:55 -0700, "MMFAN" <mmf@mmf.org> wrote:

>After looking at the current state of the job market and speaking with other
>developers, I've concluded that the VB market is pretty much dead and the
>VB.Net market may never materialize.

I pretty much concur with all your points. Sorry to see you go, but
good luck in the fantasy football arena!

I shall stay around for the beer and dancing with the bridesmaids...

MM

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

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

> > > Bill, you have to publish the definitions to the client, or
> > > the code using them won't compile - that is what the purpose
> > > of a .h file.

> > Learn to read, Tom. I know that asking you to learn to think would
> > be too much too soon. If you do not want the client to "touch" the
> > structure, you do not add it to any .h file - there is no reason
> > to do so. And the whole "precompiled" thing seems to have slipped
> > by you entirely. Once again, in small steps:

> > 1) Define the "limited access" structs and variables WITHIN blocks
> > (rather than before the first block) in the source for the module
> > in question. Make sure all of the functions which access those
> > limited-access vars and structs are also within the same blocks.

> > 2) Compile the source into a .obj (or .o or whatever the local
> > dialect calls for) file.

> > 3) Prepare a .h file which ONLY contains those variables and
> > functions which you want the client to touch.

> > 4) distribute ONLY the .obj (or .o or whatever) file and the
> > limited .h file to the client.

> > The result of this is that the client has no direct access to the
> > "no access" structures and variables, and no access to the UDT
> > definitions in the module (except those deliberately added to the
> > .h file). This process prevents the client from touching those
> > structure members which you do not want them to touch. It does
> > so on the basis of the whole structure, rather than member by
> > member - safer, but less flexible.

> Bill - explain to me how this helps...

Allright. First, let's look again at your statement of the problem:

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

Now if you take the steps above, the struct members are NOT exposed
to the client programmer unless you want them to be.

> It doesn't.

Wrong!

> Sure you can implement structs and functions that can't be seen by
> the client, but you are still marginalizing the issue.

Not in the least. You are just being blindsided by some of your own
habitual assumptions.

> Look here is a simple example, say you have a simple linked list..
> You have all the functions necessary to manipulate this list - how
> do you expose it so that the client doesn't screw with your
> next pointer?

First, a design question: EXACTLY what - if anything - is it
absolutely necessary to DIRECTLY expose to the client? In most cases,
the client doesn't need to see the list struct at all. All the client
needs are functions which create/destroy the list, add, fetch, and
sometimes update and/or delete list items. All of the upkeep can be
handled outside of the client's direct influence (inside the block).
See my previous message for a more detailed description of such an
elementary module.

> YOU CAN'T.

Wrong again. It is trivial to do so. In fact, I have done so a great
many times (often with Btrees or octrees instead of simple linked
lists).

> A great many C libraries use code that looks something like this:

> typedef struct MYSTRUCT s;
> InitailizeTheStruct(&s);
> DoStuffWithThStruct(&s);
> printf("The value: %d", s.theValue);
> CleanUpTheStruct(&s);

> The reason for this is that often times there is state information
> in the struct that needs to be kept,

A good reason to use the modular approach.

> and there is no easy way to do that in the library.

Wrong yet again. You really are not doing very well.

> So tell me genious,

168, but that is irrelevant to the matter at hand.

> how do you keep joe c programmer from accessing say s.State?

By recoding the module in the way I outlined, so that J.c.p. does not
have ANY unnecessary access to ANY relevant struct.

> YOU DON'T.

WRONG YET AGAIN.

> You document it and say, don't access s.State or call it
> s.Reserved or some such nonsense.

Or you keep the client's grubby mitts off of "s" entirely, as
outlined above, and absolutely prevent such unwanted access.

> With c++ it is a
> simple matter:

> MyClass s; // we just initialized it.
> s.DoStuffWithTheClass(); // we did stuff
> cout << "The value: " << s.theValue() << endl;

And exactly HOW to you prevent joe c++ programmer from using a
pointer to bypass your illusory protection? In your own words: YOU
DON'T. Or at best, "you document it and say, don't access s.State"
or some such nonsense.

You keep making the assumption that the struct somehow "must" be
local to the client rather than to the library. That is just a habit
of yours, and has no basis in reality.

> We have less code - at least for the client,

More a language and implementation issue than one of OOP vs MP.

> and the class can keep it's own state and there is no way joe c++
> programmer can mess with your precious state.

Dangerously wrong. Ol' joe can bypass your illusory "protection" with
the simple use of a pointer. And that is why your OOP classes are so
much LESS safe than the MP modules I have been describing.

> > > The compiler has to know how much space to allocate for a
> > > struct of a type.

> > And it does - in step 2 above.

> > > I would sure like to see an example of exactly how you distribute
> > > a C code library that:

> > > 1. doesn't define functions and structs in a .h file for the
> > > client to reference.

> > Remembering that those are the structs that you were complaining
> > that you didn't WANT the client to touch. Try to stay on track,
> > Tom.

> My point is that many times you need to keep state between calls to
> your library.

Obviously. But let's not limit ourselves to "libraries" here. The
discussion is just as valid for drivers and other system resources.

> Where do you do that, hmmm?

Internally, unless the state is so trivially unimportant that you are
willing to give the client unrestricted access to it.

> Well generally it's done by storing it in the struct exposed to
> the client -

Only by poorly taught OO types. Well taught Modular Programmers know
better.

> since it would be hard to do it in the library itself -

Actually, it is trivially easy.

> probably not impossable, but difficult and probably slow.

Neither, actually. You just haven't thought it through. And it has
been common practice in drivers, OS elements, and the like for the
better part of 50 years. And it is certainly superior in terms of
safety.

> So, tell me Bill how do you prevent the client from doing
> something like:

> myStruct.State = ALL_SCREWED_UP;

As described above - by keeping the entire struct internal to the
block, and exposing only query responses. Now how do you prevent
the client from using pointers to do the same thing to YOUR
myStruct.State?

> > > 2. doesn't distribute a .o or .a file so that the compiler
> > > can link the definitions to the implementations.

> > Learn to read, Tom. I very EXPLICITLY called for distribution of
> > the object file (whatever the designation: .obj, .o, whatever).
> > Or are you just trying to blow more smoke?

> Simple misunderstanding, I see that now... It was just a
> misreading... I apologize for that.

Accepted.

--

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 *
*-----------------------*--------------------------------------------*

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

In article <3d76d2dc@10.1.10.29>,
"Mark Hurd" <markhurd@ozemail.com.au> writes:

[...]

> Have a look at Handles in the WinAPI. Conceptually they are double
> pointers, that is **WinStruct for some relevant Windows structure.

Many times - in many OSs - they are something both simpler and safer.
They are offsets into a internal table of structure pointers. With that
arrangement, you can have any number of instances of the structure,
each accessible (indirectly only) by way of its handle. When the
client calls a relevant function and passes the handle, the function
looks up (and then uses) the instance associated with the handle. The
handle itself is useless to the client, other than for such calls.
Various strategies are sometimes used to make it nontrivial for the
client to access "wrong" structures by messing with the pointer -
especially in routines subject to (effectively simultaneous) access
by multiple clients.

The overhead involved is actually quite minimal. Especially when
compared with the security benefit.


--

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 *
*-----------------------*--------------------------------------------*

[David Bayley]

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

>> Have a look at Handles in the WinAPI. Conceptually they are double
>> pointers, that is **WinStruct for some relevant Windows structure.
>
> Many times - in many OSs - they are something both simpler and safer.
> [...]

Yeah... it's called an Object. Rather than re-invent the wheel over and
over again, it was recognised as simpler and safer to move the common
abstraction of identity and encapsulation into the language.

Can we move beyond the basics and discuss Polymorphism and Inheritance.
How does MP handle these. You've raised some important dangers of
Inheritance, but haven't really gone beyond the "shoot yourself in the
foot" argument. AFAICT, you haven't addressed Polymorphism at all.
IMO, beyond the evidently obvious benefits of Identity/Encapsulation,
Polymorphism would be the next pillar of OO to address. Taking
pot-shots at Inheritance is *way* to easy, since this is a fuzzy area
even amongst OO advocates.

In another message, you hinted at one alternative whereby, in C, a
public struct could be manually copied to/from a private struct. In
terms of Encapsulation, this a poor alternative to OO. In terms of
Polymorphism, it seems like a horrendous hack.

It is these very patterns, that led to OO. Ignoring Inheritance, could
you clarify your objection to Identity, Encapsulation, and Polymorphism
(as exhibited in the "Object-Based" VB).

Could you also give some concrete examples. In my experience, it is
obvious that the Win32 API is inferior to OO APIs such as Smalltalk,
VBrun, VCL, J2SE, .NET, etc.. Perhaps the Win32 API is a poor example
of Modular Programming?

--
David

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

In article <3d792ff9@10.1.10.29>,
"David Bayley" <dbayley@spamless.aebacus.com> writes:

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

> >> Have a look at Handles in the WinAPI. Conceptually they are
> >> double pointers, that is **WinStruct for some relevant Windows
> >> structure.

> > Many times - in many OSs - they are something both simpler and
> > safer.

> > [...]

> Yeah... it's called an Object.

No. It is called a Module, and it predates Objects by decades.

> Rather than re-invent the wheel over and over again,

You have it backwards. Objects were an attempt to reinvent the MP
wheel. The structural parts of the module have been cookbook simple
for decades.

> it was recognised as simpler and safer to move the common
> abstraction of identity and encapsulation into the language.

It was neither simpler NOR safer. It WAS, however, a good way to
reuse the strengths of Modular Programming to overcome the ascendancy
(in Academic circles) of "Structural Programming" and change the
balance of Academic politics.

The common module I described to Tom earlier is both simpler and far
safer than the equivalent class. In fact, the entire modality is
both simpler and safer.

> Can we move beyond the basics and discuss Polymorphism and
> Inheritance.

No. You can play "battle of the buzzwords" all you want. But the
issue at hand is Tom's contention that "a well written class
provids a lot more saftey then a module." Spelling errors aside, he
has now acknowledged that the "safety" he cited in OOP is largely
illusory.

Polymorphism and inheritance are merely tools. They are not ends
unto themselves.

Can you even state that request without the rather circular tactic
of describing it in terms of OO concepts and constructs? Modular
Programming is as much a design modality as an implementation
modality. Rather than playing games of "how do you do OO in MP?"
(equivalent to the old "how do you do OO with Strict Structured
Programming"), the more appropriate questions would be "how would
you design and implement THIS specific program/driver/library
routine/etc. with MP? With OO? What are the relative
benefits/drawbacks of each for this project?" Of course, if you
are unable to even conceptualize the project independent of such
modality specific constructs, how can you hope to participate
meaningfully in such a discussion? Worse, how can you ever hope to
competently evaluate the issue of "the right tool" for a given
project?

> How does MP handle these.

A largely meaningless question. Those are not elements of MP design,
as discussed above. Therefore, they're not elements of MP implemented.

> You've raised some important dangers of Inheritance, but haven't
> really gone beyond the "shoot yourself in the foot" argument.

The issue was Tom's fallacy about safety. OO classes are
demonstrably less safe than MP modules. BTW, I went beyond the "shoot
yourself in the foot" argument to the far more important "head off
inappropriate Client access" argument. Tom was the one reduced to a
minute subset of the foot shot argument.

> AFAICT, you haven't addressed Polymorphism at all.

Because polymorphism has ABSOLUTELY NOTHING to do with Tom's fallacy
about safety.

> IMO, beyond the evidently obvious benefits of Identity/Encapsulation,

.... which are directly relevant to Tom's safety fallacy ...

> Polymorphism would be the next pillar of OO to address.

Why? it is irrelevant to Tom's safety fallacy. It is somewhat
relevant to Tom's "force the developer to spend more time in the
design phase of the project" fallacy, but we already disposed of
that one.

> Taking pot-shots at Inheritance is *way* to easy, since this is
> a fuzzy area even amongst OO advocates.

This is not a sporting event or a children's game. This is a
discussion of specific issues - primarily the safety difference
between an OO class and an MP module. If it is "to easy" (I assume
you mean "too easy") to use such arguments when discussing Tom's
fallacy, then it is Too Obvious that his claim IS a fallacy.

> In another message, you hinted at one alternative whereby, in
> C, a public struct could be manually copied to/from a private
> struct.

The question here is: is that an example of your above mentioned
perceptual shortcomings, or is it a deliberate distortion? Either
way, it would be pointless to try discussing the matter in terms of
that distortion of yours.

> In terms of Encapsulation, this a poor alternative to OO.

On the contrary, the ORIGINAL (as opposed to your distortion)
provides far more effective encapsulation than OO provides. Try
reading the original more carefully. Make notes. Make very sure that
you do not try to infer things that are not there. Draw a picture -
use a box for the "block".

> In terms of Polymorphism, it seems like a horrendous hack.

In terms of polymorphism, it is completely irrelevant. Polymorphism
is a conceptual element of OO design, NOT MP design. It is also FAR
more often used in OO than is necessary or wise. Take a giant step
back. Look - in purely noon, customer terms - at EXACTLY what was
supposed to be accomplished. Is it ABSOLUTELY IMPOSSIBLE to
accomplish that without the use of polymorphism? If you think the
answer is yes, try asking some other people with stronger backgrounds
in noon modalities. I seriously doubt you can find even one
legitimate endues need that REQUIRES polymorphism, unless that
"need" is defined in OO terms itself (the circular case).

> It is these very patterns, that led to OO.

No, it was Academic Politics - and the failure of Structured
Programming to meet the needs of interactive and real-time systems -
that led to OO. I watched it happen. The only reason the failure did
not simply return MP to prominence was Academic Inertia: too many
Department Chairs and other highly placed Academics (not to mention
senior Corporate types) had invested too much of their status into
trashing MP in favor of Structured Programming. Going back was
"unthinkable" - they would have had to publicly admit they were
wrong in their spirited attacks. But going forward, into something
"new" (or at least something with a new name) was a way to save face.

> Ignoring Inheritance, could you clarify your objection to Identity,
> Encapsulation, and Polymorphism (as exhibited in the "Object-Based"
> VB).

Remembering that my earlier posts were EXPLICITLY addressing Tom's
"safety" fallacy, rather than more general comparisons between MP and
OO - and most ESPECIALLY, that I was not addressing the idiotic
notion of "doing OO" in MP - most of your question is a complete non
sequitor. Particularly the part about Polymorphism. However, my
objection to "encapsulation as exhibited in the 'object-based' VB" is
that it leaks like a sieve, imposes an unconscionable amount of
unnecessary overhead, and obscures the distinction between data and
code. IMO, it doesn't qualify as encapsulation in any meaningful
way - it only plays at it. THAT is my objection.

> Could you also give some concrete examples.

Read my other posts more carefully - I already have.

> In my experience, it is obvious that the Win32 API is inferior to
> OO APIs such as Smalltalk, VBrun, VCL, J2SE, .NET, etc.. Perhaps
> the Win32 API is a poor example of Modular Programming?

The Win32 API is not any sort of an example of Modular Programming.
It was neither designed nor implemented via that modality (although
parts use some of the precepts of MP). It is a poor example of
software design and implementation in general, but a good illustration
of the problems which come from conflicting directives from upper
management (even from the same PERSON in upper management), lower
levels of management, formal documents, and informal documents - as
well as those from unrealistic schedules, unrestricted spec mutation,
and ulterior motives (some of the problems are deliberate, making the
parts of the API which are available to developers outside of M$
inferior to those available to the M$ Office group and other product
groups within M$).


--

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 *
*-----------------------*--------------------------------------------*