Re: invoking a method
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 4 Dec 2006 01:23:36 +1300
"Paul Robinson" <paul@xxxxxxxxxxxxxxxx> wrote in message
news:6bidnRNZEcyKzu_YnZ2dnUVZ_tSdnZ2d@xxxxxxxxxxxxx
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
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.)
I've come to believe it would be more "natural" if the method name was
specified first.
I would find that completely UNnatural... It is indeed a diverse world we
inhabit :-)
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.
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.
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.
We'll never know...:-)
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.
.
- Follow-Ups:
- Re: invoking a method
- From: Richard
- Re: invoking a method
- From: P. Raulerson
- Re: invoking a method
- References:
- invoking a method
- From: Frank Swarbrick
- Re: invoking a method
- From: Paul Robinson
- invoking a method
- Prev by Date: Re: invoking a method
- Next by Date: Re: cmsg cancel <pduch.24120$J32.21092@read1.cgocable.net>
- Previous by thread: Re: invoking a method
- Next by thread: Re: invoking a method
- Index(es):
Relevant Pages
|
