Cobol - invoking a method

Author

invoking a method

Frank Swarbrick

2006-12-02, 6:55 pm

Looking at examples supplied with MF Net Express reminded me of
something that seems odd to me about all OO languages I've looked in to.
They pretty much all invoke methods in a somewhat similar format in
that the object comes first, followed by the name of the method,
followed by any parameters.

COBOL 2002
invoke object "method" using by value parm1, parm2
MF COBOL
invoke object::"method"(parm1, parm2)
Java
object.method(parm1, parm2)
Objective-C
[object method:parm1 parm2name:parm2]
Ruby
object.method parm1, parm2

One thing that I've come to believe is that it would often be more
"natural" (for me) if the method name was specified first. The method
is very often a verb. So why not something like:
insert employee into list

where 'insert' is the method name, 'employee' is the object to be
inserted (the parameter) and 'list' is the object that is to receive the
message. 'into' is just a noise word to make it more readable.

What follows below is code from one of the MF ISO2002 examples, along
with modified versions in other languages. The last "language" is just
something I've been toying with. Right now it's a 2000+ line text
document of my thoughts on an 'ideal' (hah!) programming language.
Probably that's all it will ever be. But still, it keeps me off the
streets.

COBOL 2002:
working-storage section.
01 displayList usage object reference DLinkList.
procedure division.
set displayList to DLinkList::"new"
invoke displayList "add" using by value emp1
invoke displayList "add" using by value car1
invoke displayList "add" using by value indPlace1
invoke displayList "add" using by value car2
move listSize of displayList to noItems
if noItems > 0
invoke displayList "getfirst" returning displayItem
invoke displayItem "display"
perform until exit
set displayItem to displayList::"getnext"
if displayItem not = null
invoke displayItem "display"
else
exit perform
end-if
end-perform
end-if
exit program.

Micro Focus COBOL:
working-storage section.
01 displayList DLinkList.
procedure division.
set displayList to DLinkList::"new"
invoke displayList::"add"(emp1)
invoke displayList::"add"(car1)
invoke displayList::"add"(indPlace1)
invoke displayList::"add"(car2)
move displayList::"listSize" to noItems
if noItems > 0
set displayItem to displayList::"getfirst"
invoke displayItem::"display"
perform until exit
set displayItem to displayList::"getnext"
if displayItem not = null
invoke displayItem::"display"
else
exit perform
end-if
end-perform
end-if
exit program.

Java:
{
DLinkList displayList;

displayList = new DLinkList();
displayList.add(emp1);
displayList.add(car1);
displayList.add(indPlace1);
displayList.add(car2);
noItems = displayList.listSize();
if (noItems > 0) {
displayItem = displayList.getfirst();
displayItem.display();
while () {
displayItem = displayList.getnext();
if (displayItem != NULL)
displayItem.display();
else
break;
}
}
}

Objective-C:
{
DLinkList *displayList;

displayList = [[DLinkList alloc] init];
[displayList add:emp1];
[displayList add:car1];
[displayList add:indPlace1];
[displayList add:car2];
noItems = [displayList listSize];
if (noItems > 0) {
displayItem = [displayList getfirst];
[displayItem display];
while () {
displayItem = [displayList getnext];
if (displayItem != NULL)
[displayItem display];
else
break;
}
}
}

Ruby:
begin
displayList = DLinkList.new
displayList.add emp1
displayList.add car1
displayList.add indPlace1
displayList.add car2
noItems = displayList.listSize
if noItems > 0
displayItem = displayList.getFirst
displayItem.display
while true
displayItem = displayList.getnext
if displayItem
displayItem.display
else
break
end
end
end
end

"Frank's programming language":
begin
displayList := new DLinkList$
[add emp1 to displayList]
[add car1 to displayList]
[add indPlace1 to displayList]
[add car2 to displayList]
noItems := displayList.listSize #(listSize is a property)#
test noItems
when gt 0
displayItem := [getfirst displayList]
[display displayItem];
loop until exit
displayItem = [getnext displayList]
test displayItem
when true
[display displayItem]
when false
exit
end
end
end
end

Like Objective-C, I've wrapped brackets around the object invocation.
To me it makes it a bit more readable, plus it would probably making
source code parsing simpler. If the method is simply a "property" (or
"attribute", depending on your language preference) it would be:
object.property
I suppose you could also have
[property of object]
but I prefer the former. Plus, while I can see
object1.property := object2.property
I can't really picture:
[property of object] := [property of object]
Well, I can, but again I prefer the former.
A regular (non-OO) "function call" would probably just be:
func(parm1, parm2)

Comments and constructive criticism welcomed. Ignoring my nonsense is
perfectly fine. Comments like "don't you have better things to do with
your time then create yet another programming language" will be ignored.
I have no illusions of this "language" going anywhere beyond this
text document. :-)

Frank

P. Raulerson

2006-12-02, 6:55 pm

You should look into Smalltalk- right up your alley. Of course, it drives
those of us who are indoctrinated with procedural languages right crazy...

I did not know that the MF had a new "University Edition" out, the last one
I knew of was version 3.0. Wayyy behind the times. This one may be a little
old as well, which is why you are picking up errors. The University edition
is a way that MF can make a bit of cash off older - basically
non-supported - versions of the product.

-Paul

"Frank Swarbrick" <infocat@earthlink.net> wrote in message
news:50lch.5827$ql2.1611@newsread3.news.pas.earthlink.net...
> Looking at examples supplied with MF Net Express reminded me of something
> that seems odd to me about all OO languages I've looked in to. They pretty
> much all invoke methods in a somewhat similar format in that the object
> comes first, followed by the name of the method, followed by any
> parameters.
>
> COBOL 2002
> invoke object "method" using by value parm1, parm2
> MF COBOL
> invoke object::"method"(parm1, parm2)
> Java
> object.method(parm1, parm2)
> Objective-C
> [object method:parm1 parm2name:parm2]
> Ruby
> object.method parm1, parm2
>
> One thing that I've come to believe is that it would often be more
> "natural" (for me) if the method name was specified first. The method is
> very often a verb. So why not something like:
> insert employee into list
>
> where 'insert' is the method name, 'employee' is the object to be inserted
> (the parameter) and 'list' is the object that is to receive the message.
> 'into' is just a noise word to make it more readable.
>
> What follows below is code from one of the MF ISO2002 examples, along with
> modified versions in other languages. The last "language" is just
> something I've been toying with. Right now it's a 2000+ line text
> document of my thoughts on an 'ideal' (hah!) programming language.
> Probably that's all it will ever be. But still, it keeps me off the
> streets.
>
> COBOL 2002:
> working-storage section.
> 01 displayList usage object reference DLinkList.
> procedure division.
> set displayList to DLinkList::"new"
> invoke displayList "add" using by value emp1
> invoke displayList "add" using by value car1
> invoke displayList "add" using by value indPlace1
> invoke displayList "add" using by value car2
> move listSize of displayList to noItems
> if noItems > 0
> invoke displayList "getfirst" returning displayItem
> invoke displayItem "display"
> perform until exit
> set displayItem to displayList::"getnext"
> if displayItem not = null
> invoke displayItem "display"
> else
> exit perform
> end-if
> end-perform
> end-if
> exit program.
>
> Micro Focus COBOL:
> working-storage section.
> 01 displayList DLinkList.
> procedure division.
> set displayList to DLinkList::"new"
> invoke displayList::"add"(emp1)
> invoke displayList::"add"(car1)
> invoke displayList::"add"(indPlace1)
> invoke displayList::"add"(car2)
> move displayList::"listSize" to noItems
> if noItems > 0
> set displayItem to displayList::"getfirst"
> invoke displayItem::"display"
> perform until exit
> set displayItem to displayList::"getnext"
> if displayItem not = null
> invoke displayItem::"display"
> else
> exit perform
> end-if
> end-perform
> end-if
> exit program.
>
> Java:
> {
> DLinkList displayList;
>
> displayList = new DLinkList();
> displayList.add(emp1);
> displayList.add(car1);
> displayList.add(indPlace1);
> displayList.add(car2);
> noItems = displayList.listSize();
> if (noItems > 0) {
> displayItem = displayList.getfirst();
> displayItem.display();
> while () {
> displayItem = displayList.getnext();
> if (displayItem != NULL)
> displayItem.display();
> else
> break;
> }
> }
> }
>
> Objective-C:
> {
> DLinkList *displayList;
>
> displayList = [[DLinkList alloc] init];
> [displayList add:emp1];
> [displayList add:car1];
> [displayList add:indPlace1];
> [displayList add:car2];
> noItems = [displayList listSize];
> if (noItems > 0) {
> displayItem = [displayList getfirst];
> [displayItem display];
> while () {
> displayItem = [displayList getnext];
> if (displayItem != NULL)
> [displayItem display];
> else
> break;
> }
> }
> }
>
> Ruby:
> begin
> displayList = DLinkList.new
> displayList.add emp1
> displayList.add car1
> displayList.add indPlace1
> displayList.add car2
> noItems = displayList.listSize
> if noItems > 0
> displayItem = displayList.getFirst
> displayItem.display
> while true
> displayItem = displayList.getnext
> if displayItem
> displayItem.display
> else
> break
> end
> end
> end
> end
>
> "Frank's programming language":
> begin
> displayList := new DLinkList$
> [add emp1 to displayList]
> [add car1 to displayList]
> [add indPlace1 to displayList]
> [add car2 to displayList]
> noItems := displayList.listSize #(listSize is a property)#
> test noItems
> when gt 0
> displayItem := [getfirst displayList]
> [display displayItem];
> loop until exit
> displayItem = [getnext displayList]
> test displayItem
> when true
> [display displayItem]
> when false
> exit
> end
> end
> end
> end
>
> Like Objective-C, I've wrapped brackets around the object invocation. To
> me it makes it a bit more readable, plus it would probably making source
> code parsing simpler. If the method is simply a "property" (or
> "attribute", depending on your language preference) it would be:
> object.property
> I suppose you could also have
> [property of object]
> but I prefer the former. Plus, while I can see
> object1.property := object2.property
> I can't really picture:
> [property of object] := [property of object]
> Well, I can, but again I prefer the former.
> A regular (non-OO) "function call" would probably just be:
> func(parm1, parm2)
>
> Comments and constructive criticism welcomed. Ignoring my nonsense is
> perfectly fine. Comments like "don't you have better things to do with
> your time then create yet another programming language" will be ignored. I
> have no illusions of this "language" going anywhere beyond this text
> document. :-)
>
> Frank

Donald Tees

2006-12-02, 6:55 pm

Paul Robinson

2006-12-03, 3:55 am

Frank Swarbrick wrote (edited):

> about all OO languages ... pretty much all invoke methods
> in a somewhat similar format that the object comes first,
> followed by the name of the method, followed by any parameters.

> COBOL 2002: invoke object "method" using by value parm1, parm2
> MF COBOL: invoke object::"method"(parm1, parm2)
> Java: object.method(parm1, parm2)
> Objective-C: [object method:parm1 parm2name:parm2]
> Ruby: object.method parm1, parm2
>
> I've come to believe it would be more "natural" if the method
> name was specified first. The method is very often a
> verb. So why not something like:
> insert employee into list
>
> where 'insert' is the method name, 'employee' is the object to be
> inserted (the parameter) and 'list' is the object that is to receive the
> message. 'into' is just a noise word to make it more readable.

Okay, having actually done maintenance on compilers including written
more than one, I'll state why I don't think your idea will work, at
least, not in the context of Cobol.

Now, I will admit I have not worked on anyone else's Cobol compiler so I
don't know how they work, I will offer some thoughts on the subject
based on how I suspect they work. I may be wrong on this point but
considering the way Cobol reference manuals show Cobol syntax, I have a
reasonable belief that this would be the way it would be done.

Presumably the parser for a Cobol Compiler is going to presume some
fixed syntax, i.e. a specific DIVISION having certain contexts. In
fact, the typical reference manual for a Cobol Compiler will have line
and box based syntax diagrams showing exactly what particular symbols
are permissible at a particular point, e.g. in the DATA DIVISION, if
there is a two-digit number, it is expected to be followed by either a
data name, blank or FILLER, followed by PIC or PICTURE or some other terms.

Now, in order to allow something like this, you would have to have some
way to allow a Cobol parser to identify that this is a method (or
function) call.

If we enter the PROCEDURE DIVISION, typically what you have are a series
of sentences in which the first word, which is a "verb", dictates what
the sentence means, i.e. what action is to take place. That particular
verb has certain permitted parameters and options.

Actually, you could do something like this if you had a provision that
referencing an identifier is conditionally a method call. Of course,
this also causes a problem if the method name or object name are the
same as or similar to a Cobol keyword. But the high probability is that
it would be an extreme effort to be able to implement such a thing,
since I suspect that Cobol compilers tend to be keyword driven, thus
allowing them to implement the "implicit call" function (where reference
to a procedure or function implicitly calls that function without use
of, say, a CALL (or PERFORM in Cobol) would require potentially a
significant rewrite or even a reengineering of the parsing routines of
the compiler.

Languages that implement "implicit call" can do this because they have
provision for referencing an identifier as either an assignment (if the
symbol following the identifier is the assignment symbol), or a
procedure call if the identifier is a procedure / function, or is
followed by a parameter list.

C, Pascal and Visual Basic all support "implicit call." Some languages,
it would be very difficult to implement.

In Fortran, for example, you have something like

DO 5 I = 1, 10
or
DO 5 I = 1.10

The first is a loop construct, the second is an assignment. Fortran
does not depend on spaces, does not have reserved words, and has few
restrictions on how you form an identifier, so until it sees the "." or
the "," it can't tell that the statement is an assignment or is a loop.
In fact, while technically it is legal syntax, most people who write
Fortran would consider the second example to be incorrect.

So in Fortran, you can't even use spaces or delimiters to determine
whether some reference is a variable or an imperative statement until
much further along in the line. Thus implementing an "implicit call"
would be very difficult if it was even possible.

Now, Cobol has a number of advantages including imperative command-based
statements. This makes writing a compiler easier, at the expense of
making the language to be compiled more rigid. Which is exactly the
state of Cobol programs.

Now, it is conceivable to allow such a construct if some way can be
found to allow a method reference to be used such that some keyword in
the stream allows the program to be aware that this is what is being done.

Actually, this might not be a bad idea, and it sounds interesting,
although I don't know if it can be implemented in a reasonable fashion
giving the method I suspect most Cobol compilers are implemented.

Pete Dashwood

2006-12-03, 6:55 pm

"Paul Robinson" <paul@paul-robinson.us> wrote in message
news:6bidnRNZEcyKzu_YnZ2dnUVZ_tSdnZ2d@ca
vtel.net...
> Frank Swarbrick wrote (edited):
>
>

This is a logical top down progression which may seem strange at first, but
becomes clear when you realise that everything is relating to an Object.

OBJECTS have METHODS, PROPERTIES, and EVENTS.

OBJECT METHODS may have parameters. (Personally, I avoid this as much as
possible and use GET and SET Methods to set object properties, rather than
passing parameters at invocation time. The reasons for this are too complex
to go into here in the time I am prepared to spend on it... One benefit is
that the interface to method invocation doesn't change; you simply invoke
the method, having already "passed" the parameters.)
[color=darkred]

I would find that completely UNnatural... It is indeed a diverse world we
inhabit :-)

The method is very often a[color=darkred]

No, parameters are NOT objects; they are properties. In your example, "list"
is the object...

For me that would be

invoke list
"SET-employee" using ws-employee
end-invoke

(The SET method of the list object is implicit if it is a COM object (and
those are the ones I mainly deal with...) If it isn't, then you would need
to write (or generate) your own GET and SET methods) The Fujitsu COM
interface Class provides these methods and saves you the trouble of having
to wrap your .dll with the layers and interfaces you would otherwise need.
The use of SET as shown here, will not work outside the Fujitsu Object COBOL
environment (You could simulate it very easily though).

It's not a good example, because SET actually sets the property, which is
the same as "inserting" it... Any INSERT Method, presumably has something to
be inserted, so there will usually be further information required.

Something that might use an INSERT method could be a database object
(Collections use ADD)

invoke DBObject
"SET-DBDataLocation" using ws-structure-ptr
end-invoke
invoke DBObject
"insert" *> Note no parameters to INSERT method...
returning ws-DBStatus
end-invoke

Here, the location of the structure to be inserted is set before invoking
the INSERT method. The effect is exactly the same as if it had been passed
as a parameter, and you might wonder why I chose not to address the Object
once, and simply pass it parameters.

Here's the rationale, in my own words, as best I can explain it quickly and
succinctly (there is much more here than meets the eye), so,
over-simplified...

GENERAL:

1. Object methods allow objects to behave in various ways. Methods are about
"behaviour".

2. Object properties are the public data attributes of an object.
Properties are about influencing and controlling behaviour, and are
influenced and controlled by behaviours.

3. Because they are PUBLIC, properties can be easily used to affect
behaviour, BEFORE the behaviour is initiated (SET). They can also be viewed
AFTER the behaviour has completed, to see what happened (GET).

SPECIFIC (to the example above):

1. The insert may need a different number of parameters if you decide to
extend it's functionality.

(Suppose we decide to add BLOBs (Binary Large Objects... say, images) to the
database and need to add a signature to each one immediately before writing
it, after virus checking it. Now there is a specific behaviour required for
BLOBs, but it only marginally deviates from the standard INSERT processing.
A new Method ("BLOBBY") is added to the DBObject Class as a private method
that will be activated before the INSERT method if a certain property is
set. BLOBBY will calculate and check the signature and ensure it is inserted
in the data structure. The INSERT method will not be touched; it will insert
the structure just as always.

invoke DBObject
"SET-DBDataLocation" using ws-structure-ptr
end-invoke

if its-a-blob
invoke DBObject
"SET-DBBLOBFlag" using by value TRUE
end-invoke
end-if

invoke DBObject
"insert" *> Note no parameters to INSERT method...
returning ws-DBStatus
end-invoke

Only new programs that are required to deal with BLOBs need the new code.
Maybe BLOBs can only be added to one specific database, in one specific
system... there are any number of possibilities. The point is that any code
in any system which is using the INSERT method, and does NOT require BLOB
functionality, continues to function as it always has. It requires neither
change nor regression testing.)

2. If you use a parameter list, and one or more of the items in the list
changes, due to extended functionality or overrides in the future, you must
REGRESSION TEST EVERY single program that uses the INSERT method.

3. Linking specific parameters to specific methods does not encouirage
method generalisation. Seeing fundamental behaviour as modifiable through
properties, is a good way to avoid maintaining (changing and modifying what
methods do) code. If functionality needs extending; extend the behaviours of
the Class. Don't change existing behaviour that is working and proven. If
the basic behaviour needs changing, you didn't design it properly, or things
have changed so dramatically that it is no longer relevant. Either way, it's
time to design and write it again.

Using the approach above, existing programs do not have their behavioural
interfaces changed, the INSERT method remains encapsulated, and you only
need to test the programs that use the new functionality.

[color=darkred]
>
> Okay, having actually done maintenance on compilers including written more
> than one, I'll state why I don't think your idea will work, at least, not
> in the context of Cobol.

Having had similar experience, I'll be interested in your comments :-)
>
> Now, I will admit I have not worked on anyone else's Cobol compiler so I
> don't know how they work, I will offer some thoughts on the subject based
> on how I suspect they work. I may be wrong on this point but considering
> the way Cobol reference manuals show Cobol syntax, I have a reasonable
> belief that this would be the way it would be done.

Yes, that would be a fair assumption.

However, personally, I wouldn't make it :-)

There are so many good compilers that I believe it is risky to assume how
they work.

Some people love doing the unexpected... :-)

The best compiler I ever worked on used transition diagramming for the
parsing and was blazingly fast. Rather than looking at and unstringing
words, every character of source was processed through predicted states. If
the "interesting" states didn't eventuate the source was flushed to the next
white space.

Nodes were built for the procedure division and referenced back to data
names previously stored with attached attributes in shorthand.

Subsequent passes checked that COBOL rules were enforced.

It was blinding and brilliant... and it was written in 1968, before computer
science screwed the world up :-)

It had 14 passes in total and I disassembled it so we could patch it to take
tape input (it was designed to read cards only), and to get it to write its
output to a fixed disk where we could offload it to tape (rather than
punching Object decks which tended to be a bit "fragile". It had been
written by a single person, on contract to a major manufacturer. Said person
had fallen out with them and there was no support for it from said
manufacturer... :-)

I spent nearly 6 months anaysing and modifying this code, and I learned
much. There are products being written today by people with Masters degrees,
which are not worthy to even act as bootstraps for this compiler... :-)

The discussion below is good and fair, but there are possibilities it
doesn't consider. Some of the difficulties only arise if you assume certain
approaches; a different approach means they aren't problematic.
>
> Presumably the parser for a Cobol Compiler is going to presume some fixed
> syntax, i.e. a specific DIVISION having certain contexts. In fact, the
> typical reference manual for a Cobol Compiler will have line and box based
> syntax diagrams showing exactly what particular symbols are permissible at
> a particular point, e.g. in the DATA DIVISION, if there is a two-digit
> number, it is expected to be followed by either a data name, blank or
> FILLER, followed by PIC or PICTURE or some other terms.
>
> Now, in order to allow something like this, you would have to have some
> way to allow a Cobol parser to identify that this is a method (or
> function) call.
>
> If we enter the PROCEDURE DIVISION, typically what you have are a series
> of sentences in which the first word, which is a "verb", dictates what the
> sentence means, i.e. what action is to take place. That particular verb
> has certain permitted parameters and options.
>
> Actually, you could do something like this if you had a provision that
> referencing an identifier is conditionally a method call. Of course, this
> also causes a problem if the method name or object name are the same as or
> similar to a Cobol keyword. But the high probability is that it would be
> an extreme effort to be able to implement such a thing, since I suspect
> that Cobol compilers tend to be keyword driven, thus allowing them to
> implement the "implicit call" function (where reference to a procedure or
> function implicitly calls that function without use of, say, a CALL (or
> PERFORM in Cobol) would require potentially a significant rewrite or even
> a reengineering of the parsing routines of the compiler.
>
> Languages that implement "implicit call" can do this because they have
> provision for referencing an identifier as either an assignment (if the
> symbol following the identifier is the assignment symbol), or a procedure
> call if the identifier is a procedure / function, or is followed by a
> parameter list.
>
> C, Pascal and Visual Basic all support "implicit call." Some languages,
> it would be very difficult to implement.
>
> In Fortran, for example, you have something like
>
> DO 5 I = 1, 10
> or
> DO 5 I = 1.10
>
> The first is a loop construct, the second is an assignment. Fortran does
> not depend on spaces, does not have reserved words, and has few
> restrictions on how you form an identifier, so until it sees the "." or
> the "," it can't tell that the statement is an assignment or is a loop. In
> fact, while technically it is legal syntax, most people who write Fortran
> would consider the second example to be incorrect.
>
> So in Fortran, you can't even use spaces or delimiters to determine
> whether some reference is a variable or an imperative statement until much
> further along in the line. Thus implementing an "implicit call" would be
> very difficult if it was even possible.
>
> Now, Cobol has a number of advantages including imperative command-based
> statements. This makes writing a compiler easier, at the expense of
> making the language to be compiled more rigid. Which is exactly the state
> of Cobol programs.
>
> Now, it is conceivable to allow such a construct if some way can be found
> to allow a method reference to be used such that some keyword in the
> stream allows the program to be aware that this is what is being done.
>
> Actually, this might not be a bad idea, and it sounds interesting,
> although I don't know if it can be implemented in a reasonable fashion
> giving the method I suspect most Cobol compilers are implemented.
>
We'll never know...:-)

Pete.

Frank Swarbrick

2006-12-03, 6:55 pm

P. Raulerson wrote:
> You should look into Smalltalk- right up your alley. Of course, it drives
> those of us who are indoctrinated with procedural languages right crazy...
>
> I did not know that the MF had a new "University Edition" out, the last one
> I knew of was version 3.0. Wayyy behind the times. This one may be a little
> old as well, which is why you are picking up errors. The University edition
> is a way that MF can make a bit of cash off older - basically
> non-supported - versions of the product.

Hmm, I've looked at Smalltalk and never found it particularly readable.
Or understandable. :-) I am definitely a procedural language
programmer. I find OO stuff to be fascinating, but not always 'natural'.

NE 5.0 is the "latest and greatest". Just released this year. You may
be thinking of Fujistu, which I believe gives away 3.0 of their product.
As far as I know the NE "University Edition" is pretty much full
functioning, other than only allowing up to 2200 lines of source code
per executable. See the following link for more information:
http://www.microfocus.com/Resources...sp?productid=52

Frank

Frank Swarbrick

2006-12-03, 6:55 pm

Paul Robinson wrote:
> Frank Swarbrick wrote (edited):
>
>
>
> Okay, having actually done maintenance on compilers including written
> more than one, I'll state why I don't think your idea will work, at
> least, not in the context of Cobol.

Don't get me wrong. I was not at all suggesting this usage for COBOL.
I was suggesting it for if I were developing my own language; a language
that is not COBOL.

> Now, I will admit I have not worked on anyone else's Cobol compiler so I
> don't know how they work, I will offer some thoughts on the subject
> based on how I suspect they work. I may be wrong on this point but
> considering the way Cobol reference manuals show Cobol syntax, I have a
> reasonable belief that this would be the way it would be done.
>
> Presumably the parser for a Cobol Compiler is going to presume some
> fixed syntax, i.e. a specific DIVISION having certain contexts. In
> fact, the typical reference manual for a Cobol Compiler will have line
> and box based syntax diagrams showing exactly what particular symbols
> are permissible at a particular point, e.g. in the DATA DIVISION, if
> there is a two-digit number, it is expected to be followed by either a
> data name, blank or FILLER, followed by PIC or PICTURE or some other terms.
>
> Now, in order to allow something like this, you would have to have some
> way to allow a Cobol parser to identify that this is a method (or
> function) call.
>
> If we enter the PROCEDURE DIVISION, typically what you have are a series
> of sentences in which the first word, which is a "verb", dictates what
> the sentence means, i.e. what action is to take place. That particular
> verb has certain permitted parameters and options.
>
> Actually, you could do something like this if you had a provision that
> referencing an identifier is conditionally a method call. Of course,
> this also causes a problem if the method name or object name are the
> same as or similar to a Cobol keyword. But the high probability is that
> it would be an extreme effort to be able to implement such a thing,
> since I suspect that Cobol compilers tend to be keyword driven, thus
> allowing them to implement the "implicit call" function (where reference
> to a procedure or function implicitly calls that function without use
> of, say, a CALL (or PERFORM in Cobol) would require potentially a
> significant rewrite or even a reengineering of the parsing routines of
> the compiler.
>
> Languages that implement "implicit call" can do this because they have
> provision for referencing an identifier as either an assignment (if the
> symbol following the identifier is the assignment symbol), or a
> procedure call if the identifier is a procedure / function, or is
> followed by a parameter list.
>
> C, Pascal and Visual Basic all support "implicit call." Some languages,
> it would be very difficult to implement.
>
> In Fortran, for example, you have something like
>
> DO 5 I = 1, 10
> or
> DO 5 I = 1.10
>
> The first is a loop construct, the second is an assignment. Fortran
> does not depend on spaces, does not have reserved words, and has few
> restrictions on how you form an identifier, so until it sees the "." or
> the "," it can't tell that the statement is an assignment or is a loop.
> In fact, while technically it is legal syntax, most people who write
> Fortran would consider the second example to be incorrect.
>
> So in Fortran, you can't even use spaces or delimiters to determine
> whether some reference is a variable or an imperative statement until
> much further along in the line. Thus implementing an "implicit call"
> would be very difficult if it was even possible.
>
> Now, Cobol has a number of advantages including imperative command-based
> statements. This makes writing a compiler easier, at the expense of
> making the language to be compiled more rigid. Which is exactly the
> state of Cobol programs.
>
> Now, it is conceivable to allow such a construct if some way can be
> found to allow a method reference to be used such that some keyword in
> the stream allows the program to be aware that this is what is being done.
>
> Actually, this might not be a bad idea, and it sounds interesting,
> although I don't know if it can be implemented in a reasonable fashion
> giving the method I suspect most Cobol compilers are implemented.

I'm sure you are correct about why this would not work for Cobol.
Unlike many other languages, COBOL seems to be based on a "beginning of
statement" indicator rather than an "end of statement" indicator. This
is why there is a need for the CALL and INVOKE statement keywords (not
to mention COMPUTE), but why COBOL does not need to have parentheses
around parameters. It knows when the statement is done because it hits
a keyword indicating the beginning of a new statement. This is why one
can have:

move object::"method"(parm1, parm2) to receiver

but cannot have just

object::"method"(parm1, parm2)

(I'm sure you know this.)

I will say it really annoyed me until I realized why it was done this way.

Anyway, if you're interested you can look at the language parser for
OpenCobol. Amazingly simple to read. (Doesn't include any OO stuff,
though.)

http://open-cobol.cvs.sourceforge.n...r.y?view=markup

Frank

P. Raulerson

2006-12-03, 6:55 pm

I got to talk once with a man named Dan Ingalls, just for a few minutes. He
impressed me that Smalltalk could actually be a language worth using. Years
later I ran into VisualAge Generator, and convinced myself beyond any
possible doubt that Smalltalk and the RealWorld should not be allowed to
meet, interact, or seriously depend upon each other. The Sprint billing and
customer service system tends to support that point of view. ;)

Okay, I really do think Smalltalk has it's uses and is a pretty

language. I do find it difficult to interface with the existing "real world"
of COBOL, RPG, Assembler, C, and Java. Very good concepts in it, and where
it DOES work and work exceptionally well, is when it is used to produce
visual interfaces. It really shines in that area, and with good reason of
course.

Since this discussion has taken off on an unexpected turn, I offer this
link. It is a (legal or not) copy of a paper written by Andy Kay, and it
really

. ;)

http://www.iam.unibe.ch/~ducasse/Fr...HistoryHOPL.pdf

To really throw a zinger into the discussion, Ada is probably the best
example of an implemented OOL that can actually be used to get things done.
That is of course, my opinion, but check it out. The Algol background on the
language gives rise to really intuitive syntax, and the "real world" things
in it, like exception handling (and some COBOL heritage), allow you to
really use the thing.

-Paul

"Frank Swarbrick" <infocat@sprynet.com> wrote in message
news:%7Fch.6392$tM1.4619@newsread1.news.pas.earthlink.net...
> P. Raulerson wrote:
>
> Hmm, I've looked at Smalltalk and never found it particularly readable. Or
> understandable. :-) I am definitely a procedural language programmer. I
> find OO stuff to be fascinating, but not always 'natural'.
>
> NE 5.0 is the "latest and greatest". Just released this year. You may be
> thinking of Fujistu, which I believe gives away 3.0 of their product. As
> far as I know the NE "University Edition" is pretty much full functioning,
> other than only allowing up to 2200 lines of source code per executable.
> See the following link for more information:
> http://www.microfocus.com/Resources...sp?productid=52
>
> Frank

P. Raulerson

2006-12-03, 6:55 pm

Just a comment:
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4tftu9F13rndoU1@mid.individual.net...

"getters and setters" typically refer to METHODS used to set a property, as
you so aptly described. However, there is nothing that says the properties
*must* be PUBLIC. Indeed, Getters and Setters are used to encapsulate the
format of private properties inside an object, and in specific, their
implementation.

Second, unlike is some of the Microsoft world, it is pretty common to pass
objects to ADD or INSERT methods and have the method determine what kind of
object is dealing with. "+" is usually used as an example of this - being
able to add two integers or concatenate two strings, or convert an integer
to a string and add it to another string. That kind of stuff. As you pointed
out, they are also regular parts of collections, and hide the underlying
implementation.

-Paul

<snip lots of good stuff here to get to the part I am commenting on ...>
> (The SET method of the list object is implicit if it is a COM object (and
> those are the ones I mainly deal with...) If it isn't, then you would need
> to write (or generate) your own GET and SET methods) The Fujitsu COM
> interface Class provides these methods and saves you the trouble of having
> to wrap your .dll with the layers and interfaces you would otherwise need.
> The use of SET as shown here, will not work outside the Fujitsu Object
> COBOL environment (You could simulate it very easily though).
>
> It's not a good example, because SET actually sets the property, which is
> the same as "inserting" it... Any INSERT Method, presumably has something
> to be inserted, so there will usually be further information required.
>
> Something that might use an INSERT method could be a database object
> (Collections use ADD)
>

Richard

2006-12-03, 6:55 pm

Pete Dashwood wrote:

> SPECIFIC (to the example above):
>
> 1. The insert may need a different number of parameters if you decide to
> extend it's functionality.

That's what overloading and mangling is for.

insert(something, something, blobby)

is not the same method as:

insert(something, something)

but probably invokes the latter as well as dealing with the blobby.

Another way of doing this is with defaults on parameters:

insert(something, somthing, blobby=None)

if the method is invoked with only two parameters then the variable
blobby has the value None (or some other as required) so inside the
method one can:

if ( bloobly ):
do something with blobby

> (Suppose we decide to add BLOBs (Binary Large Objects... say, images) to the
> database and need to add a signature to each one immediately before writing
> it, after virus checking it. Now there is a specific behaviour required for
> BLOBs, but it only marginally deviates from the standard INSERT processing.
> A new Method ("BLOBBY") is added to the DBObject Class as a private method
> that will be activated before the INSERT method if a certain property is
> set. BLOBBY will calculate and check the signature and ensure it is inserted
> in the data structure. The INSERT method will not be touched; it will insert
> the structure just as always.
>
> invoke DBObject
> "SET-DBDataLocation" using ws-structure-ptr
> end-invoke
>
> if its-a-blob
> invoke DBObject
> "SET-DBBLOBFlag" using by value TRUE
> end-invoke
> end-if
>
> invoke DBObject
> "insert" *> Note no parameters to INSERT method...
> returning ws-DBStatus
> end-invoke
>
> Only new programs that are required to deal with BLOBs need the new code.
> Maybe BLOBs can only be added to one specific database, in one specific
> system... there are any number of possibilities. The point is that any code
> in any system which is using the INSERT method, and does NOT require BLOB
> functionality, continues to function as it always has. It requires neither
> change nor regression testing.)

Yeah, right. What happens if one part of the the program requires the
new funtionality and it is not required in the rest. Once the
SET-DBBLOBFlag is set then it may stay set and an insert from somewhere
else duplicates the blob.

> 2. If you use a parameter list, and one or more of the items in the list
> changes, due to extended functionality or overrides in the future, you must
> REGRESSION TEST EVERY single program that uses the INSERT method.

No more so then your way.

> 3. Linking specific parameters to specific methods does not encouirage
> method generalisation. Seeing fundamental behaviour as modifiable through
> properties, is a good way to avoid maintaining (changing and modifying what
> methods do) code.

So does overloading.

So does having a method "insert-with-blob", or even class-with-blob,
insert method.

> The best compiler I ever worked on used transition diagramming for the
> parsing and was blazingly fast.

XE13 ?

Pete Dashwood

2006-12-03, 6:55 pm

Thanks for the comments, Paul.

I should have made it clear that I was describing what I consider to be
personal "best practice" and not necessarily what can actually be done.

I know GET and SET methods can be used to manipulate private properties, but
I don't do that. If I want things manipulated I make them public... :-)

Pete.

TOP POST - nothing new below

"P. Raulerson" <paul.rl@raulersons.com> wrote in message
news:ZIFch.11140$YI1.4490@newsfe15.lga...
> Just a comment:
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:4tftu9F13rndoU1@mid.individual.net...
>
> "getters and setters" typically refer to METHODS used to set a property,
> as you so aptly described. However, there is nothing that says the
> properties *must* be PUBLIC. Indeed, Getters and Setters are used to
> encapsulate the format of private properties inside an object, and in
> specific, their implementation.
>
> Second, unlike is some of the Microsoft world, it is pretty common to pass
> objects to ADD or INSERT methods and have the method determine what kind
> of object is dealing with. "+" is usually used as an example of this -
> being able to add two integers or concatenate two strings, or convert an
> integer to a string and add it to another string. That kind of stuff. As
> you pointed out, they are also regular parts of collections, and hide the
> underlying implementation.
>
> -Paul
>
>
> <snip lots of good stuff here to get to the part I am commenting on ...>
>
>

Pete Dashwood

2006-12-03, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1165184299.836974.231480@l12g2000cwl.googlegroups.com...
>
> Pete Dashwood wrote:
>
>
> That's what overloading and mangling is for.
>
> insert(something, something, blobby)
>
> is not the same method as:
>
> insert(something, something)
>
> but probably invokes the latter as well as dealing with the blobby.

Precisely my point. Maybe you missed it :-)?
>
> Another way of doing this is with defaults on parameters:

Sure. There are many ways of doing things; I out lined what I personally
prefer.

>
> insert(something, somthing, blobby=None)
>
> if the method is invoked with only two parameters then the variable
> blobby has the value None (or some other as required) so inside the
> method one can:
>
> if ( bloobly ):
> do something with blobby
>
>
> Yeah, right. What happens if one part of the the program requires the
> new funtionality and it is not required in the rest. Once the
> SET-DBBLOBFlag is set then it may stay set and an insert from somewhere
> else duplicates the blob.

Then it is your responsibility as a programmer to ensure that you unset it
after use, IF you plan on using this same instance of the DBObject in places
where you don't want it set...

It comes back to modifying behaviours (or not...)

>
>
> No more so then your way.

"My way" does not require this and I don't do it.
>
>
>
> So does overloading.

Yes, I agree.
>
> So does having a method "insert-with-blob", or even class-with-blob,
> insert method.

Sure. It was a contrived example and not a good one. I was trying to
summarize some concepts and attempt to explain why I do what I do. I never
suggested it was the "only way".

>
>
>
> XE13 ?
>
No, although I agree XE13 was fantastic in its time.

It was a B500 compiler for Burroughs (remember them :-)...? part of the
BUNCH (Burroughs, Univac, NCR, CDC, and Honeywell) as IBM dismissively
called anyone who was not IBM. Note that they didn't even consider ICL
:-)... guess it didn't fit their acronym...

Pete.

Pete Dashwood

2006-12-03, 6:55 pm

"Frank Swarbrick" <infocat@sprynet.com> wrote in message
news:%7Fch.6392$tM1.4619@newsread1.news.pas.earthlink.net...
> P. Raulerson wrote:
>
> Hmm, I've looked at Smalltalk and never found it particularly readable. Or
> understandable. :-) I am definitely a procedural language programmer. I
> find OO stuff to be fascinating, but not always 'natural'.
>

You are in good company, Frank. Most of the procedural programmers I've
tried to retrain have exactly this problem. On the other hand, people who
know nothing about programming take to OO like ducks to water :-)

It comes down to being able to set aside what you already "know", and look
at the concepts as if you were encountering programming fo rthe first time.

(See my discussion elsewhere in CLC archives regarding ITSA and ITSLIKE...)

It took me several months of grappling with OO COBOL when it first came
out... I gave up and decided to learn Java instead. Because it was a
completely new (to me) language I had to look at it as if I knew nothing.
Within a w

I was comfortable with OO concepts, within a month I was
writing Java and enjoying it, and then going back for another look at OO
COBOL, everything just fell into place...

> NE 5.0 is the "latest and greatest". Just released this year. You may be
> thinking of Fujistu, which I believe gives away 3.0 of their product. As
> far as I know the NE "University Edition" is pretty much full functioning,
> other than only allowing up to 2200 lines of source code per executable.
> See the following link for more information:
> http://www.microfocus.com/Resources...sp?productid=52
>
> Frank

This raises another pet peeve of mine... Why would you support a company
that simply limits and restricts you, instead of encouraging you?

Limits on source lines? Royalties on developed applications? Why? It is
this attitude (and MF are by no means alone in it) that is killing COBOL.

I would MUCH rather have a complete and full evaluation for say, 30 days,
that lets me get the feel of a product, than some emasculated version that
simply wastes my time and effort.

There's not much incentive to develop anything if it doesn't belong to you
after you have done so...Run time fees are simply a joke. Vote with your
feet and don't support companies that use this model.

Case in point...

I have recently completed setting up my wireless LAN and need to have remote
access to control machines that are used sometimes on the network (all
laptops that could be at any location around the house). There is a company
called LogMeIn that offer such a service. I tried it for a w

and was
very impressed. I could grab any machine anywhere in the house and control
all the others from it. Good support, stable platform, and some nice touches
like being able to share the local clipboard with any other machine on the
network.

Decided I might buy it, then found it is $12 a month for the service, on
each machine, ongoing....

Downloaded Remote Administrator instead, got all the same effects except for
the clipboard (and I wrote a script to workaround that in about 10 minutes),
and it is a one time registration of $29.99. I registered in a heartbeat.

The point is that a revenue generation model that goes for an ongoing fee
(unless the fee is tiny enough to be insignificant and brings added benefits
like ongoing support), will lose every time against one that has a one time
charge and provides mainly the same service.

Pete.

Richard

2006-12-03, 6:55 pm

Pete Dashwood wrote:

> Then it is your responsibility as a programmer to ensure that you unset it
> after use, IF you plan on using this same instance of the DBObject in places
> where you don't want it set...
>
> It comes back to modifying behaviours (or not...)

It is only necessary to unset after use if there are places where it is
not set before use because it is not required, or you missed one.

It's much easier with an overloaded or defaulted parameter or even a
derived class because it can then be done in just one place and apply
everywhere. No need to worry about whether an unset is needed.

>
> "My way" does not require this and I don't do it.

Using an overload, or a derived class, or a defaulted parameter also
does not need a regression test for every single program, or at least
no more so than your way.

> Sure. It was a contrived example and not a good one. I was trying to
> summarize some concepts and attempt to explain why I do what I do. I never
> suggested it was the "only way".

How do you deal with multithreading ? It would seem to me that you are
creating a critical section the runs from the set through the invoke to
the unset. That is not a good thing. Parameter passing keeps the
critical section to just the invoke, which can be made thread safe
quite easily.

> It was a B500 compiler for Burroughs (remember them :-)...?

Yes, AEPB had one that I helped replace with a 1903S or something.

P. Raulerson

2006-12-03, 9:55 pm

Now that one really does have me curious Pete. Care to go on with the
subject a bit more length?

I tend to make almost every property private just so that I can hide the
implementation of it. I usually generate a class that I use to pass the data
as well. Works great in my world. In procedural parlance, I can publish an
API and change the implementation behind it as many times as I wish without
disturbing other people using it. Indeed, it may be that I am misusing
properties in some way, but that has always seemed the most logical and
correct way to implement them - since way back in the early 1980's at least.

-Paul

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4th387F145bllU1@mid.individual.net...
> Thanks for the comments, Paul.
>
> I should have made it clear that I was describing what I consider to be
> personal "best practice" and not necessarily what can actually be done.
>
> I know GET and SET methods can be used to manipulate private properties,
> but I don't do that. If I want things manipulated I make them public...
> :-)
>
> Pete.
>
> TOP POST - nothing new below
>
>
> "P. Raulerson" <paul.rl@raulersons.com> wrote in message
> news:ZIFch.11140$YI1.4490@newsfe15.lga...
>
>

Pete Dashwood

2006-12-04, 7:55 am

X-Trace: individual.net 8PlFOQoncXjX8iHFho9u6wG9LpJs3zTES5/c9lMR8NrRmPg6G4
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Response
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:161987

"P. Raulerson" <paul.rl@raulersons.com> wrote in message
news:ZAMch.2560$Rj.108@newsfe19.lga...
> Now that one really does have me curious Pete. Care to go on with the
> subject a bit more length?
>
> I tend to make almost every property private just so that I can hide the
> implementation of it. I usually generate a class that I use to pass the
> data as well. Works great in my world. In procedural parlance, I can
> publish an API and change the implementation behind it as many times as I
> wish without disturbing other people using it.

Absolutely, a very good approach.

>Indeed, it may be that I am misusing properties in some way, but that has
>always seemed the most logical and correct way to implement them - since
>way back in the early 1980's at least.
>

No, I don't see that as misuse.

Going back to what I said earlier...

I see properties as allowing external change of behaviours, and also
providing a low volume data interface to/from my objects.

(Most of my objects have a property called interfaceBlock which is a COM
String of 8192 bytes, and can be structured any way I like). This block is
usually in the Class factory so it can be easily shared by all methods -
different methods may interpret its contents differently.)

I like your idea of using a data interface class and that is probably a more
elegant way of doing this. I'll think about that some more :-)

Coming back to use of private and public properties... It may have been
confusing when I said that properties are public; obviously if you are
getting and setting them, it doesn't matter whether they are public or
private. It just so happens that in my own perceptions I consider anything
that is available externally from the object to be public and so I have
historically declared them that way... it's just a habit really.

We all tend to settle on what works best for us.

I'm not suggesting that my approach is the best or only one; it works for me
and I don't maintain code (once is is debugged and doing what it is meant
to), as I used to do when I developed with procedural code only.

After five years exclusively using OO (and a few years playing with it
before that)
there is no way I would go back to non-OO development.

Pete

Pete Dashwood

2006-12-04, 7:55 am

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1165190161.501114.48460@n67g2000cwd.googlegroups.com...
>
> Pete Dashwood wrote:
>
>
> It is only necessary to unset after use if there are places where it is
> not set before use because it is not required, or you missed one.

Isn't that what I said? If you want the behaviour of an object dynamically
modifiable at run time then it is your responsibility to ensure it is
modified or not. There certainly are other ways this can be achieved and I
take no issue with the ones you have suggested. I just don't personally
prefer them because of other considerations that are far too numerous to go
into here.
>
> It's much easier with an overloaded or defaulted parameter or even a
> derived class because it can then be done in just one place and apply
> everywhere. No need to worry about whether an unset is needed.
>
Well, that's your opinion.

And there are circumstances where I would completely agree with you. But not
always, and that is why I am trying to deal with this at a conceptual,
rather than a specific level

I see other spin offs from those solutions which make them unattractive to
me, but I don't intend to argue it because I don't think what you are saying
is wrong :-)

>
> Using an overload, or a derived class, or a defaulted parameter also
> does not need a regression test for every single program, or at least
> no more so than your way.

I don't recall arguing that... I don't personally like overloading because
it requires more complexity in the overloaded object, but that's just a
personal preference and I don't think anything you have suggested is "wrong"
>
>
> How do you deal with multithreading ? It would seem to me that you are
> creating a critical section the runs from the set through the invoke to
> the unset. That is not a good thing. Parameter passing keeps the
> critical section to just the invoke, which can be made thread safe
> quite easily.
>
>
> Yes, AEPB had one that I helped replace with a 1903S or something.
>

Pete.

Howard Brazee

2006-12-04, 6:55 pm

On Sun, 03 Dec 2006 19:17:55 GMT, Frank Swarbrick
<infocat@sprynet.com> wrote:

>Don't get me wrong. I was not at all suggesting this usage for COBOL.
>I was suggesting it for if I were developing my own language; a language
>that is not COBOL.

Before we could reasonably discuss your new language's needs, we need
to know what was the intent of this new language. What is need is
this language supposed to fulfill.

Richard

2006-12-04, 6:55 pm

Pete Dashwood wrote:

> Isn't that what I said?

No.

> If you want the behaviour of an object dynamically
> modifiable at run time then it is your responsibility to ensure it is
> modified or not.

That's why I prefer mechanisms where the program itself can take
responsibility for doing so. I'm too lazy to want to do it myself, and
I don't trust others to do so.

> There certainly are other ways this can be achieved and I
> take no issue with the ones you have suggested. I just don't personally
> prefer them because of other considerations that are far too numerous to go
> into here.

Well, just one will do. I can't think of _anything_ that makes setters
and unsetters better.

> I don't recall arguing that... I don't personally like overloading because
> it requires more complexity in the overloaded object, but that's just a
> personal preference and I don't think anything you have suggested is "wrong"

But in your example you still have to add code to the method to test
whether the blob was set or not and deal with it. In what way is an
overloaded method (not object), or a 'with_blob' method, or default
parameter, adding more complexity than that ?

I noticed you ignored the issue of threading.

Pete Dashwood

2006-12-04, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1165255578.298333.270600@n67g2000cwd.googlegroups.com...
>
> Pete Dashwood wrote:
>
>
> No.
>
>
> That's why I prefer mechanisms where the program itself can take
> responsibility for doing so. I'm too lazy to want to do it myself, and
> I don't trust others to do so.
>
Fine.

>
> Well, just one will do. I can't think of _anything_ that makes setters
> and unsetters better.

Derived classes are fine and I do use them sometimes, overloading is NOT
fine because it requires parameters to be passed and I don't want to do
that, the considerations behind this are much more than I intend to go into
here.

I am not arguing that setters and unsetters are BETTER (in fact, I'm not
arguing anything... sorry :-)), just that they are better for me, because I
don't want parameters passed to methods.

I prefer to have the paramters pre-set as properties before invoking the
method. I have no intention of discussing this further, other than to say it
was many months of experiment which led me to this approach.
>
>
> But in your example you still have to add code to the method to test
> whether the blob was set or not and deal with it. In what way is an
> overloaded method (not object), or a 'with_blob' method, or default
> parameter, adding more complexity than that ?

If overloading is used, parameters must be passed to the method. They will
be different parameters to the same method (or another copy of it within the
Class). If the same method is used it will have an overhead to decide which
set of parameters it was passed and set properties appropiately, if another
method with the same name is used, this is just a needless duplication of
Class code, as far as I'm concerned. There is a requirement for the method
to set these parameters into properties anyway... I like to do this as a
separate exercise, which is not the responsibility of the method, BUT that
isn't carved in stone, there are many other factors that may cause me not
to do this, and I don't ALWAYS do it. It is a preference.

The principle is that each method is responsible for what it does, with the
parameters that modify its behaviour pre-set for it. Yes, the code is the
same either way, but there are subtle benefits in having a layer of
separation. (In fact, I like Paul's idea of a separate interface Class and
am thinking more on this...)
>
> I noticed you ignored the issue of threading.
>
Mainly because it isn't relevant for the work I am doing.

When I actually NEED to have multi-threading I use Java and implement the
threading Classes. Most of what I'm doing is component based; I can use a
Java threaded framework and call components within that, on the extremely
rare occasions where I would need to. There is seldom need to have innate
multi-threading in an environment where each "thread" can have its own
instance of the object anyway...

COM components are always apartment threaded .

There are so many possible factors and considerations and specific instances
and exceptions, that I have not attempted to make blanket statements here.
What I have outlined are some principles which I have found to be useful,
and some preferences which are personal.

Pete.

Charles Hottel

2006-12-04, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4th387F145bllU1@mid.individual.net...
> Thanks for the comments, Paul.
>
> I should have made it clear that I was describing what I consider to be
> personal "best practice" and not necessarily what can actually be done.
>
> I know GET and SET methods can be used to manipulate private properties,
> but I don't do that. If I want things manipulated I make them public...
> :-)
>
> Pete.
>
> TOP POST - nothing new below
>
Pete, if you have the time check out this link on "Why Getter and Setter
Methods Are Evil" as I would like to hear your opinion on this:

http://www.javaworld.com/javaworld/...05-toolbox.html

I am assuming that you would disagree but I would like to hear your
reasoning. Thanks.

P. Raulerson

2006-12-04, 6:55 pm

Ah, I see where you are coming from now. Makes a lot of sense I think. I get
into so many different kinds of projects, that I tend to use different
methods for different tasks. OO doesn't help me much with say, UNIX Kernel
programming. On the other hand, Database processing sometimes makes sense as
an OO Programming Project, and sometimes only as a Object Oriented Design
(with the implementation in a procedural language.) Visual Processing, like
Windows stuff - almost always OO seems to be the best choice.

I see very little value in using an OO design or Programming Language (or
even many features) in a tree killer program. Where brute force is called
for, very careful design at a low level of detail is called for. In a user
interface, it is just the opposite - high level behaviors have to be
defined.

In short, COBOL, RPG, Assembler, and such have their place, right along with
VB, Java, Smalltalk, and that crowd. I don't want to loose access to *any*
of them. ;)

-Paul

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4thstlFu9ev2U1@mid.individual.net...
>
> "P. Raulerson" <paul.rl@raulersons.com> wrote in message
> news:ZAMch.2560$Rj.108@newsfe19.lga...
>
> Absolutely, a very good approach.
>
>
> No, I don't see that as misuse.
>
> Going back to what I said earlier...
>
> I see properties as allowing external change of behaviours, and also
> providing a low volume data interface to/from my objects.
>
> (Most of my objects have a property called interfaceBlock which is a COM
> String of 8192 bytes, and can be structured any way I like). This block is
> usually in the Class factory so it can be easily shared by all methods -
> different methods may interpret its contents differently.)
>
> I like your idea of using a data interface class and that is probably a
> more elegant way of doing this. I'll think about that some more :-)
>
> Coming back to use of private and public properties... It may have been
> confusing when I said that properties are public; obviously if you are
> getting and setting them, it doesn't matter whether they are public or
> private. It just so happens that in my own perceptions I consider anything
> that is available externally from the object to be public and so I have
> historically declared them that way... it's just a habit really.
>
> We all tend to settle on what works best for us.
>
> I'm not suggesting that my approach is the best or only one; it works for
> me and I don't maintain code (once is is debugged and doing what it is
> meant to), as I used to do when I developed with procedural code only.
>
> After five years exclusively using OO (and a few years playing with it
> before that)
> there is no way I would go back to non-OO development.
>
> Pete
>

Richard

2006-12-04, 9:55 pm

Pete Dashwood wrote:

>
> If overloading is used, parameters must be passed to the method. They will
> be different parameters to the same method (or another copy of it within the
> Class).

> If the same method is used it will have an overhead to decide which
> set of parameters it was passed and set properties appropiately,

Well, no, that is what name mangling in C++ is for. The decision is
made at compile time.

> if another
> method with the same name is used, this is just a needless duplication of
> Class code, as far as I'm concerned.

Well, no. It just invokes the other method, no duplication at all:

method A_with_blob(p1, p2, blob): not overloaded
or method A(p1,p2, blob): overloaded
or method A(p1, p2, blob=NULL): if default parameter can be
use
....
if ( blob != NULL )
....
method A(p1,p2): not required if
default parameters can be used.
A_with_blob(p1,p2, NULL):

> There is a requirement for the method
> to set these parameters into properties anyway...

Well, no. Parameters don't need to be set into properties.

> I like to do this as a
> separate exercise, which is not the responsibility of the method,

Which imposes overheads and requires getter/setter methods to clog up
the class.

Frank Swarbrick

2006-12-04, 9:55 pm

Pete Dashwood<dashwood@removethis.enternet.co.nz> 12/03/06 4:37 PM >>>
>
>"Frank Swarbrick" <infocat@sprynet.com> wrote in message
>news:%7Fch.6392$tM1.4619@newsread1.news.pas.earthlink.net...
drives[color=darkred]
[color=darkred]
[color=darkred]
Or[color=darkred]
I[color=darkred]
>
>You are in good company, Frank. Most of the procedural programmers I've
>tried to retrain have exactly this problem. On the other hand, people who
>know nothing about programming take to OO like ducks to water :-)

I've been doing OO on and off since the early 90s, but I've never done what
I would consider a 'major project' in anything but COBOL (and C, long ago).
Until I do that I won't consider myself to be OO fluent. Now just to figure
out a 'major project' to do! :-)

>It comes down to being able to set aside what you already "know", and look

>at the concepts as if you were encountering programming fo rthe first
time.
>
>(See my discussion elsewhere in CLC archives regarding ITSA and
ITSLIKE...)
>
>It took me several months of grappling with OO COBOL when it first came
>out... I gave up and decided to learn Java instead. Because it was a
>completely new (to me) language I had to look at it as if I knew nothing.
>Within a w

I was comfortable with OO concepts, within a month I was
>writing Java and enjoying it, and then going back for another look at OO
>COBOL, everything just fell into place...
>
be[color=darkred]
[color=darkred]
functioning,[color=darkred]
[color=darkred]
http://www.microfocus.com/Resources.../description.as
p?productid=52[color=darkred]
>
>This raises another pet peeve of mine... Why would you support a company
>that simply limits and restricts you, instead of encouraging you?

Why? Because I can't find any alternative. At least when it comes to OO
support. There's OpenCobol, but it does not support OO.

>Limits on source lines? Royalties on developed applications? Why? It is
>this attitude (and MF are by no means alone in it) that is killing COBOL.

I don't disagree.

>I would MUCH rather have a complete and full evaluation for say, 30 days,
>that lets me get the feel of a product, than some emasculated version that

>simply wastes my time and effort.

Well there I will have to disagree a bit. 30 days is not enough time; at
least when your doing it on your own time and spending only an hour or two a
day on it, at most.

>There's not much incentive to develop anything if it doesn't belong to you

>after you have done so...Run time fees are simply a joke. Vote with your
>feet and don't support companies that use this model.

I don't (at this point, at least!) have any intention of selling a product I
might write in MF COBOL, so while I agree its ridiculous, I can't say it
really affects me.

But yes, it would certainly be nice if MF would do something like what
Microsoft did with Visual Studio Express. I don't expect them to give away
the bank, but it would be nice to have a fully functional compiler for free.
Perhaps only the command-line version, or something. Or a stripped down
version of the IDE that only offers the basics, while the 'bells and
whistles' would cost more. Have to leave them something to sell, after all!
:-)

Still, if I can get a good grip on the OO COBOL concepts I'd love to add
them to OpenCobol, which is indeed free. Perhaps a pipe-dream, but we shall
see...

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

Frank Swarbrick

2006-12-04, 9:55 pm

Howard Brazee<howard@brazee.net> 12/04/06 8:46 AM >>>
>On Sun, 03 Dec 2006 19:17:55 GMT, Frank Swarbrick
><infocat@sprynet.com> wrote:
>
>
>Before we could reasonably discuss your new language's needs, we need
>to know what was the intent of this new language. What is need is
>this language supposed to fulfill.

Everything that other languages don't have that I wish they did. Or "better
ways" of doing those things that they do have. :-)

Seriously, I'm just playing around. If I ever get serious about it I will
let you know. In the end, I just have a lot of "pet peeves", and I get our
my frustrations by making notes on how I wished things worked. Which is not
at all to say that anything I come up would be feasible, otherwise it seems
to me it would have already been done by someone else!

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

James J. Gavan

2006-12-05, 3:55 am

Frank Swarbrick wrote:
> Looking at examples supplied with MF Net Express reminded me of
> something that seems odd to me about all OO languages I've looked in to.
> They pretty much all invoke methods in a somewhat similar format in
> that the object comes first, followed by the name of the method,
> followed by any parameters.

etc... <snip>

Frank I'm not going to repeat the whole of your message but your point
was you found the generally accepted OO INVOKE syntax 'unacceptable' or
non-intuitive.
-------------------------------
1. COBOL APPROACH :

Let's go back to square one with COBOL :

- COBOL '74 from my old RM manual :-

CALL (Program : identifier/literal) USING, data-name-1, data-name-2 etc...

- COBOL 85

along with this IBM and at least MF introduced (non-standard) :-

The above with the addition of entry points to go directly to a
section/paragraph :-

CALL (Program: identifier/literal) ENTRY-NAME, USING, data-name-1,
data-name-2 etc.. RETURNING

- sequence above looks familiar when you think about OO ?

CALL(INVOKE) identifier/literal(Object Class), entry-name(Method-Name),
USING param-1, param-2 (can be a mixture of a series of Level 01's which
are either text or objects) returning ONLY ONE Level 1, (but can be a
series of 05's which again can be a mixture of text or object references).

If you want it changed to your way, you're gonna have to persuade J4 to
change the Procedural CALL syntax - good luck ! :-)

Initially I sure had problems coping with OO, (specifically the
'show-bit', i.e. GUIs and their relationship to the rest of OO), but I
never had a problem with the COBOL INVOKE syntax - just took it as read.
Think on it :-

a) INVOKE (program/class - or the Object created from "new") which
points at the "program" you want

b) Method-Name (equivalent to a Procedural Paragraph using the
entry-point feature) - frequently used methods in M/F are cached in momory.

c) USING Parameters - optional

d) RETURNING - optional

Pete's already covered above - but another take on why OO syntax is
'framed' as it is.
-------------------------------------------------------------------------

2. WHERE IT'S AT WITH OO COBOL

No peers to converse with, (and only some five names that I can think of
in the MF Forum that *really* used OO), I had to sweat it on my own.
Just like Pete focused on Components I dreamed up a design approach
which seemed to work for me, and indeed does. I was seriously getting to
the point that I thought I should write down my thoughts in a book. Step
One though, to be more universal, I would have needed to be comfortable
with the Web interfacing. Blow me down. M/F, (correct from their point
of view), switched horses to dotNet. Sod it! Upgrade to N/E 4 and 5 and
a new learning curve). At this stage I packed it in. I look at all the
imponderables associated with Webbing. I'll go googling and trip over
references which take me down a fresh avenue. Examples :-

- "I use Java 'cos that's where the money is, but using Smalltalk's
advanced features I can be more productive in Smalltalk than Java...."
No doubt he was thinking of the commercial versions Dolphin or VisualAge
(???) from Cincomm ???).

- SQUEAK (the non-commercial version of Smalltalk) has a tool SEASIDE
which is web focused - good looking screens. Then I pick up in a
separate message, "SEASIDE is SLOWooooooo !".

- "PERL or RUBY lack these features .....".

The list of negatives for ANY language is bewildering. You're right we
DO need a new language for programming called BABEL or ESPERANTO - it
truly is crazy how people keep on coming up with new approaches, rather
than developing a solid base model - and using OO - to tack on new
features which are missing.

Just read in the paper about Vista - seems Bill's gang had to sit down
and rewrite much of it from scratch !. What about OO REUSE ???? C# -
read an article where one of the architects was purloined from Borland
for $1 million. It's claimed C# embraces the best of Java and C++ -
remains to be seen. Anyway, how do you know ? A superficial knowledge
wont help, you need to be not just a 'looker' but a reasonably long-time
developer in both those languages before you can endorse Microsoft's
intended objective.

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

3. PASSING ON MY KNOWLEDGE (EXPERIENCE).

Wont be using it any more but you're welcome to use code below
associated with that MF DisplayList example you quoted.

Gavan's Rule : Write a routine once. Subsequently you write something
similar a little way on. Hmmmm. Then later on you find yourself writing
a third version under slightly different circumstances. CRAZY ! Think it
through; how can you make one routine serve all three. The answer is -
REUSE, generic support classes - in Pete's case he has gone for
components. The support class approach doesn't trigger immediately, but
when you get a comfort zone with OO coding, it sits there in the back of
your mind as a technique. Doesn't immediately fall into place and much
of your thoughts can be diagrammed on paper before you achieve what you
eventually code. (Your design patterns in banking although different
from mine oil/gas, stil contain common demnominators).

So firstly an explanation of the code below. I *had* an ISAM file, which
is now an SQL Table and I need a Business Control Class "Edit
Descriptions". I need a menu to allow the user to select different
record types from that Table, display them in a Listbox then either
allow the user to enter a new Prime Key (new record) or select an
element from the Listbox for changing/deleting. Further, should the user
enter the PrimeKey for an EXISTING record in the Listbox, that is
checked against the Listbox Collection and if present, that's what gets
displayed.

Now the code you quoted is 'Mickey Mouse' - that's not to denigrate M/F
but they have to keep the examples simple to get the idea across. But as
you should be able to pick out from the code below, Reusable classes can
be used with any display list/collection/dictionary. (If you check the
methods for collections it is possible to display the whole list with
the method "display" - not particularly helpful - but gives you a DOS
text screen wrapping around, where you can view the unformatted contents
of the collection. (Probably may not have found it yet but all the
methods are in the following file - using your appropriate path :-

"C:\Program Files\MERANT\Net Express\Base\BIN\MFNXCL31.CHM"

Note mine is Version 3.1).

Master Menu
Selection
------------

Pete Dashwood

2006-12-05, 7:55 am

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1165280877.871260.111520@73g2000cwn.googlegroups.com...
>
> Pete Dashwood wrote:
>
>
>
> Well, no, that is what name mangling in C++ is for. The decision is
> made at compile time.
>

I don't write C++, have no intention of doing so and have no idea why you
would want or need to mangle names.

In the languages I DO use (including OO COBOL) what I stated stands.

Furthermore I ONLY use late binding and I don't want decisions made at
compile time (irrespective of whether names are 'mangled' or not...)

>
> Well, no. It just invokes the other method, no duplication at all:

Not in the environments I use.

>
> method A_with_blob(p1, p2, blob): not overloaded
> or method A(p1,p2, blob): overloaded
> or method A(p1, p2, blob=NULL): if default parameter can be
> use
>

All of the above use parameters. The whole point of my post is to avoid
doing that. The reasons WHY I would want to avoid doing that are beyond the
scope of this discussion. (I did give some clues but I'm really not
prepared to explain or debate it because I really don't care what people do.
My whole point is that I have found this approach useful; if people
disagree, that's fine, don't use it. I'm not on commission here... :-). If
someone read it and found it made them think and in the course of that they
got something they could use, my time was not wasted. Some people here are
just getting in to OO. I think that's commendable, although I'd rather they
had done it 10 years ago :-). Showing one carefully qualified, possible
approach, and trying to explain the underlying concepts to it, seemed to me
a good idea. (In retrospect, perhaps it wasn't and I'll think twice about
future posts here.)

if ( blob != NULL )
> ....
> method A(p1,p2): not required if
> default parameters can be used.
> A_with_blob(p1,p2, NULL):
>
>
>
> Well, no. Parameters don't need to be set into properties.

So exactly how does the method store and reference them? (I am using
'properties' loosely here to include local variables or any data storage, in
line with the concept I previously outlined ('Methods' are behaviours,
'Properties' are data.) A pointer to a parameter or a parameter which is, in
fact a pointer, is still 'data' that is used by the method.)

>
>
> Which imposes overheads and requires getter/setter methods to clog up
> the class.
>
With COM these 'overheads' are in the Class wrapping and cost me nothing. My
Classes (the ones which are COM ones, and that is most of them) do NOT
contain GET and SET methods to 'clog them up'. These methods are provided
automatically by the interface. (I did say that... but your own
considerations as to how things should work may have blinded you to it)

Richard, I think we will have to disagree here. I'm not using C++ and my
reasons for not wanting parameters to methods are more than I can even begin
to spell out here. That's just the way I do it. As it works very well for me
I see no reason to change it.

I respect very much your opinions and ability and I don't see disagreement
as being personal, but I' m not looking for argument on OO (tired of it
years ago in this forum) so I can't see any point in pursuing this further.
You've said nothng positive about what I posted, despite the fact that I am
not trying to persuade anyone, not suggesting my solution as 'the only way',
and freely admitted that the circumstances surrounding a given
implementation are complex and may require deviation from a specific. (I
cannot in all honesty say that I have NEVER used overloading, or derived
classes, but I pretty much discarded these approaches some time ago, for
reasons of my own which are part of a much bigger framework. I believe in
separation layers. It has worked for me many times over the years. Like I
have said all along, it is a personal preference. But it is not black and
white.)

I can live with your disapproval of what I do :-)

I still write SECTIONs in COBOL... :-) (That doesn't mean I don't appreciate
your arguments for not doing so...)

Pete.

Pete Dashwood

2006-12-05, 7:55 am

"Charles Hottel" <chottel@earthlink.net> wrote in message
news:2W2dh.6874$ql2.4513@newsread3.news.pas.earthlink.net...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:4th387F145bllU1@mid.individual.net...
> Pete, if you have the time check out this link on "Why Getter and Setter
> Methods Are Evil" as I would like to hear your opinion on this:
>
> http://www.javaworld.com/javaworld/...05-toolbox.html
>
> I am assuming that you would disagree but I would like to hear your
> reasoning. Thanks.
>

Pete Dashwood

2006-12-05, 7:55 am

Hi Charles,

I haven't time to go into all the pros and cons of this but I should clear
up some confusion that could arise from my post.

I DO make things Public as a general rule, where they will affect the
behaviour of a method. However, I expect them to be accessed via GET/SET
(accessor) methods. After reflecting on this discussion I have decided to
change this policy. (Not the accessor methiods; making them private...). I
mentioned elsewhere it is really just a historical habit. I think Paul's
point about hiding things (although this goes against my nature :-)) is a
valid one. Richard sees accessor methods as clogging up the object, and
many people would agree.

The fact is that it isn't black and white.

There are some circumstances where you really should use accessor methods
and there are others where it probably is OK to let object users manipulate
properties directly. Fundamentally, it depends on the application.

I followed the link you posted and read the article with as open a mind as I
could manage.:-)

I think some of the points are valid but there are other factors which were
not considered.

For a much more balanced discussion on this see...
[url]http://discuss.fogcr

.com/joelonsoftware4/default.asp?cmd=show&ixPost=121194&ixReplies=21[/url]

I believe that all of the reasons why I would use accessors are covered in
this discussion (and a lot more besides), along with reasons why you
wouldn't use them.

Most of what I am developing are components, and COM components at that. (I
am gradually going to transit to dotNET and am still studying dotNET Classes
and learning C#). Therefore, I am writing Library applications and these are
often best served with accessor methods (see discussion above)

Hope this helps,

Pete.

"Charles Hottel" <chottel@earthlink.net> wrote in message
news:2W2dh.6874$ql2.4513@newsread3.news.pas.earthlink.net...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:4th387F145bllU1@mid.individual.net...
> Pete, if you have the time check out this link on "Why Getter and Setter
> Methods Are Evil" as I would like to hear your opinion on this:
>
> http://www.javaworld.com/javaworld/...05-toolbox.html
>
> I am assuming that you would disagree but I would like to hear your
> reasoning. Thanks.
>

Howard Brazee

2006-12-05, 6:55 pm

On Mon, 4 Dec 2006 18:49:58 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

>
>Everything that other languages don't have that I wish they did. Or "better
>ways" of doing those things that they do have. :-)

That has always been popular - to find a solution for everything.
Isn't that what Einstein spent most of his adult life working on?

But you might as well design a tool for your garage that you could use
for all your woodworking, plumbing, auto, and electrical needs.

>Seriously, I'm just playing around. If I ever get serious about it I will
>let you know. In the end, I just have a lot of "pet peeves", and I get our
>my frustrations by making notes on how I wished things worked. Which is not
>at all to say that anything I come up would be feasible, otherwise it seems
>to me it would have already been done by someone else!

I enjoyed a language which someone wrote which I bought for my Atari
800. Action! was an implementation of someone's theoretical optimal
language. I tended to agree with its design, but the computing
world has gotten bigger.

Maybe a better analogy than the toolbox above is the transportation
industry. We have designed "universal" truck trailers that fit on
trains and on ships - but even these aren't optimal for all tasks -
they just take less labor to go from one medium to another. And as
with software, that design didn't anticipate some security issues.

Richard

2006-12-05, 6:55 pm

Pete Dashwood wrote:

[color=darkred]
> .. and have no idea why you would want or need to mangle names.

To show that your claims about 'overhead' is a strawman in many cases.

[color=darkred]
>
> All of the above use parameters. The whole point of my post is to avoid
> doing that.

And the point of my post was to show that using parameters does not
result in your claim of duplication of code.

> If
> someone read it and found it made them think and in the course of that they
> got something they could use, my time was not wasted.

Well, exactly. And if I illustrate that it does not necessarily aviod
overhead, or duplication, or other claims you have made, and does
introduce technical problems, such as critical sections, then I haven't
wasted my time either.

>
> So exactly how does the method store and reference them? (I am using
> 'properties' loosely here to include local variables or any data storage, in
> line with the concept I previously outlined ('Methods' are behaviours,
> 'Properties' are data.) A pointer to a parameter or a parameter which is, in
> fact a pointer, is still 'data' that is used by the method.)

It may well be that a parameter is being passed in order to be stored
inside the object in a property, or it may be that the parameter can
simply be referenced by the method without being stored somewhere else
first. You appeared to imply that it always required to be stored
before it could be used.

> With COM these 'overheads' are in the Class wrapping and cost me nothing. My
> Classes (the ones which are COM ones, and that is most of them) do NOT
> contain GET and SET methods to 'clog them up'. These methods are provided
> automatically by the interface. (I did say that... but your own
> considerations as to how things should work may have blinded you to it)

Well, yes, they do contain 'getters' and 'setters' even if they are
automatically created by the compiler, or perhaps they are created as
required on the fly at run-time. Either way they are as much, or more,
overhead as overloading or name-mangled methods.

> my reasons for not wanting parameters to methods are more than I can even begin
> to spell out here.

I suspect that you are very wise to avoid even starting with those
reasons.

> I can live with your disapproval of what I do :-)

Just as well.

William M. Klein

2006-12-11, 6:56 pm

I raised this issue during the '02 Standard development (along with WHY the
method had to be a literal, when CALL can have an identifier). Oh, well !!!

P.S. You may want to look at Micro Focus "vocabularies" that let you "write
your own syntax" (that uses OO under the covers).

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <infocat@earthlink.net> wrote in message
news:50lch.5827$ql2.1611@newsread3.news.pas.earthlink.net...
> Looking at examples supplied with MF Net Express reminded me of something that
> seems odd to me about all OO languages I've looked in to. They pretty much all
> invoke methods in a somewhat similar format in that the object comes first,
> followed by the name of the method, followed by any parameters.
>
> COBOL 2002
> invoke object "method" using by value parm1, parm2
> MF COBOL
> invoke object::"method"(parm1, parm2)
> Java
> object.method(parm1, parm2)
> Objective-C
> [object method:parm1 parm2name:parm2]
> Ruby
> object.method parm1, parm2
>
> One thing that I've come to believe is that it would often be more "natural"
> (for me) if the method name was specified first. The method is very often a
> verb. So why not something like:
> insert employee into list
>
> where 'insert' is the method name, 'employee' is the object to be inserted
> (the parameter) and 'list' is the object that is to receive the message.
> 'into' is just a noise word to make it more readable.
>
> What follows below is code from one of the MF ISO2002 examples, along with
> modified versions in other languages. The last "language" is just something
> I've been toying with. Right now it's a 2000+ line text document of my
> thoughts on an 'ideal' (hah!) programming language. Probably that's all it
> will ever be. But still, it keeps me off the streets.
>
> COBOL 2002:
> working-storage section.
> 01 displayList usage object reference DLinkList.
> procedure division.
> set displayList to DLinkList::"new"
> invoke displayList "add" using by value emp1
> invoke displayList "add" using by value car1
> invoke displayList "add" using by value indPlace1
> invoke displayList "add" using by value car2
> move listSize of displayList to noItems
> if noItems > 0
> invoke displayList "getfirst" returning displayItem
> invoke displayItem "display"
> perform until exit
> set displayItem to displayList::"getnext"
> if displayItem not = null
> invoke displayItem "display"
> else
> exit perform
> end-if
> end-perform
> end-if
> exit program.
>
> Micro Focus COBOL:
> working-storage section.
> 01 displayList DLinkList.
> procedure division.
> set displayList to DLinkList::"new"
> invoke displayList::"add"(emp1)
> invoke displayList::"add"(car1)
> invoke displayList::"add"(indPlace1)
> invoke displayList::"add"(car2)
> move displayList::"listSize" to noItems
> if noItems > 0
> set displayItem to displayList::"getfirst"
> invoke displayItem::"display"
> perform until exit
> set displayItem to displayList::"getnext"
> if displayItem not = null
> invoke displayItem::"display"
> else
> exit perform
> end-if
> end-perform
> end-if
> exit program.
>
> Java:
> {
> DLinkList displayList;
>
> displayList = new DLinkList();
> displayList.add(emp1);
> displayList.add(car1);
> displayList.add(indPlace1);
> displayList.add(car2);
> noItems = displayList.listSize();
> if (noItems > 0) {
> displayItem = displayList.getfirst();
> displayItem.display();
> while () {
> displayItem = displayList.getnext();
> if (displayItem != NULL)
> displayItem.display();
> else
> break;
> }
> }
> }
>
> Objective-C:
> {
> DLinkList *displayList;
>
> displayList = [[DLinkList alloc] init];
> [displayList add:emp1];
> [displayList add:car1];
> [displayList add:indPlace1];
> [displayList add:car2];
> noItems = [displayList listSize];
> if (noItems > 0) {
> displayItem = [displayList getfirst];
> [displayItem display];
> while () {
> displayItem = [displayList getnext];
> if (displayItem != NULL)
> [displayItem display];
> else
> break;
> }
> }
> }
>
> Ruby:
> begin
> displayList = DLinkList.new
> displayList.add emp1
> displayList.add car1
> displayList.add indPlace1
> displayList.add car2
> noItems = displayList.listSize
> if noItems > 0
> displayItem = displayList.getFirst
> displayItem.display
> while true
> displayItem = displayList.getnext
> if displayItem
> displayItem.display
> else
> break
> end
> end
> end
> end
>
> "Frank's programming language":
> begin
> displayList := new DLinkList$
> [add emp1 to displayList]
> [add car1 to displayList]
> [add indPlace1 to displayList]
> [add car2 to displayList]
> noItems := displayList.listSize #(listSize is a property)#
> test noItems
> when gt 0
> displayItem := [getfirst displayList]
> [display displayItem];
> loop until exit
> displayItem = [getnext displayList]
> test displayItem
> when true
> [display displayItem]
> when false
> exit
> end<