"Serguei" <[EMAIL PROTECTED]> wrote on 14 Feb 2006 09:08:31 -0000
> [Emulating OOP] is the only reason one should choose to do
> something of the kind you have described - the reason to mimic
> some of the elements of OOP (this is also why one might to use
> COMMONs as well - this is the only reason for COMMON, emulating
> elements of OOP, not passing parameters around).
While the examples provided earlier used constants for the subroutine
names, it was suggested that these might be variable. Even so, having a
standard interface routine is a widely accepted programming method. It's
call Data Driven design. SB+ uses this extensively, and you will find
innumerable CALL SB.PROCESS("Process") statements in SB+ Basic programs.
The best data driven example I saw earlier had to do with tax calculations:
different states and countries have different methods of calculating taxes.
Specifying the appropriate tax calculation routine based on a data value
makes sense, since each tax calculation would be isolated to a separate
routine, as opposed to a monstrous octopus of code having to test each of
several options in order to calculate the proper tax.
Additionally, there are many valid uses for COMMON blocks that have nothing
to do with OOP. There have been numerous discussions on this list
regarding the overhead of opening files, and having a common block of file
variables available in each routine makes more sense than having each
routine open the files it needs. Common blocks are also useful for
providing environment parameters to each routine. Again, SB+ has an
extensive COMMON just for this purpose.
Whenever I see absolutes like "always", "never", and "only" in
recommendations, it tends to raise an alarm that some alternatives may have
been overlooked.
--Tom Pellitieri
Toledo, Ohio
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
