Binding alternatives was Re: invoking a method

On Wed, 6 Dec 2006 00:07:43 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>
>"Richard" <riplin@Azonic.co.nz> wrote in message
>news:1165280877.871260.111520@73g2000cwn.googlegroups.com... 
>
>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...)
>
The issue of bind time is interesting.  Binding at compile time has
the advantage of elimination of intermodule overhead which can be
significant.  Interestingly, IBM z series COBOL now binds all system
subroutines at run time (those called implicitly by verbs such as READ
or SEARCH ALL as opposed to those by CALL statement) unless the called
module is included in the compile code as a nested program.  The z/OS
environment has a higher overhead for execution time binding than many
others. The advantage of compile time binding is that code is frozen
at that point which is also the divantage.   Binding of separately
compiled modules also eliminates both first time overhead and
subsequent overhead to a lesser extent but does not have the advantage
of the compiler being able to optimize code and discard unreferenced
code.  The binding mechanism presumably can be smart enough to match
caller/invoker and called/invoked expectations on entities being
exchanged.  Binding at execution time means that not only is a
separate invocation made of the loading mechanism but that all
parameter passing validity checking (if any) is done at execution
time.  Even if no validity checking for matching parameter
descriptions is done there is a measurable overhead for both first
call and subsequent calls on an IBM z series system.  This overhead is
not great enough for most batch work to cause an installation to
change the batch compile option from DYNAM (bind all called modules at
execution time) to RES (bind all called modules at bind or link-edit
time).  I would assume that the name mangling done by C/C++ allows a
simple and direct way for the caller to assure that the parameter
passing is correct and that the descriptions match.

In cases where performance matters, compile time binding is best.  It
also allows for the most validity checking.  Depending on the in-line
code necessary for run-time calls, it actually may save executable
load module size.  This is especially true where multiple modules can
be included through a standard copy mechanism with all unused code
being eliminated from compilation.  Depending on how a shop wants to
handle change, compile time binding offers the assurance that
subroutine/invoked module execution will change only after a
re-compile.  Run time binding allows a caller/invoker to pick up
changed behaviour, current fixes etc. without a re-compile.

My personal view is that far more thought has to be given to what the
effects of changes are than shops do.  They can be paranoid about
source code and load module changes yet let script changes (REXX,
Perl, C-shell, JCL, utility control records) go through with minimal
testing.  Change of data control tables also may be loosely checked.
The idea that control tables specifying things like tax rules, sales
discounts by type of sale, etc. can be made external to programs and
thus open to the appropriate group within an organization for control
is good.  What is not good is that these changes many times are not
adequately tested and can have interesting unintended consequences.
Thus allowing changes in behaviour in dynamically invoked modules is
no more dangerous than allowing changes in behaviour caused
non-program changes.  Both have to be managed.  Both may have to be
better bounded by doing such things as adding an effective date for
the changed behaviour.
>
> 
>
>Not in the environments I 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 ) 
>
>So exactly how does the method store and reference them? (I am using
>'properties' loosely here to include local variables or any data storage, i
n
>line with the concept I previously outlined ('Methods' are behaviours,
>'Properties' are data.) A pointer to a parameter or a parameter which is, i
n
>fact a pointer, is still 'data' that is used by the method.)
>
> 
>With COM these 'overheads' are in the Class wrapping and cost me nothing. M
y
>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 begi
n
>to spell out here. That's just the way I do it. As it works very well for m
e
>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 appreciat
e
>your arguments for not doing so...)
>
>Pete.
>