VB 1-3 Form - "functionally challenged"


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 11 of 11

Thread: VB 1-3 Form - "functionally challenged"

  1. #1
    Rich Guest

    VB 1-3 Form - "functionally challenged"


    Bob,

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

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

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

    Rich



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

    Bob O`Bob <bob@cluestick.org> wrote:
    >Rich wrote:
    >>
    >> If it was object based, where, in the VB 1-3 IDE, could you create a class
    >> module? You could not.

    >
    >
    >Wrong. On the File menu, the choice is "New Form"
    >
    >
    >
    > Bob
    >--
    >Life makes SO much less sense when you're sane.



  2. #2
    Mike Mitchell Guest

    Re: VB 1-3 Form - "functionally challenged"

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

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


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

    MM

  3. #3
    Mark Alexander Bertenshaw Guest

    Re: VB 1-3 Form - "functionally challenged"

    Rich -

    > Again, a VB form is NOT an object in the pure sense. How can I inherit

    from
    > a VB 1-3 form? At very best it is a "functionally challenged" object. VB
    > users loosely using terms has caused VB users to be looked down on as

    hackers,
    > novices or a plethora of other unprofessional terms.


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

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

    * Encapsulation
    * Inheritance
    * Polymorphism

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

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

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

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

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


    PCers?

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


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

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



  4. #4
    Joe \Nuke Me Xemu\ Foster Guest

    Re: VB 1-3 Form - "functionally challenged"

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

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


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

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


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

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


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

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


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

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


    That's "overloading".

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


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

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



  5. #5
    Larry Linson Guest

    Re: VB 1-3 Form - "functionally challenged"


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

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


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

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


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

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


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

  6. #6
    Mark Alexander Bertenshaw Guest

    Re: VB 1-3 Form - "functionally challenged"


    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
    >"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message

    <news:3b957e6b@news.devx.com>...
    >
    >> In my course on Object Oriented concepts (and although this is ....way.....
    >> back, I still have the notes), the three concepts that were made a language
    >> object oriented are:
    >>
    >> * Encapsulation
    >> * Inheritance
    >> * Polymorphism
    >>
    >> Encapsulation is the most important concept, since it is ensures that

    a user
    >> of a component (meant in the most generic sense) cannot access its data
    >> directly. VB 1-3 did not allow this in VB code, but it did allow this

    for
    >> 3rd party components via the concept of VBX controls (which were accessed
    >> via properties, which are essentially get_ and put_ methods in disguise).

    >
    >Guess again! Modules could and did have private variables. Encapsulation
    >was around long, long before OOP, despite the best efforts of the Pure OOP
    >crowd to claim otherwise. Sure, Types are global, but that can be fixed

    by
    >passing around an index into a private array, instead of instances of the
    >Type. As for managing this array, the same "double the size" techniques
    >seen in such things as STL's vectors and Java's StringBuffer worked just

    as
    >well in VB3.


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

    >> This, and the availability of built in objects within the language is

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

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


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

    >> Inheritance is the ability to use a class that uses the features of another
    >> class without having to rewrite that original class. In a way, this is

    a
    >> kind of higher level version of the reusability of a function in an
    >> old-fashioned procedural library. Now, how you achieve this i.e. the
    >> implementation is what is usually is what people fight about. A lot of
    >> people (including you, obviously) would say that unless this feature is
    >> implemented in a language transparently, achieved by a combination of
    >> compiler and run-time jiggery pokery, then that language is not using
    >> inheritance. I would counter this and say that this view is far too
    >> implementation concerned, and in fact my classes where I used encapsulation
    >> and delegation are also using inheritance. In fact, my form of inheritance
    >> is better, since it more controllable, now I don't have to mess around

    with
    >> keywords like super *8-). Basically, languages such as smalltalk and

    java
    >> are simply hunting for methods up and down the vtables behind your back,

    and
    >> this can get very, very confusing.

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


    Indeed.

    >> So, by this token, VB4-6 implement inheritance, since you are easily able

    to
    >> reuse your implementation of a class (or form). (Don't worry, I'm not

    going
    >> to extend this definition to VB1-3 since reusing a form in another form

    is
    >> only relevant in an MDI situation).

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


    What was this?

    >> Finally, Polymorphism. This is generally the idea that an objects will

    be
    >> able react differently to the same method, depending on the context in

    which
    >> it is sent. There are two forms in which this normally takes. The version
    >> which is used even in non-OO languages such as Ada is the ability to have

    a
    >> number of methods, with the same method name, but with different parameters
    >> distinguishing them. C++, and I think, Java use this mechanism. A more

    >
    >That's "overloading".


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

    >> recent extension of the same concept is the idea of interfaces which can

    be
    >> implemented by a class with the intention to allow a class to be used

    _as_
    >> another class. Java does this, and so does VB 5 and 6 - admittedly only
    >> because it relies on COM.

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


    True ... but a bit crude.


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


  7. #7
    Bob Guest

    Re: VB 1-3 Form - "functionally challenged"


    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
    news:3b95fffc$1@news.devx.com...
    >
    > "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
    > >"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message

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

    >
    > What was this?
    >


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

    Bob




  8. #8
    Mike Mitchell Guest

    Re: VB 1-3 Form - "functionally challenged"

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

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


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

    MM

  9. #9
    Joe \Nuke Me Xemu\ Foster Guest

    Re: VB 1-3 Form - "functionally challenged"

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

    > "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
    > news:3b95fffc$1@news.devx.com...
    > >
    > > "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
    > > >"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message

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

    > >
    > > What was this?
    > >

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


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

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



  10. #10
    Bob Guest

    Re: VB 1-3 Form - "functionally challenged"


    "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
    news:3b97a7ab@news.devx.com...
    > "Bob" <tooslow42@yahoo.com> wrote in message

    <news:3b96400e$1@news.devx.com>...
    >
    > > "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in

    message
    > > news:3b95fffc$1@news.devx.com...
    > > >
    > > > "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
    > > > >"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in

    message
    > > <snip>
    > > > >VB4 lacked Implements. It didn't lack, however, an add-in providing
    > > > >implementation inheritance. Sure, it was a kludge, but it got the

    job
    > > > >done by quittin' time.
    > > >
    > > > What was this?
    > > >

    > >
    > > There was a 3rd party product that scanned VB code looking for special
    > > comments and generating VB code that attempted to simulate

    implementation
    > > inheritance. I had the misfortune of being forced to use this product on

    a
    > > large project and it truly was a case of the cure being worse than the
    > > disease.

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

    <http://www.xenu.net/>

    Joe,

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

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

    Bob



  11. #11
    Mark Alexander Bertenshaw Guest

    Re: VB 1-3 Form - "functionally challenged"


    "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    news:3b96367e.13848026@news.devx.com...
    > On Wed, 5 Sep 2001 02:29:26 +0100, "Mark Alexander Bertenshaw"
    > <mark.bertenshaw@virgin.net> wrote:
    >
    > >Have a look around the vb.oop newsgroup, and tell me that the guys there

    are
    > >hackers, novices, and unprofessional. Whilst in many cases I believe

    there
    > >_are_ people like Mike Mitchell who seem to have violent (and silly)
    > >reactions to OOP, I know a lot of VB programmers who are completely clued
    > >up, and know how to engineer software using OO methodologies.

    >
    > Where is the evidence that business applications are "better" when
    > written the pure OOP way compared with the traditional procedural way?


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

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

    the traditional procedural way?

    > How do you explain the fact that 70% of applications written in Visual

    Basic do not employ objects derived from classes the authors have written?

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

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


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

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


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

    >
    > MM


    Regards,

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



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