Did I write a good (efficient) program?

On Wed, 2 Apr 2008 10:07:54 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>OO Code has a different set...
>
>1.  Does it work?
>2.  Is it small and complete (encapsulated)?
>3.  Can I reuse and extend it easily?
>
>Efficiency is taken care of by keeping components small, and using
>optimizing compilers.
>
>Maintainability is not a consideration as long as the interface is simple o
r
>non existent.

Except those characteristics are essential for good maintainability.
The application needs to be maintainable.  The system needs to be
maintainable.    The component size is different and techniques for
making the code maintainable have changed.

But the goal is the same.

On Tue, 01 Apr 2008 23:21:29 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>news:65folmF1f605pU1@mid.individual.net... 
>
>Applications programmers (eg, moi) don't think in terms of "components";
>strangely enough, we think in terms of "applications."
>
>I guess that explains as well as anything why it is 'systems' programmers
>are the ones who just couldn't cut it in applications.
>
>MCM
>
>
>

What make you think systems progrmmers can't cut it in application? In
the beginning of my career I pulled double duty as a systems and
applications programmer.  Never had a problem with either.

Regards,
////
(o o)
-oOO--(_)--OOo-

"Save the whales. Collect the whole set."
-- Steven Wright
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

"SkippyPB" <swiegand@nospam.neo.rr.com> wrote in message
 news:7oa7v3t4asvik0cnrlsk5j8k4o7g4jkodt@
4ax.com...> > What make you think
systems progrmmers can't cut it in application? In
> the beginning of my career I pulled double duty as a systems and
> applications programmer.  Never had a problem with either.

I was afraid of this. I was too subtle in my saracasm.

Well, at least the *applications* programmers "get it."

MCM

The problems with using the "max" rather than the "current" size occurs when
referencing the entire group item and moving it, for example, to a single
receiving item.  Having "undefined/garbage" data in the "unused" portion of 
the
max part will cause problems.  The GROUP item doesn't know (need to know) ho
w
the individual sub-items are defined.

Is this clear?  If not, I can try doing an example.

***

As far as you example goes, when passing an indirect  variable length item o
r a
group containing one, what will be past is a pointer.  If the called program
 is
in another language, then you would define the structure with a pointer as w
hat
was received and need to process it "accordingly".  If the subprogram did
something that COBOL couldn't handle when it came back, then various "except
ion
conditions" might be raised.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
 news:tce6v3hriqrje7kcom4petuon9rp0a84bl@
4ax.com...
> On Wed, 02 Apr 2008 05:41:02 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
> 
>
> The next paragraph seems to confirm that, when it qualifies any-length wit
h
> indirect. The
> implication is that a change to a direct any-length item DOES affect the
> addresses of its
> neighbors.
>
> "The physical address of a variable-length data item may change during
> execution of the
> program. Dynamic-capacity tables and indirect any-length elementary items,
> however they
> may change during execution, do not in any way affect the addresses of the
ir
> neighbors."
>
> What procedural operations are they referring to? A MOVE and comparison wo
uld
> work if the
> maximum length were allocated and following items not shifted. I can think
 of
> two
> situations where it matters. FUNCTION LENGTH says nothing about
> variable-length groups,
> which seems like an error.  Reference modification cannot be used on
> variable-length
> groups.
>
> How can a program tell whether the item following an any-length elementary
> item is
> contiguous? What behavior would be different?
>
> Suppose program A calls B with the address of an indirect any-length item 
or
> variable-length group containing a direct any-length item. B changes the
> item's size and
> address. How does A know the new address? The parameter passed was the add
ress
> of the item
> or group, not the address of its base pointer. If a Cobol program did pass
 the
> addess of
> the base pointer, which it would almost have to, that would cause problems
 for
> other
> languages, including the OS API.

"Howard Brazee" <howard@brazee.net> wrote in message
 news:rp37v3pcskcjhk6ui9ack5lus9tcipff8k@
4ax.com...
> On Wed, 2 Apr 2008 10:07:54 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
> 
>
> Except those characteristics are essential for good maintainability.
> The application needs to be maintainable.  The system needs to be
> maintainable.    The component size is different and techniques for
> making the code maintainable have changed.
>
> But the goal is the same.

Yes, of course. However, the WAY in which the goals are met is very
different. "Self-documenting" code is irrelevant. It only matters if code is
to be constantly changed. If the code NEVER changes, then it doesn't matter.
That was my point.

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

On Wed, 02 Apr 2008 21:37:18 GMT, "William M. Klein" <wmklein@nospam.netcom.
com> wrote:

>The problems with using the "max" rather than the "current" size occurs whe
n
>referencing the entire group item and moving it, for example, to a single
>receiving item.  Having "undefined/garbage" data in the "unused" portion of
 the
>max part will cause problems.  The GROUP item doesn't know (need to know) h
ow
>the individual sub-items are defined.

I think a group move DOES need to handle any-length items separately. 8.5.1.
9 says:

"Unlike other group items, a variable-length group is not equivalent to an a
lphanumeric
data item and cannot undergo a comparison or a move operation, in either dir
ection,
explicitly or otherwise, unless the other operand is a compatible group. Gro
ups are
compatible if all variable-length data items correspond and match as specifi
ed
below. For the purposes of compatibility, either both operands may be variab
le-length
groups or only one of the operands may be a variable-length group.

Determination of compatibility between a variable-length group and another g
roup is as
follows:
3) For each any-length elementary item in either group there is a correspond
ing any-length
elementary item in the other group as specified in 8.5.1.9.1, Positional cor
respondence."


You say, above, a variable length group can be moved to a single receiving i
tem. The last
sentence of the first paragraph says the same. But the first sentence and 3)
 appear to
require they both be variable-length groups with corresponding any-length it
ems.

It is easy picture a move from a variable-length group to a fixed-length ite
m, such as a
file record. It is not as easy to picture the reverse. Say it's moving bytes
 until it gets
to an any-length string defined as prefixed by binary-long. The input doesn'
t contain a
binary-long. How does it determine the length of the string?

Getting back to a move between two variable-length groups,
there is no requirement that the corresponding any-length items match on
direct/indirect
prefixed/delimited
limit

On a group move, the sending group might contain a direct item (with limit) 
while the
corresponding item in the receiving group is indirect. The sending item migh
t be delimited
by low-value while the receiving group is prefixed by binary-long.

For these reasons, it seems a grouip move would have to be three operations
copy the bytes preceding the any-length item
copy the any-length item, which may require scanning for a delimiter
or allocating memory
copy the bytes following the any-length item

>Is this clear?  If not, I can try doing an example.

I would appreciate an example that deals with the above points.

>  ***
>
>As far as your example goes, when passing an indirect  variable length item
 or a
>group containing one, what will be passed is a pointer.  If the called prog
ram is
>in another language, then you would define the structure with a pointer as 
what
>was received and need to process it "accordingly".  If the subprogram did
>something that COBOL couldn't handle when it came back, then various "excep
tion
>conditions" might be raised.

I found the answer under CALL. Any-length items and variable-length groups a
re NOT ALLOWED
to be passed as parameters, period. That avoids dealing with the issue of si
ze changing in
the called program.

The returning item is not allowed to be an any-length item, but can be a var
iable-length
group containing an any-length item. This is not a mistake, it shows that so
meone on the
standards committee understands the issues I asked about. If the returning w
ere an
any-length elementary item, the called program would have no way to communic
ate its new
location after a size change. But when the returning item is a group, the gr
oup contains
pointers to its variable-length elements, enabling the called program to pas
s back their
new locations.



>
>--
>Bill Klein
> wmklein <at> ix.netcom.com
>"Robert" <no@e.mail> wrote in message
> news:tce6v3hriqrje7kcom4petuon9rp0a84bl@
4ax.com... 
>

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:65fmhdF2fbsenU1@mid.individual.net...
[snip]
> To modify existing functionality does NOT mean modifying a base class. It
> means extending (through inheritance) or over-riding existing behaviours.

The priniples of object-oriented design do not include
the use of inheritance to overcome inadequate or faulty
design. In such cases, modifying a base class may be
unavoidable.

"Rick Smith" <ricksmith@mfi.net> wrote in message
 news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d@mi
d-floridainternet...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:65fmhdF2fbsenU1@mid.individual.net...
> [snip] 
>
> The priniples of object-oriented design do not include
> the use of inheritance to overcome inadequate or faulty
> design. In such cases, modifying a base class may be
> unavoidable.

I have never encountered such a situation and do not expect to. (Guess my
designs are not "inadequate" or "faulty"...:-))

I really don't care about academic "principles of OO design" unless they are
pertinent to the world in which I live and work; your statement above is
not.

My own principles (derived from over a decade of real world use) tell me not
to modify a Base Class.

So I don't.

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