On 25/09/2022 1:38 am, Bernd Oppolzer wrote:
The link to the video once again, because it was damaged by my eMail
client:
https://www.youtube.com/watch?v=IRTfhkiAqPw
Brian's videos are entertaining but his modus operandi is to take some
really bad code and then demonstrate how to refactor it using structured
programming. That may be convincing for folks that haven't used OO
languages but it's not for those that have. For example, his Java
command line parser is just bogus. Modern Java APIs (Java 1.5 +) use
annotations https://rvesse.github.io/airline/. Sure beats the hell out
of using getopt() in C.
HTH, kind regards
Bernd
Am 24.09.2022 um 19:12 schrieb Bernd Oppolzer:
Sorry for this topic drift, but this is interesting, anyway.
IMO, there are some really interesting use cases for such techniques,
for example
- sort routines where the comparison functions is generic, that is, a
function pointer
- same for search routines
- same for dynamic arrays of structs, indexed by key structs (I
implemented one, using AVL trees)
- a function package which prints or plots other functions
and so on.
In C, I did this using function pointers.
In Pascal, I can pass procedures or functions to procedure parameters
(procedures passed as
parameters to other procedures), which is virtually the same as
function pointers, but IMO
looks nicer. This is from the 1960s. I never considered this as being
OO, but in fact,
all the above things, although implemented in procedural languages
like C and Pascal,
are TEMPLATES.
If I really feel the need for such solutions (which I do sometimes),
I anyway like to stick
with procedural languages like, see above, Pascal and C, and I don't
use C++;
all the OO overhead makes me feel bad.
See this video:
Object-Oriented Programming is Embarrassing: 4 Short Examples -
YouTube <https://www.youtube.com/watch?v=IRTfhkiAqPw>
Kind regards
Bernd
Am 24.09.2022 um 18:51 schrieb Tony Harminc:
On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
0000042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
Far worse is the attempt to use OO techniques in non-OO languages.
"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.
Years ago I inherited a good size (~200 kLOC) assembler program that
had a
lot of old-fashioned techniques. But at the same time it had a
structured
macro scheme that was quite advanced, and included an internal
subroutine
call/stack mechanism. I updated the macros to generate symbols for the
assembler xref/ADATA about what was being called and from where, and
only
then discovered that the subcall macro had the option to load the
"function
pointer" (address) from a field in a "struct" (DSECT), thus making a
complete static xref of calls impossible. The best that could be done
(other than a complete control/data flow analysis) was to also log what
updated those pointers in the struct, but correlating them was almost
impossible.
Bad code can be written using just about any programming paradigm in
any
language.
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
