Re: Active X problems was Re: It's COBOL, Jim, but not as we know it...

HeyBub wrote:
Pete Dashwood wrote:

You can. If you have the source you can extend a method or property,
if you don't have the source you can suggest an improvement to the
developer. (Most developers are very pleased to hear feedback on
their components, and will do what they can to accommodate you.)

Of course this is one of the nominally swell features of Active-X,
but contraindicated in the case at hand.

I think that's just silly.

You are saying write code for every instance of everything, so it can
be available for modification, should the need arise. (The fact that
it is available for modification is not conducive to thinking a bit
more before modifying it...)

No, I'm not saying that. I'm admitting that abstraction has its place
but its place isn't EVERY place .




The function of a component is to do what it does; not do something
like what it does because you think it should. Perhaps you need to
extend it with some added functionality; fine, write another
component and use them both to achieve your aim. You don't modify
existing behaviour unless you want to reap the whirlwind.

Or, in my case, ignore the proffered component because it is
non-modifiable.

If I posted the source code you still would not use it.




(I realise this may be a foreign concept to people used to working in
COBOL...)

If you had the source of the component you would be changing it
whenever you felt there was a need to, and that would defeat the
whole object of it. You would then find other programs which used it
no longer functioned correctly and the result would be what is
accepted on most COBOL sites: maintaining code will require most of
the budget.

Oh bother! It's trivial, in a subroutine for example, to accommodate
legacy activities while using (most of) the subroutine's code for
the new or different condition.

But it reqirescomplete regression testing of everything that uses the
subroutine. You are missing the point of encapsulation.




Personally, I don't really care whether you use String2Num or not; it
was intended to demonstrate a concept. I use it and find it very
handy. I have done so for 7 years now and never maintained it, apart
from recently adding the completely new functionality to support
floating point. (So, far I'm happy to report that none of my
applications have broken because I did this...)

You added functionality to handle floating point! You took a chance on
corrupting many years worth of established results to ADD something
that could have been just as easily handled by another component?

Yes, I considered the risk and found it acceptable. (I'm pressed for time at
the moment). However, the correct approach would have been to add a new
method to the existing component or, indeed to write a new component and
invoke it when floating point was encountered. (If I didn't have the source
I would certainly have done that) Despite what you may think, I do not have
religious fervour about anything computer related and usually opt for
pragmatic solutions.


What's the strategic difference between adding space <> zero and
adding floating point conversions?

Functional divide and lines of code.

Floating point is a functionality that can reasonably be expected to be part
of what the component is designed to achieve. It will require more than one
or even a few lines of code so it should be encapsulated into another
function. The vehicle for this function could be a new component or it could
simply be a new method in the existing component. Either way, existing
encapsulation should not be violated. (I actual fact I added a new section
to an existing method, which was very wrong of me (I said as much at the
time...) I "got away with it" because the new section maintains
encapsulation and is ONLY ever activated if floating point is encountered.
This makes it very similar to a new method, but without requiring the
external and internal housekeeping that a new method would. Nevertheless,
the proper approach would have been a new method. On reflection, I might
change it to that when I have time.

Changing spaces to zeros or not is a trivial test that doesn't require
encapsulated functionality. It can be done easily, external to the
component. If I was going to modify the component toallow this, it would be
through a Boolean property that could be set or unset to allow or disallow
this check. The fact that the component currently defaults spaces to zeros
is a simply a matter of convenience for the internal code.


Why not check for floating point before invoking the component and
handling floating point stuff in a completely separate module?

That would certainly be a viable approach. However, the stated purpose of
the module is to determine whether a string can legitimately be considered
numeric or not, and floating point is a valid numeric format so it is not
unreasonable to expect the component to handle it. Besides, Robert threw it
out as a challenge and I like challenges. :-)


That
way the original component would remain unsullied and the chance of
corrupting hundreds of other modules would be zero? That you would
have to replicate 2/3rds of the original code is but a small price to
pay for integrity!

Why would I have to replicate 2/3rds fo the original? Again, you are missing
the point of encapsulation.



It isn't about ActiveX, it is about encapsulated functionality vs
bespoke programming. Mental adjustment is required to move to a
component based approach. It really is not about technology.

No, for some, it is a religious experience.

As a devout Atheist, I wouldn't know :-)


Slowly the shop floor adjusts to the new processes required by the
package. Three years later you ask them if it is any good. They can't
imagine life without it.


"Come let us gather at the river..."

Sometimes, trying to present what may be new concepts can be seen to be
evangelizing. If my comments and observations have come across that way, I
apologize. I really have no vested or other interest in people using
components. They work for me, saved me a fortune when I migrated away from
COBOL, and provide excellent ROI every day. I LIKE trusting other people's
code and not having source for it. I only have one lifetime. I cannot be all
things to all people and I cannot write every piece of functionality I am
likely to need. (Besides, others have areas of specialization and knowledge
I couldn't hope to encompass in a dozen lifetimes; I'm glad to have their
wisdom encpasulated into objects. I trust Windows every day, use some of its
components to leverage the price I paid for it, and have no source for
thesecomponents either. Do you think the one I posted as a demo is any less
useful because I don't have the source and cannot change how it works?
Neither do I have source for the various third party components I have used
for years and which are serving me well. I see encapsulation as a VERY
useful approach, I see re-use and moving away from source code maintenance
as desirable. Like most f the world, I see the future of computer
programming in encapsulated objects.

But I totally respect the right of others not to.

As you have not claimed the no-prize, I can only assume you have not tested
the component, or you couldn't make it fail.

If it is the latter, then I cannot see why you would object to something
that does what it is supposed to do, does it reliably and well, even adds
value to the basic requirement by providing alternative formats, yet you
describe it as a "terrible solution"... Because you are unable to modify it?

What's the difference between "religious fervor" and "not the way we do
things around here"? :-)

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: CoBOL moved to OO
    ... just as civil or electrical engineering ... > the supplied functions to access data fail, it can be relatively easy to ... can not only obtain the functionality I require, I can get it "in spades"... ... > true for data encapsulation, logical abstraction, or anywhere else. ...
    (comp.lang.cobol)
  • Re: Active X problems was Re: Its COBOL, Jim, but not as we know it...
    ... If you have the source you can extend a method or property, ... from recently adding the completely new functionality to support ... You added functionality to handle floating point! ... original code is but a small price to pay for integrity! ...
    (comp.lang.cobol)
  • Re: CoBOL moved to OO
    ... >>an engineering discipline, just as civil or electrical engineering ... and have a complex structured system that uses common functionality. ... > true for data encapsulation, logical abstraction, or anywhere else. ... Are you saying CBSE isn't worth it? ...
    (comp.lang.cobol)
  • New OO module idea - looking for suggestions
    ... I've been working on a module that provides encapsulation, inheritance ... Another key piece of functionality is that when a method is overridden ... perl developer to explore and perhaps even enjoy some of the features ...
    (comp.lang.perl.modules)
  • OO and change was Re: Cobol News - Microfocus and AcuCOBOL
    ... I take no responsibility for what MicroSoft do with their ... really are an OO programmer) previous methods need not to be ... That is arguably one of the fundamental reasons for encapsulation, ... Components encapsulate functionality. ...
    (comp.lang.cobol)