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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 5 FirstFirst 12345 LastLast
Results 31 to 45 of 61

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

  1. #31
    Tom Shelton Guest

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


    <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



  2. #32
    W.E. (Bill) Goodrich, PhD Guest

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

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

  3. #33
    Tom Shelton Guest

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

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



  4. #34
    Mark Hurd Guest

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

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



  5. #35
    Tom Shelton Guest

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


    "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



  6. #36
    Phil Weber Guest

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

    > So tell me genious...

    <snicker>



  7. #37
    Mark Hurd Guest

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

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




  8. #38
    Tom Shelton Guest

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


    "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



  9. #39
    Mark Hurd Guest

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

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



  10. #40
    Kunle Odutola Guest

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

    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



  11. #41
    W.E. (Bill) Goodrich, PhD Guest

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

    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

  12. #42
    W.E. (Bill) Goodrich, PhD Guest

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

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

  13. #43
    W.E. (Bill) Goodrich, PhD Guest

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

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

  14. #44
    David Bayley Guest

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

    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




  15. #45
    W.E. (Bill) Goodrich, PhD Guest

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

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center