Virtual functions

[amorem...@gmail.com]

What are virtual functions? Could you please give an example?

[Christian Gollwitzer]

Am 16.03.18 um 06:05 schrieb amorem...@gmail.com:

> What are virtual functions? Could you please give an example?

A quick Google search turns up many pages with examples, including:

https://www.geeksforgeeks.org/virtual-function-cpp/
https://en.wikipedia.org/wiki/Virtual_function
http://www.cplusplus.com/doc/tutorial/polymorphism/

Christian

[red floyd]

On 03/15/2018 10:05 PM, amorem...@gmail.com wrote:
> What are virtual functions? Could you please give an example?
>

What textbook are you using that does not discuss them?

[bitrex]

On 03/16/2018 01:05 AM, amorem...@gmail.com wrote:
> What are virtual functions? Could you please give an example?
>

It's a function that only exists "virtually", like you have an idea for
a function that does something cool but it's the weekend and you don't
really feel much like writing code so currently you can only kinda
imagine it in your head

[amorem...@gmail.com]

Thank you so much. These did help me develop a clearer theory in my head.

[amorem...@gmail.com]

It's not the textbook does not discuss virtual functions. I just don't seem to be able to apply it in practical code.

[amorem...@gmail.com]

Thank you so much.

[James Kuyper]

What happens when you try to apply it in practical code? A specific
example would be helpful.

[Richard]

[Please do not mail me a copy of your followup]

amorem...@gmail.com spake the secret code
<9a0aaa70-f875-42e5...@googlegroups.com> thusly:

>It's not the textbook does not discuss virtual functions. I just don't
>seem to be able to apply it in practical code.

I'd summarize it as: virtual functions are useful when you have
generic operations that apply to categories of objects, but each
object within the category has slightly different ways of
accomplishing the operation.

The classic example is a GUI framework containing a class hierarchy of
widgets. In other words there is some base class "Widget" and the
individual widget types derive from that:

class Widget { /* .... */ };
class CheckBox : public Widget { /* ... */ };
class ListBox : public Widget { /* ... */ };
class TextBox : public Widget { /* ... */ };

We want to draw widgets on the screen. Each widget does this slightly
differently:

- Checkbox widgets draw a little box with or without the check mark to
indicate the checked or unchecked state
- List box widgets draw the list of items. Selected items are drawn
with some sort of visual highlight to indicate the selection.
- Text box widgets draw the editable area in a distinct manner to
differentiate it from the background and render any text inside that
area.
- and so-on

From the perspective of a client of a widget, we don't care how it
draws. Most of the time, we don't even care what kind of widget it
is; we just want it to draw itself on the screen. So we typically
hold the widgets on a dialog as pointers to the base and invoke
the draw operation on the widgets through a pointer to the base:

class Widget {
public:
virtual void draw() = 0; // might not be abstract, depends on the design
/* .... */
};
class CheckBox : public Widget {
public:
void draw() override { /* draw CheckBox */ }
/* ... */
};
etc.

class Dialog
{
public:
// here, a Dialog is just holds a bag of Widgets. It is not a
// Widget itself (this is a design choice), so its draw is not
// virtual.
void draw()
{
for (auto w : m_widgets)
{
w->draw();
}
}

/* ... */

private:
std::vector<std::unique_ptr<Widget>> m_widgets;
};

--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Jorgen Grahn]

I have trouble applying them in practical code, too, after 15 years
with C++. In the sense that run-time polymorphism (a better word for
the language feature as a whole, IMHO) is not needed in every program.

For me, that tends to happen when:
- My design has several classes which are similar, from some
point of view.
- I want to do similar things with a mix of objects from
these classes.
- And, I can see that I cannot know until runtime which class
I'm processing.

(If this doesn't make sense, see other, longer responses by others.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[woodb...@gmail.com]

::boost::base_collection<Widget>
would probably be better:
http://www.boost.org/doc/libs/1_66_0/doc/html/poly_collection.html

. Beyond the performance advantages described there, there
are also serialization-related performance advantages over
a vector of pointers. To the best of my knowledge, the C++
Middleware Writer is the only library to have serialization
support for boost::base_collection.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[Scott Lurndal]

Jorgen Grahn <grahn...@snipabacken.se> writes:
>On Fri, 2018-03-23, amorem...@gmail.com wrote:
>> On Friday, March 16, 2018 at 9:28:45 PM UTC+5:45, red floyd wrote:
>>> On 03/15/2018 10:05 PM, amorem...@gmail.com wrote:
>>> > What are virtual functions? Could you please give an example?
>>> >
>>>
>>> What textbook are you using that does not discuss them?
>>
>> It's not the textbook does not discuss virtual functions. I just
>> don't seem to be able to apply it in practical code.
>
>I have trouble applying them in practical code, too, after 15 years
>with C++. In the sense that run-time polymorphism (a better word for
>the language feature as a whole, IMHO) is not needed in every program.

I use virtual functions in most of my code.

As a concrete example, consider a computer system simulation (used to
experiment with different architectural changes prior to implementation
in silicon).

This simulation models several different I/O controllers, yet all the I/O
controllers have a common interface to the central processor. Each I/O
controller is an instance of a Data Link Processor (DLP). It makes
sense, then, to model the interface as an abstract class (c_dlp) which
provides virtual functions that are common to all controllers:

class c_dlp {
...
public:
c_dlp(ulong, ulong, c_logger *);
virtual ~c_dlp(void);

/**
* Cancel all outstanding IOCB's. The implementation of this
* method must discontinue all outstanding operations, producing
* result descriptors for each oustanding operation.
*
* The cancel MLI opcode value is 0xc.
*
* @param iocb The IOCB for the cancel operation.
*/
virtual bool cancel(c_iocb *iocb) = 0;

/**
* Echo operation. Write data to DLP and immediately read back into
* buffer following written data. Diagnostic use.
*
* The echo MLI opcode value is 0x1.
*
* @param iocb The IOCB for the echo operation.

*/
virtual bool echo(c_iocb *iocb) = 0;

/**
* Test the DLP, or test an individual Unit on the DLP. The
* test operation variants are DLP specific.
*
* The test MLI opcode value is 0x2.
*
* @param iocb The IOCB for the test operation.
*/
virtual bool test(c_iocb *iocb) = 0;

/**
* Read data from the DLP. The read operation is DLP specific.
*
* The read MLI opcode value is 0x8.
*
* @param iocb The IOCB for the read operation.
*/
virtual bool read(c_iocb *iocb) = 0;

/**
* Write data to the DLP. The write operation is DLP specific.
*
* The write MLI opcode value is 0x4.
*
* @param iocb The IOCB for the write operation.
*/
virtual bool write(c_iocb *iocb) = 0;

/**
* Retrieve a text string describing the DLP.
*/
virtual const char *get_name(void) = 0;

....
};

Each device model then implements (in the Java sense) that interface.

io/dlps/buffered_printer_dlp.h:class c_buffered_printer_dlp : public c_dlp {
io/dlps/fips_tape_dlp.h:class c_fips_tape_dlp : public c_dlp {
io/dlps/ht_dcp_dlp.h:class c_ht_dcp_dlp : public c_dlp {
io/dlps/ht_dpdc_dlp.h:class c_ht_dpdc_dlp : public c_disk_dlp {
io/dlps/isc_dlp.h:class c_isc_dlp : public c_dlp, public c_port_transport {
io/dlps/odt_dlp.h:class c_odt_dlp : public c_dlp,
io/dlps/qwik_dlp.h:class c_qwik_dlp : public c_dlp {
io/dlps/ssp_dlp.h:class c_ssp_dlp : public c_dlp, public c_ssp_client {
io/dlps/telcom_dlp.h: public c_dlp,
io/dlps/train_printer_dlp.h:class c_train_printer_dlp : public c_dlp {
io/dlps/uniline_dlp.h:class c_uniline_dlp : public c_dlp,

The I/O controller model then simply uses the c_dlp interface to access
all the device models and never sees the actual device model class
name.

e.g.

c_dlp *dlpp = get_dlp(channel);
if (dlpp != NULL) {
if (!dlpp->read(iocbp)) {
/* Operation Failed */
set_coms(HIGH);
} else {
set_coms(EQUAL);
}
}

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnpbbupl.e...@frailea.sa.invalid> thusly:

>I have trouble applying them in practical code, too, after 15 years
>with C++. In the sense that run-time polymorphism (a better word for
>the language feature as a whole, IMHO) is not needed in every program.

I found that when practicing pure TDD, pure abstract interfaces show
up more often in my code. That means virtual functions in C++. There
are other design benefits to using pure abstract interfaces, but when
testing behavioral classes (e.g. not simple value types like std::string)
you tend to have one class collaborating with another and you want to
mock out the collaborators. This is trivial if the collaboration is
done through a pure virtual interface.

A modern compiler may even notice that this "virtual" function is only
ever called on one particular class implementation and eliminate the
indirection through the vtable.

[Jorgen Grahn]

On Mon, 2018-03-26, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnpbbupl.e...@frailea.sa.invalid> thusly:
>
>>I have trouble applying them in practical code, too, after 15 years
>>with C++. In the sense that run-time polymorphism (a better word for
>>the language feature as a whole, IMHO) is not needed in every program.
>
> I found that when practicing pure TDD, pure abstract interfaces show
> up more often in my code. That means virtual functions in C++.

Yes. That's one of the issues I have with TDD in C++: I have to make
my code more complex to use it.

> There are other design benefits to using pure abstract interfaces,
> but when testing behavioral classes (e.g. not simple value types
> like std::string) you tend to have one class collaborating with
> another and you want to mock out the collaborators. This is trivial
> if the collaboration is done through a pure virtual interface.
>
> A modern compiler may even notice that this "virtual" function is only
> ever called on one particular class implementation and eliminate the
> indirection through the vtable.

That's good, but the problem (for me personally) is I find it harder
to handle code when there's a lot of inheritance. Except of course
when it replaces manual "if (type_a) do_a() else if (type_b) do_b()"
code; then it's the natural choice for me too.

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code

<slrnpbijf6.e...@frailea.sa.invalid> thusly:

>On Mon, 2018-03-26, Richard wrote:
>> I found that when practicing pure TDD, pure abstract interfaces show
>> up more often in my code. That means virtual functions in C++.
>
>Yes. That's one of the issues I have with TDD in C++: I have to make
>my code more complex to use it.

How does it become more complex?

I have found just the opposite. My code gets simpler because I end up
with good abstractions, highly cohesive classes and loosely coupled
deisgns. All of those things make for code that is simpler to
understand.

[Ian Collins]

On 03/27/2018 08:45 AM, Jorgen Grahn wrote:
> On Mon, 2018-03-26, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
>> <slrnpbbupl.e...@frailea.sa.invalid> thusly:
>>
>>> I have trouble applying them in practical code, too, after 15 years
>>> with C++. In the sense that run-time polymorphism (a better word for
>>> the language feature as a whole, IMHO) is not needed in every program.
>>
>> I found that when practicing pure TDD, pure abstract interfaces show
>> up more often in my code. That means virtual functions in C++.
>
> Yes. That's one of the issues I have with TDD in C++: I have to make
> my code more complex to use it.

How so? Is the design more complex, or do you just end up with more,
smaller pieces?

--
Ian

[Öö Tiib]

TDD does not cause shorter or less complex functions or
more interfaces. If people want they do like that for other
reasons but TDD does not push towards it.
TDD causes less function parameters, less and flatter
inheritance trees, more methods public and less global state.

[Cholo Lennon]

On 26/03/18 17:20, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnpbijf6.e...@frailea.sa.invalid> thusly:
>
>> On Mon, 2018-03-26, Richard wrote:
>>> I found that when practicing pure TDD, pure abstract interfaces show
>>> up more often in my code. That means virtual functions in C++.
>>
>> Yes. That's one of the issues I have with TDD in C++: I have to make
>> my code more complex to use it.
>
> How does it become more complex?
>

Well, if you need to apply, for example, dependency injection in order
to test your code, the complexity increases.

> I have found just the opposite. My code gets simpler because I end up
> with good abstractions, highly cohesive classes and loosely coupled
> deisgns. All of those things make for code that is simpler to
> understand.

Yes, in the end maybe you have better abstractions, but the code
complexity is higher (more clases, interfaces, etc). Don't get me wrong,
unit testing is an integral part of my daily work, it pay off. I really
believe in testing (which is not the same as TDD, we've already
discussed this in other thread in the past).

Regards


--
Cholo Lennon
Bs.As.
ARG

[Jorgen Grahn]

Very late reply; I partly blame Easter.

I'd put it like this: I end up with explicit flexibility that's not
used in runtime. Like dependency injection, where I end up with
pointers to abstract types passed in the constructors, where plain,
concrete members would have sufficed.

There may be ways around this, or a better way to reason about such
code, but I haven't found it yet. (But I know you're happy with it.)

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code

<slrnpc7492.e...@frailea.sa.invalid> thusly:

>I'd put it like this: I end up with explicit flexibility that's not
>used in runtime. Like dependency injection, where I end up with
>pointers to abstract types passed in the constructors, where plain,
>concrete members would have sufficed.

Your testing alternative is link-time substitution. It's a giant
PITA, but you can do it if you really dislike abstract interface
injection.

[Jorgen Grahn]

On Tue, 2018-04-03, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnpc7492.e...@frailea.sa.invalid> thusly:
>
>>I'd put it like this: I end up with explicit flexibility that's not
>>used in runtime. Like dependency injection, where I end up with
>>pointers to abstract types passed in the constructors, where plain,
>>concrete members would have sufficed.
>
> Your testing alternative is link-time substitution. It's a giant
> PITA, but you can do it if you really dislike abstract interface
> injection.

That's an alternative I'd like to investigate. At a previous
workplace we briefly considered it, but didn't know how to go about
it. Noone wanted to link test code into the product by accident, and
so on.

Then we introduced testability by dependency injection, and noone was
really happy with the result.

(And then we introduced component tests, since we had really well-
defined runtime components, and these were the ones that ended up
catching the bugs.)

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code

<slrnpc9l7k.e...@frailea.sa.invalid> thusly:

>That's an alternative I'd like to investigate. At a previous
>workplace we briefly considered it, but didn't know how to go about
>it. Noone wanted to link test code into the product by accident, and
>so on.

"Test Driven Development for Embedded C" by James Grenning
<https://amzn.to/2EjQaBf> does a good job of explaining how to use link
time substitution.

It's also covered by Michael Feathers in "Working Effectively with
Legacy Code" <https://amzn.to/2q5GC8F>

[Tim Rentsch]

I find these comments about virtual functions and polymorphism[*]
interesting. I started on C++ quite a while ago, but even so had
been using polymorphic messaging for about a decade before that.
For me class hierarchies and (what C++ calls) virtual functions
pretty much pop up naturally, without my having to seek them out
especially. (That is not to say they don't benefit from being
revised, of course they do.) I speculate that starting with C++
as a first "OOP" language makes it harder to acquire the OOP
mindset. No evidence, mind, besides this one data point, but
it is still an interesting conjecture.

[*] The programming language community usually refers to things
like virtual functions as just plain polymorphism, ie, without
any "run-time" modifier. Other kinds of polymorphic constructs,
eg overloaded functions or templates, are usually referred to as
"ad hoc polymorphism". (This is assuming the terminology hasn't
changed since I was active in the field, which it may very well
have.)

[Alf P. Steinbach]

On 05.04.2018 07:42, Tim Rentsch wrote:
>
> [*] The programming language community usually refers to things
> like virtual functions as just plain polymorphism, ie, without
> any "run-time" modifier. Other kinds of polymorphic constructs,
> eg overloaded functions or templates, are usually referred to as
> "ad hoc polymorphism". (This is assuming the terminology hasn't
> changed since I was active in the field, which it may very well
> have.)

It all depends on the context.

The C++ standard defines polymorphic as a formal term (in C++17 §1.8/1
and §10.3/1), for a class meaning that it has one or more virtual
functions. That's what's meant by "polymorphic class" or "polymorphic
object".

The more general meaning of polymorphism is that the same source code
can have different detailed effects depending on the types involved in
an invocation/instantiation of it.

For that C++ supports polymorphism resolved at compile time, called
static polymorphism, and polymorphism resolved at run time, called
dynamic polymorhism.

The ¹Wikipedia article about polymorphism supports your view of the
terminology, but seems to be at odds with most every article about it
for programmers. From that I conclude that the term "ad hoc
polymorphism" is almost exclusively used in academia. I believe that
academia is by nature very conservative, often failing to adjust.


Cheers & hth.,

- Alf


¹ https://en.wikipedia.org/wiki/Polymorphism_(computer_science)

[Mr Flibble]

On 05/04/2018 15:46, Alf P. Steinbach wrote:
> On 05.04.2018 07:42, Tim Rentsch wrote:
>>
>> [*] The programming language community usually refers to things
>> like virtual functions as just plain polymorphism, ie, without
>> any "run-time" modifier.  Other kinds of polymorphic constructs,
>> eg overloaded functions or templates, are usually referred to as
>> "ad hoc polymorphism".  (This is assuming the terminology hasn't
>> changed since I was active in the field, which it may very well
>> have.)
>
> It all depends on the context.
>
> The C++ standard defines polymorphic as a formal term (in C++17 §1.8/1
> and §10.3/1), for a class meaning that it has one or more virtual
> functions. That's what's meant by "polymorphic class" or "polymorphic
> object".
>
> The more general meaning of polymorphism is that the same source code
> can have different detailed effects depending on the types involved in
> an invocation/instantiation of it.
>
> For that C++ supports polymorphism resolved at compile time, called
> static polymorphism, and polymorphism resolved at run time, called
> dynamic polymorhism.

Types cease to exist after compilation: it is all just text in the text
segment: theoretically a compiler compiling a C++ program utilizing
vtables can generate the same machine code as a totally different
language compiler which has no such concept as vtables and virtual
functions which means that "runtime polymorphism" is a nonsense as it
doesn't actually exist.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

</troll>

[Richard]

[Please do not mail me a copy of your followup]

Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
<kfnpo3e...@x-alumni2.alumni.caltech.edu> thusly:

>[...] I speculate that starting with C++

>as a first "OOP" language makes it harder to acquire the OOP
>mindset. No evidence, mind, besides this one data point, but
>it is still an interesting conjecture.

Anecdotally, this is my experience as well. My first OOP language was
C++ and it wasn't until I started practicing TDD that I felt the
benefit of SOLID design principles.

>[*] The programming language community usually refers to things
>like virtual functions as just plain polymorphism, ie, without
>any "run-time" modifier. Other kinds of polymorphic constructs,
>eg overloaded functions or templates, are usually referred to as
>"ad hoc polymorphism". (This is assuming the terminology hasn't
>changed since I was active in the field, which it may very well
>have.)

It's common to refer to template genericity as static polymorphism in
C++ and the typical virtual method style polymorphism as dynamic or
run-time polymorphism.

[Mr Flibble]

On 05/04/2018 18:21, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
> <kfnpo3e...@x-alumni2.alumni.caltech.edu> thusly:
>
>> [...] I speculate that starting with C++
>> as a first "OOP" language makes it harder to acquire the OOP
>> mindset. No evidence, mind, besides this one data point, but
>> it is still an interesting conjecture.
>
> Anecdotally, this is my experience as well. My first OOP language was
> C++ and it wasn't until I started practicing TDD that I felt the
> benefit of SOLID design principles.

TDD is cancer. Designing software by fixing failing tests is no way to
design software.

[Paavo Helde]

On 5.04.2018 20:28, Mr Flibble wrote:
>
> TDD is cancer. Designing software by fixing failing tests is no way to
> design software.

Well, evolution has done exactly that and designed things like me and
you;-) Not sure yet if this is a total failure or not. Of course, things
like giraffe's laryngeal nerve
("https://rationalwiki.org/wiki/Laryngeal_nerve") are not so neat, but
they are there in the codebase and not going anywhere.

Also beware that our new neural net overlords are being designed by a
similar trial-and-error approach (although the process is called
"training" by some reason), so you should better get used to the idea
before they find you dispensable.

Cheers
Paavo

[Ian Collins]

On 04/06/2018 05:28 AM, Mr Flibble wrote:
> On 05/04/2018 18:21, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
>> <kfnpo3e...@x-alumni2.alumni.caltech.edu> thusly:
>>
>>> [...] I speculate that starting with C++
>>> as a first "OOP" language makes it harder to acquire the OOP
>>> mindset. No evidence, mind, besides this one data point, but
>>> it is still an interesting conjecture.
>>
>> Anecdotally, this is my experience as well. My first OOP language was
>> C++ and it wasn't until I started practicing TDD that I felt the
>> benefit of SOLID design principles.
>
> TDD is cancer. Designing software by fixing failing tests is no way to
> design software.

Maybe, so it's a good thing that TDD isn't designing software by fixing
failing tests.

--
Ian

[Richard]

[Please do not mail me a copy of your followup]

>On 5.04.2018 20:28, Mr Flibble wrote:
>>
>> TDD is cancer. Designing software by fixing failing tests is no way to
>> design software.

I knew there was a reason you were in my KILL file...

[Mr Flibble]

It is tho.

[Chris M. Thomasson]

On 4/5/2018 10:28 AM, Mr Flibble wrote:
> On 05/04/2018 18:21, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
>> <kfnpo3e...@x-alumni2.alumni.caltech.edu> thusly:
>>
>>> [...]  I speculate that starting with C++
>>> as a first "OOP" language makes it harder to acquire the OOP
>>> mindset.  No evidence, mind, besides this one data point, but
>>> it is still an interesting conjecture.
>>
>> Anecdotally, this is my experience as well.  My first OOP language was
>> C++ and it wasn't until I started practicing TDD that I felt the
>> benefit of SOLID design principles.
>
> TDD is cancer. Designing software by fixing failing tests is no way to
> design software.

Imvho, fixing a failing test can be beneficial. ;^)

[Mr Flibble]

I have no problem with unit tests which are great for finding
regressions but I do have a problem with designing software by fixing
smallest testable units (i.e. functions) which is what TDD is all about.
Unit tests should drive continuous integration NOT design.

[Ian Collins]

On 04/06/2018 07:46 AM, Mr Flibble wrote:
> On 05/04/2018 20:24, Ian Collins wrote:
>> On 04/06/2018 05:28 AM, Mr Flibble wrote:
>>> On 05/04/2018 18:21, Richard wrote:
>>>> [Please do not mail me a copy of your followup]
>>>>
>>>> Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
>>>> <kfnpo3e...@x-alumni2.alumni.caltech.edu> thusly:
>>>>
>>>>> [...]  I speculate that starting with C++
>>>>> as a first "OOP" language makes it harder to acquire the OOP
>>>>> mindset.  No evidence, mind, besides this one data point, but
>>>>> it is still an interesting conjecture.
>>>>
>>>> Anecdotally, this is my experience as well.  My first OOP language was
>>>> C++ and it wasn't until I started practicing TDD that I felt the
>>>> benefit of SOLID design principles.
>>>
>>> TDD is cancer. Designing software by fixing failing tests is no way to
>>> design software.
>>
>> Maybe, so it's a good thing that TDD isn't designing software by fixing
>> failing tests.
>
> It is tho.

Tests don't design themselves...

--
Ian.

[Chris M. Thomasson]

On 4/5/2018 12:55 PM, Mr Flibble wrote:
> On 05/04/2018 20:51, Chris M. Thomasson wrote:
>> On 4/5/2018 10:28 AM, Mr Flibble wrote:
>>> On 05/04/2018 18:21, Richard wrote:
>>>> [Please do not mail me a copy of your followup]
>>>>
>>>> Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
>>>> <kfnpo3e...@x-alumni2.alumni.caltech.edu> thusly:
>>>>
>>>>> [...]  I speculate that starting with C++
>>>>> as a first "OOP" language makes it harder to acquire the OOP
>>>>> mindset.  No evidence, mind, besides this one data point, but
>>>>> it is still an interesting conjecture.
>>>>
>>>> Anecdotally, this is my experience as well.  My first OOP language was
>>>> C++ and it wasn't until I started practicing TDD that I felt the
>>>> benefit of SOLID design principles.
>>>
>>> TDD is cancer. Designing software by fixing failing tests is no way
>>> to design software.
>>
>> Imvho, fixing a failing test can be beneficial. ;^)
>
> I have no problem with unit tests which are great for finding
> regressions but I do have a problem with designing software by fixing
> smallest testable units (i.e. functions) which is what TDD is all about.
>  Unit tests should drive continuous integration NOT design.

Humm... That is difficult for me to disagree with. The design is the
design. The tests should aid in making sure the design is working as
expected.

[Ian Collins]

If you can sider the test to be part of the design (the detailed design
if you like), it is logical to write them before the code. So just as
you start out with a requirement the code does not meet, you start out
with a test its does not pass. Once it meets the requirement, the test
passes.

--
Ian.

[Vir Campestris]

On 05/04/2018 18:01, Mr Flibble wrote:
> Types cease to exist after compilation: it is all just text in the text
> segment: theoretically a compiler compiling a C++ program utilizing
> vtables can generate the same machine code as a totally different
> language compiler which has no such concept as vtables and virtual
> functions which means that "runtime polymorphism" is a nonsense as it
> doesn't actually exist.

After compilation all those nice high level abstractions have
disappeared in a cloud of assembler (or not even that, depending on your
compiler). And yet, runtime polymorphism does exist.

A C program could choose to put a function pointer into a struct, and
have the calling program use the function pointer. That's runtime
polymorphism. You could do it in assembler if you were that perverse. In
fact I have a vague memory of doing just that for an API many MANY years
ago, back when assembler efficiency mattered more than developer man hours.

(If there were lots of these you might want to put all the pointers in a
table shared between similar structs. You could call it a vtable.)

Andy

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<finer8...@mid.individual.net> thusly:

>If you can sider the test to be part of the design (the detailed design
>if you like), it is logical to write them before the code. So just as
>you start out with a requirement the code does not meet, you start out
>with a test its does not pass. Once it meets the requirement, the test
>passes.

This.

Maybe people would understand this better if it were called Design
Driven Development instead of Test Driven Development. The main
activity is a design activity, not a testing activity.

[Mr Flibble]

On 05/04/2018 22:43, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <finer8...@mid.individual.net> thusly:
>
>> If you can sider the test to be part of the design (the detailed design
>> if you like), it is logical to write them before the code. So just as
>> you start out with a requirement the code does not meet, you start out
>> with a test its does not pass. Once it meets the requirement, the test
>> passes.
>
> This.
>
> Maybe people would understand this better if it were called Design
> Driven Development instead of Test Driven Development. The main
> activity is a design activity, not a testing activity.

Bullshit. TDD isn't design driven in the slightest.

[Mr Flibble]

I suggest you scroll to the end of my post; past the .sig.

[woodb...@gmail.com]

On Thursday, April 5, 2018 at 4:47:54 PM UTC-5, Mr Flibble wrote:

TGIT -- Thank G-d it's Thursday.

[Ian Collins]

On 04/06/2018 12:47 PM, woodb...@gmail.com wrote:
> On Thursday, April 5, 2018 at 4:47:54 PM UTC-5, Mr Flibble wrote:
>
> TGIT -- Thank G-d it's Thursday.

TGIF

Its Friday here...

--
Ian.

[Ian Collins]

On 04/06/2018 09:47 AM, Mr Flibble wrote:
> On 05/04/2018 22:43, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Ian Collins <ian-...@hotmail.com> spake the secret code
>> <finer8...@mid.individual.net> thusly:
>>
>>> If you can sider the test to be part of the design (the detailed design
>>> if you like), it is logical to write them before the code. So just as
>>> you start out with a requirement the code does not meet, you start out
>>> with a test its does not pass. Once it meets the requirement, the test
>>> passes.
>>
>> This.
>>
>> Maybe people would understand this better if it were called Design
>> Driven Development instead of Test Driven Development. The main
>> activity is a design activity, not a testing activity.
>
> Bullshit. TDD isn't design driven in the slightest.

It isn't? That's news to me.

That makes me wonder whether I am a chimp attempting Shakespeare or a
programmer designing an application. I'll let you know which once I
stop typing.

--
Ian

[Mr Flibble]

The fact that you describe yourself as a "programmer" speaks volumes.
Programmers are code monkeys who do not think about designing software
with enough rigour. Your designs will be toy at best and egregious at
worst.

I consider myself to be a programmer, an engineer and an architect all
wrapped into the title "software developer".

Here is a clue for you: TDD is the enemy of encapsulation. Can you work
out why?

[Cholo Lennon]

I wouldn't say that TDD per se is the enemy, a "testable" artifact is.



--
Cholo Lennon
Bs.As.
ARG

[Rick C. Hodgin]

On Friday, April 6, 2018 at 8:23:15 AM UTC-4, Mr Flibble wrote:
> The fact that you describe yourself as a "programmer"...

You will weep bitterly one day at the way you've treated people, Leigh.
You will cry your eyes out over the hate and hurt you've slung at God's
beautiful creations of people so carelessly. It will eat away at you
like nothing you've ever experienced.

--
Rick C. Hodgin

[Mr Flibble]

Speed of light mate.

[Rick C. Hodgin]

On Friday, April 6, 2018 at 10:53:39 AM UTC-4, Mr Flibble wrote:
> On 06/04/2018 15:46, Rick C. Hodgin wrote:
> > On Friday, April 6, 2018 at 8:23:15 AM UTC-4, Mr Flibble wrote:
> >> The fact that you describe yourself as a "programmer"...
> >
> > You will weep bitterly one day at the way you've treated people, Leigh.
> > You will cry your eyes out over the hate and hurt you've slung at God's
> > beautiful creations of people so carelessly. It will eat away at you
> > like nothing you've ever experienced.
>
> Speed of light mate.

You can repeat that statement as often as you like. It doesn't change
a single thing. It only exemplifies your stolidness in refusing to
accept the possibility that you might be wrong. You are asserting your
own personal belief that you're right ahead of the possibility that you
might be wrong. You refuse to accept God on the basis of something you
may be wrong about.

It is your own stubbornness toward purposeful ignorance that will send
your soul to Hell, Leigh. Nothing else will do it, because God has given
you every opportunity to be saved.

You've been warned multiple times, Leigh. There's more out there than
you think. And you will perish in eternal Hellfire if you refuse to
even consider it. Your eternity is at stake. Do not be flippant.

--
Rick C. Hodgin

PS -- I heard this once: A BOLD young man came up to a preacher and
said, "God doesn't exist." The preacher replies, "Do you know
everything, son?" "No." "Do you know half of everything?"
"No." "Well, for the sake of argument, let's say you do know
half of everything. Is it possible that God exists in the
other half you don't know?"

[Mr Flibble]

On 06/04/2018 16:07, Rick C. Hodgin wrote:
> On Friday, April 6, 2018 at 10:53:39 AM UTC-4, Mr Flibble wrote:
>> On 06/04/2018 15:46, Rick C. Hodgin wrote:
>>> On Friday, April 6, 2018 at 8:23:15 AM UTC-4, Mr Flibble wrote:
>>>> The fact that you describe yourself as a "programmer"...
>>>
>>> You will weep bitterly one day at the way you've treated people, Leigh.
>>> You will cry your eyes out over the hate and hurt you've slung at God's
>>> beautiful creations of people so carelessly. It will eat away at you
>>> like nothing you've ever experienced.
>>
>> Speed of light mate.
>
> You can repeat that statement as often as you like. It doesn't change
> a single thing. It only exemplifies your stolidness in refusing to
> accept the possibility that you might be wrong. You are asserting your
> own personal belief that you're right ahead of the possibility that you
> might be wrong. You refuse to accept God on the basis of something you
> may be wrong about.
>
> It is your own stubbornness toward purposeful ignorance that will send
> your soul to Hell, Leigh. Nothing else will do it, because God has given
> you every opportunity to be saved.
>
> You've been warned multiple times, Leigh. There's more out there than
> you think. And you will perish in eternal Hellfire if you refuse to
> even consider it. Your eternity is at stake. Do not be flippant.

In the trade we call this "projection"; i.e.:

You can repeat that statement as often as you like. It doesn't change
a single thing. It only exemplifies your stolidness in refusing to
accept the possibility that you might be wrong. You are asserting your
own personal belief that you're right ahead of the possibility that you

might be wrong. You refuse to accept God doesn't exist on the basis of

something you may be wrong about.

It is your own stubbornness toward purposeful ignorance that will have
you die in ignorance, Rick. Nothing else will do it, because we have
given you every opportunity to be educated.

You've been warned multiple times, Rick. There's more out there than
you think. And you will die in ignorance if you refuse to
even consider it. Your legacy is at stake. Do not be flippant.

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
> It only exemplifies your stolidness in refusing to
>accept the possibility that you might be wrong.

Do you accept the possiblity that you might be wrong?

[Mr Flibble]

Unfortunately Rick knows he isn't wrong because he is unable to accept
that his born again "experience" can be explained as an instance of
psychosis.

[Rick C. Hodgin]

I accept the fact that I was wrong for 35 years of my life. And
I, one day I was drawn in such a way that I can't describe it other
than to say I was drawn from within undeniably, and I came to a
place where I asked Jesus to forgive my sin, and I was changed.

That change blew my life away. Everything has been changed since
that day.

That is my testimony. That is my witness. You see it lived out
in my life. It's not because I read a book and then learned how
to live out that book's teaching. It's because I've been changed
and now that book makes sense to me.

It's the same story for everyone who is born again.

There are people who profess Christianity, who grew up in the
church, who have always attended Bible Study, Sunday School, both
Sunday services, and the occasional special services or revivals.
But, they've never met God. They are not born again. They are
just religious people.

To be born again is to be changed, and it is from within that
change that the proof of the truth exists.

Does an egg becoming a larva becoming a pupa, before going through
the metamorphosis into a butterfly know what it means to be a
butterfly? It can't. It's not a butterfly. People, knowing the
flesh only, cannot understand how something as certain as the proof
a born again person possesses can exist, because they do not yet
have the spirit which gives them the proof. Blind people cannot
walk into a room they've never been in before and know how to
navigate it safely. They don't have the eyes to see the path, so
they must feel their way around. But if they had eyes, they could
see to walk around that chair, avoid that table, turn past the
stool there, and voila! Straight through on the first try.

The spirit gives us knowledge that our flesh cannot know.

It's actually how God draws people to His Son in the first place.
It's an irresistible drawing when it comes. When a person seeks
the truth, and God knows this, he draws them from within to be able
to receive it. That drawing is spirit, and it moves their flesh in
ways they cannot understand. They'll actually say, "I don't know
why I walked up to the front of the church that day, but I did, and
there I asked Jesus to forgive me and got saved."

-----
I have been transformed through the regeneration of spiritual life
given me by Jesus when I asked forgiveness for my sin. I know where
I am going, and whose I am.

Had you asked me the day before this happened, I would've told you
it was an absolute impossibility for such a change to be possible,
because it wasn't something I could know in my flesh. It required
the new change. It required the augment to be able to even perceive
the changes which would take place.

Do not take my word for it. Go to a Bible-believing, Bible-studying
Christian church and ask to speak to born again saints of God, and
ask them to give you their testimony. Go to several churches un-
related to one another, and ask of many people. Inquire of dozens
of souls and correlate their testimonies and witnesses.

You will find the common theme among people who do not know each
other, have never met one another, have no reason to purport something
for any reason other than it's the truth of what happened to them.

--
Rick C. Hodgin

[Rick C. Hodgin]

On Friday, April 6, 2018 at 11:53:36 AM UTC-4, Rick C. Hodgin wrote:
> Do not take my word for it. Go to a Bible-believing, Bible-studying
> Christian church and ask to speak to born again saints of God, and
> ask them to give you their testimony. Go to several churches un-
> related to one another, and ask of many people. Inquire of dozens
> of souls and correlate their testimonies and witnesses.
>
> You will find the common theme among people who do not know each
> other, have never met one another, have no reason to purport something
> for any reason other than it's the truth of what happened to them.

One particular man at my church gave his testimony. He was not a
church fella. He got married to a woman who shared his non-beliefs.
They lived for many years that way. Drinking. Partying. Enjoying
their life to the fullest.

One day his wife got saved and began to change. He didn't. He kept
on as he had been, and had affairs, sought to please himself.

His wife had been ill a couple weeks and hadn't been to church, and
a deacon from the church stopped by to see how she was. The man saw
the deacon walking up the driveway and went to the door to give him
a piece of his mind, and to tell him to get off his property and to
stop pestering him and not come back. But the deacon asked him a
simple question, which led to another, which led to another. And
whereas that man went to the door fuming and ready to all but kick
the person literally off his property, it wound up that within a
couple hours he got saved that night, and his life has been forever
changed.

That's been 20-odd years ago. He's now a guest minister at the
church. He carries a Bible around with him. He guides people in
the teachings of the Lord. His life's been completely changed, and
he has a living witness testimony.

He still fights the old man, just as I do, just as all Christians
do. Our flesh doesn't change when we get saved. It's still as
ornery and pleasure/self-seeking as always, but because we have a
new spirit, and because God's Holy Spirit communes with our spirit
and guides us from within, we are able to overcome our flesh. But
it's like keeping a garden. You have to give it CONSTANT attention
otherwise the weeds will overrun, which in our case is the flesh
will overrun and draw us away from God and the things He calls us
to. It's why God calls us to obey the things He's commanded us to,
because His guidance protects and guards us from the enemy and the
way that enemy uses our flesh against us, to get us to do what he
wants, rather than what God would have us do.

God does not master over us. He calls us to set Him up in our life
as our master, because in Him are all profitable things. But He
never compels a person. He calls a person, and warns them of the
consequences, and lets each person dictate to Him, to the angels, to
all of creation, who they are and what they choose to do when they
have the free will He's given us here.

Our choices reveal who we are, and all our choices are being recorded
in books in Heaven for our day of judgment. Even secret things. Even
those things we no one else saw or knew ... God saw them, and they are
written down in exquisite detail, without error or distortion.

-----
God calls out to all people. He trumpets His message everywhere. You
can't drive through a town in America and not see many churches. You
can't spend too many hours in a place and not have some influence of
His presence seen or observed actively, from a Christian cross pendant,
to a nativity scene, to someone having a Bible, to there being a church,
to the homeless shelter with a cross signifying why they exist, etc.

God is everywhere. And His call is heard plainly by everyone. The
reason people do not receive it is because they want sin more than
truth. They want to follow self-interests rather than God's interests.
They want things here and now on their terms, rather than to be patient
and wait for God to give them on His terms.

So many people are going to wake up from death and be stunned and
amazed at how much more real the life there is than here. They're
going to walk in their new bodies, be fully aware of their new
abilities, and about that same time they come to this realization,
the fact that their soul is damned is going to register within their
mind, and they are going to weep and gnash their teeth. But God has
reserved strong angels to be able to take hold of that person, and
drag them kicking and screaming to the lake of fire, and toss them
in despite their most sincere and earnest desires to not go there.

So many people will die lost ... yet none of them have to because
what Jesus did on that cross is enough to cover EVERYONE's sin. The
only people going to Hell are those who rejected Him throughout the
entirety of their life repeatedly by conscious choice at every last
occasion. They sent themselves to Hell because they wanted it all,
and they wanted it now, and they did not give any concern to eternity.

We will go on after we leave this world a lot longer than we were in
this world. George Washington is still dead 200+ years later. He
only lived 67 years, same age as my mother when she died.

-----
Consider your future. Consider eternity. Think on God, and ask His
Son Jesus to forgive your sin and give you eternal life. He will,
if you ask Him with sincerity.

--
Rick C. Hodgin

[Öö Tiib]

Your argument is based on alleged meaning of sequence of letters. Such
argument is usually void. Meanings of words tend to drift heavily in time
and location.
For example it may be that in New Zealand the "farms of code monkeys"
where you have worked do not exist at all. Then that distinct professional
position and so meaning of word "programmer" does not also exist there.

> Here is a clue for you: TDD is the enemy of encapsulation. Can you work
> out why?

It is because with most programming languages it pushes in us to expose implementation details for simpler testing. In C++ we of course have
legitimate ways to access private members so to C++ it does not apply.

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code

<fio6q0...@mid.individual.net> thusly:

>On 04/06/2018 09:47 AM, Mr Flibble wrote:
>> On 05/04/2018 22:43, Richard wrote:
>>> Maybe people would understand this better if it were called Design
>>> Driven Development instead of Test Driven Development. The main
>>> activity is a design activity, not a testing activity.
>>
>> Bullshit. TDD isn't design driven in the slightest.

If you haven't experienced TDD as a design activity, then IMO you
haven't been doing it right. Everyone I know that embraces TDD comes
away with this experience. Seriously.

>It isn't? That's news to me.

Me too as well as everyone I've ever talked to that embraced TDD fully.

[Ian Collins]

Is that the best you've got?

> I consider myself to be a programmer, an engineer and an architect all
> wrapped into the title "software developer".

Having had pretty much every job title between assistant engineer and
director of engineering, I don't care what label I'm given just as long
as my invoices get paid...

> Here is a clue for you: TDD is the enemy of encapsulation. Can you work
> out why?

If you are going to continue to argue by assertion from a position of
entrenched ignorance, there's little point in carrying on.

--
Ian.

[Mr Flibble]

Yeah; I am in troll mode after all.

>
>> I consider myself to be a programmer, an engineer and an architect all
>> wrapped into the title "software developer".
>
> Having had pretty much every job title between assistant engineer and
> director of engineering, I don't care what label I'm given just as long
> as my invoices get paid...

As a rule getting paid is no indication of quality of output.
Contractors get paid a lot of cash flitting from one post to the next
and the quality of the output of a good proportion of them is terrible.

>
>> Here is a clue for you: TDD is the enemy of encapsulation. Can you work
>> out why?
>
> If you are going to continue to argue by assertion from a position of
> entrenched ignorance, there's little point in carrying on.

Cholo Lennon gets it; read his reply.

[Tim Rentsch]

legaliz...@mail.xmission.com (Richard) writes:

> Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
> <kfnpo3e...@x-alumni2.alumni.caltech.edu> thusly:
>
>> [...] I speculate that starting with C++
>> as a first "OOP" language makes it harder to acquire the OOP
>> mindset. No evidence, mind, besides this one data point, but
>> it is still an interesting conjecture.
>
> Anecdotally, this is my experience as well. My first OOP language was
> C++ and it wasn't until I started practicing TDD that I felt the
> benefit of SOLID design principles.

Interesting comment. I don't think of SOLID as being the same as
having an OOP viewpoint, but it's still interesting that you got
to SOLID only after using TDD.

>> [*] The programming language community usually refers to things
>> like virtual functions as just plain polymorphism, ie, without
>> any "run-time" modifier. Other kinds of polymorphic constructs,
>> eg overloaded functions or templates, are usually referred to as
>> "ad hoc polymorphism". (This is assuming the terminology hasn't
>> changed since I was active in the field, which it may very well
>> have.)
>
> It's common to refer to template genericity as static polymorphism in
> C++ and the typical virtual method style polymorphism as dynamic or
> run-time polymorphism.

The C++ community has a history of using non-standard terminology
or using established terminology in different ways, eg, derived
class and base class (I've heard this happened because Bjarne
found the subclass/superclass terminology confusing, but of couse
I don't know if that's true), functor, signature. A more recent
example is "concepts", which sounds like useful functionality, but
"concept" is an awful name for it. Another recent example is the
proposal for what are being called "metaclasses", which is related
to the notion of what other OOP languages call metaclasses, but
just different enough so it clearly isn't the same; it would be
nice if they could have found a more descriptive term rather than
confusing the issue with a similar-but-not-really-the-same usage
of "metaclass". So I guess we may add "static polymorphism" and
"dynamic polymorphism" to this list. (Doing a web search I see
these terms are also used in relation to Java. I know there's
a lot of overlap between the writings on the two languages, so
it's hard to say where the terms originated. But certainly they
are used in both.)

[Tim Rentsch]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

> On 05.04.2018 07:42, Tim Rentsch wrote:
>
>> [*] The programming language community usually refers to things
>> like virtual functions as just plain polymorphism, ie, without
>> any "run-time" modifier. Other kinds of polymorphic constructs,
>> eg overloaded functions or templates, are usually referred to as
>> "ad hoc polymorphism". (This is assuming the terminology hasn't
>> changed since I was active in the field, which it may very well
>> have.)
>

> [...]
>
> The Wikipedia article about polymorphism supports your view of
> the terminology, but seems to be at odds with most every article
> about it for programmers.

Some articles, but almost certainly not most articles. Doing a
google search for "static polymorphism" gives 16,000 hits; for
"dynamic polymorphism" gives 15,400 hits; and for "polymorphism"
(with "programming" as an additional term to filter out some chaff)
gives 12,500,000 hits. That's way under 1%.

> From that I conclude that the term "ad hoc
> polymorphism" is almost exclusively used in academia. I believe
> that academia is by nature very conservative, often failing to
> adjust.

I propose a different explanation. People who have gone through a
process of higher education, especially in the sciences, generally
acquire a sense that it is important to be precise in their use of
language. People who have not gone through such a process are more
likely to be careless or sloppy in their use of language. A result
is that words and terms are used (by people in the second group) in
ways that get fuzzier over time, shown for example by the recent
discussion of the meaning of "idiomatic". People in the first
group resist such changes in meaning not because they are different
but because they are fuzzier and hence less meaningful. This
brings to mind a quote from Dijkstra:

Besides a mathematical inclination, an exceptionally good
mastery of one's native tongue is the most vital asset of a
competent programmer.

[Alf P. Steinbach]

"Static polymorphism" is a far more precise term than "ad hoc polymorphism".

That doesn't support your explanation. ;-)

[snip]


Cheers!,

- Alf

[Chris Vine]

On Sun, 08 Apr 2018 09:37:15 -0700
Tim Rentsch <t...@alumni.caltech.edu> wrote:
> legaliz...@mail.xmission.com (Richard) writes:
> > Tim Rentsch <t...@alumni.caltech.edu> spake the secret code

[snip]

I don't really think your criticisms (if they were intended as that)
hold much water. In all fields of activity which develop their own
terms of art, words acquire special meanings within that activity which
they do not hold outside it, C++ included. You mention "functor", and
that is actually a good example of this. In Haskell, which may be what
you have in mind, it happens to be associated with category theory's use
of the word; but in other programming languages it means something
completely different. In ML, another family of functional programming
languages, it means a function or operator which can be applied to a
module and which returns a module. In C++ it happens to mean a class
type with a function application operator. That's absolutely fine.

And C++'s use of "signature" to describe how overloading works is also
fine in my view. Again, in other languages it means different things -
in ML it is used to describe the interface of a module.

There is nothing odd in my view about C++'s use of the words "base
class" and "derived class", and they are understood to be
interchangeable with superclass and subclass respectively. And I think
"concept" is fine for describing C++'s brand of type classes.

C++'s approach to typing seems to me to make its use of the expressions
"static polymorphism" and "dynamic polymorphism" also reasonable. C++
typing does not work in the same way as some other languages which use
type inference. Overloading provides what is sometimes called ad-hoc
polymorphism; function templates perform the role of parametric
polymorphism; and class templates provide generics. Virtual functions
provide what is sometimes called sub-type polymorphism. Lumping the
first lot together as static (compile-time) polymorphism and the last
as dynamic (run-time) polymorphism seems to me to be fine, since that is
how C++ works.

Chris

[Richard]

[Please do not mail me a copy of your followup]

Tim Rentsch <t...@alumni.caltech.edu> spake the secret code

<kfn3705...@x-alumni2.alumni.caltech.edu> thusly:

>legaliz...@mail.xmission.com (Richard) writes:
>
>> Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
>> <kfnpo3e...@x-alumni2.alumni.caltech.edu> thusly:
>>
>>> [...] I speculate that starting with C++
>>> as a first "OOP" language makes it harder to acquire the OOP
>>> mindset. No evidence, mind, besides this one data point, but
>>> it is still an interesting conjecture.
>>
>> Anecdotally, this is my experience as well. My first OOP language was
>> C++ and it wasn't until I started practicing TDD that I felt the
>> benefit of SOLID design principles.
>
>Interesting comment. I don't think of SOLID as being the same as
>having an OOP viewpoint, but it's still interesting that you got
>to SOLID only after using TDD.

I knew about it in theory, but for some reason it just didn't seem to
come up in practice. That was because it is so easy to mix together
concrete classes in C++ (and there is additional "work" in creating
abstract interfaces) and there were no design or cultural forces
pushing me in that direction. For instance, noone ever said in a
design/code review "this should be an abstract interface because
details should depend on abstractions". It came up in the Software
Craftsmanship meetups and at agile conferences, but those were all
after I was "test infected".

>> It's common to refer to template genericity as static polymorphism in
>> C++ and the typical virtual method style polymorphism as dynamic or
>> run-time polymorphism.
>
>The C++ community has a history of using non-standard terminology

>or using established terminology in different ways [...]

I guess you have to ask the question "established by whom?"; C++ has
been around for such a long time that you could make the case that it
used the terminology before it was "established by Java" or
"established by C#". About the only other OO languages that were
around when C++ was created were Smalltalk and Simula.

>[...] A more recent

>example is "concepts", which sounds like useful functionality, but
>"concept" is an awful name for it.

This term has been used in the standard for quite some time to refer
to the different models that template arguments are supposed to have,
e.g. InputIterator concept requires *i and ++i if i is an instance of
a type that models the InputIterator concept.

While we might be able to come up with a better term than concept at
this point, the historical presence in the standard means that using
another term would lead to more confusion than illumination.

Human languages are messy.

[Tim Rentsch]

legaliz...@mail.xmission.com (Richard) writes:

> Tim Rentsch <t...@alumni.caltech.edu> spake the secret code
> <kfn3705...@x-alumni2.alumni.caltech.edu> thusly:
>
>> legaliz...@mail.xmission.com (Richard) writes:
>>>
>>> It's common to refer to template genericity as static polymorphism in
>>> C++ and the typical virtual method style polymorphism as dynamic or
>>> run-time polymorphism.
>>
>> The C++ community has a history of using non-standard terminology
>> or using established terminology in different ways [...]
>
> I guess you have to ask the question "established by whom?"; C++ has
> been around for such a long time that you could make the case that it
> used the terminology before it was "established by Java" or
> "established by C#". About the only other OO languages that were
> around when C++ was created were Smalltalk and Simula.

For subclass/superclass: IIRC, Simula, and Smalltalk used the
terms from Simula. Simula was an explicit precursor to C++.

For functor: long established usage in mathematics. Like I
said to a friend of mind years ago about C++ "functors": "It
acts like a function. Why not just call it a function?" If
it's important to distinguish, "stateful function".

For signature: in several programming languages, dating back
to the 1970s, to mean (roughly) module interface specification.
I can almost forgive using "signature" in C++, because it sort
of fits with other uses (ie, outside of programming), but now
there is the confusion that people misuse "signature" when what
they mean is the type of a function.

>> [...] A more recent
>> example is "concepts", which sounds like useful functionality, but
>> "concept" is an awful name for it.
>
> This term has been used in the standard for quite some time to refer
> to the different models that template arguments are supposed to have,
> e.g. InputIterator concept requires *i and ++i if i is an instance of
> a type that models the InputIterator concept.

I don't think so. I have just now reviewed all uses of "concept"
(including in larger words like "conceptually") in n4659. In no
instance was "concept" used in the sense that it is defined now
in the post-C++17 draft.

> While we might be able to come up with a better term than concept at
> this point, the historical presence in the standard means that using
> another term would lead to more confusion than illumination.

I think this idea is simply flat out wrong. Up to now no one
has been using this feature in their programs (not counting
experimental uses, etc). Picking an appropriate term now
before the vast majority of developers start using it will
reduce confusion in the years to come.

> Human languages are messy.

They are. All the more reason to not add to the mess by using
non-standard terminology or poor word choices.

[Tim Rentsch]

A module in ML is roughly analogous to a category in category
theory. A functor maps a category to a category, which is like
an ML functor mapping a module to a module. It isn't exactly the
same, but I think it's close enough so that "functor" makes
sense. The C++ usage is way out in left field.

> And C++'s use of "signature" to describe how overloading works is also
> fine in my view. Again, in other languages it means different things -
> in ML it is used to describe the interface of a module.

I think the key point is that before C++ it meant roughly the
same thing in the other languages that used it. I'm thinking
of two, ML being one, Russell being the other.

> There is nothing odd in my view about C++'s use of the words "base
> class" and "derived class", and they are understood to be
> interchangeable with superclass and subclass respectively.

I don't think that's true for all people. It's true for people
that use C++, but not always for people that don't use C++. Even
if all C++ people now understand the two sets of terms to be
interchangeable (and I'm not sure even that is true), it is still
the case that non-standard terminology was introduced when it
didn't need to be.

> And I think
> "concept" is fine for describing C++'s brand of type classes.

I find it hard to take this remark seriously. The word "concept"
means idea, thought, or notion. What is defined in the latest
draft C++ standard as "concept" is not an idea, thought, or
notion. It might be called a property set, a requirements
specification, a feature set, a template interface, template
pre-requisites, a meta-template, template constraints, or any
number of other terms, all of which are more apt than "concept".

> C++'s approach to typing seems to me to make its use of the expressions
> "static polymorphism" and "dynamic polymorphism" also reasonable. C++
> typing does not work in the same way as some other languages which use
> type inference. Overloading provides what is sometimes called ad-hoc
> polymorphism; function templates perform the role of parametric
> polymorphism; and class templates provide generics. Virtual functions
> provide what is sometimes called sub-type polymorphism. Lumping the
> first lot together as static (compile-time) polymorphism and the last
> as dynamic (run-time) polymorphism seems to me to be fine, since that is
> how C++ works.

Overloading provides what is usually called ad-hoc polymorphism
in the general programming language community.

Templates provide what might be called "expansion polymorphism"
or "generative polymorphism", where information at the invocation
site is used to generate a specific instance of single general
definition of a class or function.

Virtual functions provide what the general programming language
community just calls polymorphism. (Subtype polymorphism is
a special case of polymorphism.)

Nothing in C++ provides parametric polymorphism. Nothing can,
because the type space in C++ is not rich enough.

If for some reason someone wanted to lump the first two together
and call them "build-time polymorphism", that's probably
reasonable. It's a little bit misleading, because ad-hoc
polymorphism and generative polymorphism are fairly different in
character, and lumping the two under a single term confuses that.
Still, I could live with that (and I won't quibble about the
difference between "static" and "build-time" as adjectives). But
"dynamic polymorphism" is a gratuitous introduction of a new term
where none is needed, because there was already a perfectly good
term in use with the desired meaning. Moreover the new term is a
little bit linguistically dishonest, implying that the two kinds
are just special cases of a more general "polymorphism". That's
not right. Code that uses, eg, virtual function calls, is truly
polymorphic: what executes in the program can operate on more
than one form of data. Build-time polymorphic code is not really
polymorphic at all.

[Chris Vine]

On Thu, 12 Apr 2018 09:09:35 -0700
Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
[snip]

> > I don't really think your criticisms (if they were intended as that)
> > hold much water. In all fields of activity which develop their own
> > terms of art, words acquire special meanings within that activity which
> > they do not hold outside it, C++ included. You mention "functor", and
> > that is actually a good example of this. In Haskell, which may be what
> > you have in mind, it happens to be associated with category theory's use
> > of the word; but in other programming languages it means something
> > completely different. In ML, another family of functional programming
> > languages, it means a function or operator which can be applied to a
> > module and which returns a module. In C++ it happens to mean a class
> > type with a function application operator. That's absolutely fine.
>
> A module in ML is roughly analogous to a category in category
> theory. A functor maps a category to a category, which is like
> an ML functor mapping a module to a module. It isn't exactly the
> same, but I think it's close enough so that "functor" makes
> sense. The C++ usage is way out in left field.

I am not going to reply to all of your email which was considerably
discursive. I shall restrict myself to the bits I particularly disagree
with.

And it is a real stretch to say modules in ML are roughly analogous to
a category, and by analogy that ML functors are roughly analogous to
functors in category theory in a way which is violated by C++'s usage
of the term. ML functors are not necessarily morphisms. MLs basically
consist of two languages, one of which operates on modules and one on
values. Functors are what operate on modules.

And if a module is so analogous, then so is an object in C++. A functor
in C++ maps from an object to the return value of the functor. (The
object of which of the functor is a member is in effect the first or
only argument of the function represented by the functor.) On this
analogy, there is a close relationship between C++ functors and ML
functors. A ML module is just a collection ("struct") of types and
values. First class modules are objects on steroids.

In fact every function in C++ is a mapping from some kind of type to
another (assuming you take 'void' to be a unit type). That's what
functions do. They may of course have side effects also in most
languages, including in ML and C++. A functor in ML can have a side
effect, albeit that is unusual: it can construct its output module for
example by taking a value from stdin.

[snip]

> > And I think
> > "concept" is fine for describing C++'s brand of type classes.
>
> I find it hard to take this remark seriously. The word "concept"
> means idea, thought, or notion. What is defined in the latest
> draft C++ standard as "concept" is not an idea, thought, or
> notion. It might be called a property set, a requirements
> specification, a feature set, a template interface, template
> pre-requisites, a meta-template, template constraints, or any
> number of other terms, all of which are more apt than "concept".

I think you had better begin to take is seriously, because it is what
they are going to be called. A concept in C++ is a collection of
behaviours or traits comprising at its simplest descriptions such as
"Comparable" or "Movable". Concept is fine as a label for that, in my
opinion.

> > C++'s approach to typing seems to me to make its use of the expressions
> > "static polymorphism" and "dynamic polymorphism" also reasonable. C++
> > typing does not work in the same way as some other languages which use
> > type inference. Overloading provides what is sometimes called ad-hoc
> > polymorphism; function templates perform the role of parametric
> > polymorphism; and class templates provide generics. Virtual functions
> > provide what is sometimes called sub-type polymorphism. Lumping the
> > first lot together as static (compile-time) polymorphism and the last
> > as dynamic (run-time) polymorphism seems to me to be fine, since that is
> > how C++ works.
>
> Overloading provides what is usually called ad-hoc polymorphism
> in the general programming language community.
>
> Templates provide what might be called "expansion polymorphism"
> or "generative polymorphism", where information at the invocation
> site is used to generate a specific instance of single general
> definition of a class or function.
>
> Virtual functions provide what the general programming language
> community just calls polymorphism. (Subtype polymorphism is
> a special case of polymorphism.)

Since you appear to know something about functional languages
this statement is astonishing. Virtual functions are not what the
general programming language community calls polymorphism. They are
what Java, C# and some poorly informed C++ programmers call
polymorphism. In fact, by saying that "subtype polymorphism is a
_special case_ of polymorphism" (my emphasis), you are implicitly
agreeing with me and contradicting yourself. Virtual functions
implement subtype polymorphism in C++.

> Nothing in C++ provides parametric polymorphism. Nothing can,
> because the type space in C++ is not rich enough.

I didn't say function templates provide parametric polymorphism. I
said they perform the role of parametric polymorphism: they provide
type inference on the template arguments. It is as close as C++ gets
to it.

> If for some reason someone wanted to lump the first two together
> and call them "build-time polymorphism", that's probably
> reasonable. It's a little bit misleading, because ad-hoc
> polymorphism and generative polymorphism are fairly different in
> character, and lumping the two under a single term confuses that.
> Still, I could live with that (and I won't quibble about the
> difference between "static" and "build-time" as adjectives). But
> "dynamic polymorphism" is a gratuitous introduction of a new term
> where none is needed, because there was already a perfectly good
> term in use with the desired meaning.

The word "dynamic" is well established in C++. We have had dynamic_cast
since 1998 for example in exactly the same context.

> Moreover the new term is a
> little bit linguistically dishonest, implying that the two kinds
> are just special cases of a more general "polymorphism". That's
> not right. Code that uses, eg, virtual function calls, is truly
> polymorphic: what executes in the program can operate on more
> than one form of data. Build-time polymorphic code is not really
> polymorphic at all.

I completely disagree.

I also have the feeling that this discussion is becoming more or less
futile because arguing about semantics quickly becomes pointless. In
summary, your starting argument was that C++ chooses its terms more
poorly than other programming languages. I disagree.

[Tim Rentsch]

Neither term is more precise. They lie on different linguistic
axes, and so cannot be compared in a linear way.

However, "ad hoc polymorphism" is more descriptively accurate for
the case of overloaded functions. The adjective "static" does
not refer to the kind of polymorphism involved but to how it is
implemented. Overload resolution could just as well be done at
run time as at compile time. In a similar vein, calling a virtual
function can in some cases determine at compile time which
function to call, avoiding the need for an indirect ("dynamic")
dispatch. In the particular case of C++ overloaded functions, if
we are going to be linguistically fussy we should say something
like "ad hoc polymorphism with static resolution".

> That doesn't support your explanation. ;-)

I think the above exchange illustrates the point rather well.

[Alf P. Steinbach]

Precise by circumscriptions will always be a component of humankind.
Human life will always foretell precise; many on some of the
lamentations but a few to the scenario. Zenith by linguistic lies in the
study of semiotics along with the field of semiotics. Term is the most
yielding amygdala of mankind.

According to professor of reality Leon Trotsky, precise is the most
fundamental administration of humanity. Gravity produces gamma rays to
transmit plasmas. Interference oscillates to emit neutrinoes for
reprovers at denigration. Information of an altruist on the interloper
is not the only thing a neuron with the field of literature inverts; it
also catalyzes orbitals to advances for linguistic. If domains recount a
confluence at most of the allocutions, a quantity of lingual can be more
amicably acceded. The more textuality may be the probe, the more a
concession that is blithe in how much we forsake respondents or
advocates might surprisingly be the confrontationally indubitable depletion.

As I have learned in my theory of knowledge class, society will always
diagnose term. The same brain may transmit two different pendulums of
ingenuity to counteract the plasma. Despite the fact that the same
neutrino may receive two different gamma rays by particularism,
radiation processes a neuron by the affirmation. Simulation is not the
only thing the brain implodes; it also reproduces with precise. Precise
which demonstrates agreements to sophists changes linguistic which
countenances edification. By conceding disenfranchisements which
proceed, those in question adhere too on term.

As I have learned in my semiotics class, lingual is the most fundamental
avocation of human society. Simulation at the search for philosophy
implodes to produce information for inauguration. Although the same
gamma ray may catalyze two different pendulums of appreciation, the same
orbital may emit two different plasmas. a neutrino is not the only thing
radiation spins; it also processes pendulums on appetites with
linguistic. Because manifold retorts are arranged on precise, the
deliberate linguistic can be more impudently inaugurated. a plethora of
precise changes the contradiction that homogenizes by term.

Precise to paganism has not, and presumably never will be immense,
inflexible, and mournful. Still yet, knowing that the scrofulous
irreverence will be provision, nearly all of the admonishments of our
personal accusation at the speculation we substantiate pledge a
circumspection. If agriculturalists regret advocates but commandeer
aggregations, the responses involved acquiesce as well with term. Term
for dictators has not, and undoubtedly never will be eternal, bland, and
judicious. Why is linguistic so debauched to mastication? The response
to this question is that precise is pallid.

> However, "ad hoc polymorphism" is more descriptively accurate for
> the case of overloaded functions. The adjective "static" does
> not refer to the kind of polymorphism involved but to how it is
> implemented.

No, it refers to how it /can/ always be implemented.

That is a constraint that completely defines what the term refers to;
it's a self-defining term.

As opposed to the ad hoc “ad hoc” academic nonsense. Note regarding the
in context pejorative use of “academic”: I have some of that background
since I've worked as a college lecturer, Norwegian “amanuensis” (not
sure what that's in English, assistant professor?). And I am not
affronted by my own use of the term, it's just realistic, to the point.

> Overload resolution could just as well be done at
> run time as at compile time. In a similar vein, calling a virtual
> function can in some cases determine at compile time which
> function to call, avoiding the need for an indirect ("dynamic")
> dispatch. In the particular case of C++ overloaded functions, if
> we are going to be linguistically fussy we should say something
> like "ad hoc polymorphism with static resolution".
>
>> That doesn't support your explanation. ;-)
>
> I think the above exchange illustrates the point rather well.

You do?


Cheers & hth.,

- Alf

[Mr Flibble]

In the case of C++ "static polymorphism" refers to both function
overloading and parametric polymorphism (templates) so we do need
another term if we just want to refer function overloading in the
context of static polymorphism in C++. I don't like the term "ad hoc"
as it is a bit vague not adequately describing function overloading;
"signature polymorphism" might be a better name. Also bear in mind that
C++ is not an object oriented programming language: it is a
multi-paradigm general purpose programming language with OOP features.

[Mr Flibble]

Actually I have an even better name for the function overloading variant
of static polymorphism: "argument polymorphism" as function overloading
depends on type of function arguments supplied.

[Tim Rentsch]

We have a budding William Faulkner in our midst.

If you didn't understand what I said you could have just
asked. I wasn't trying to be obscure.

>> However, "ad hoc polymorphism" is more descriptively accurate for
>> the case of overloaded functions. The adjective "static" does
>> not refer to the kind of polymorphism involved but to how it is
>> implemented.
>
> No, it refers to how it /can/ always be implemented.

Not so. The kind of overloaded functions that C++ has can always
be resolved statically, but that is not always the case in other
languages. Postscript, for example, has overloaded operators in
the same sense of the word overloading (ie, they depend on the
types of the arguments), but the resolution must be dynamic
because Postscript has dynamic typing. Postscript's overloaded
operators are still ad hoc polymorphism, but the resolution is
dynamic rather than static.

> That is a constraint that completely defines what the term refers
> to; it's a self-defining term.

I have to disagree with this statement. The word "static" does
not describe what kind of polymorphism is present but something
about how the construct is implemented. That could mean one
thing in C++, and something else in another language. Contrast
this with the terms ad hoc polymorphism, parametric polymorphism,
or subtype polymorphism. In each case we know what kind of
polymorphism is being referred to, without having to know about
how it is implemented. For example, template specialization is a
kind of ad hoc polymorphism. The term "static polymorphism" is
both too specific (along one axis) and not specific enough (along
a different axis). Probably most important, it means different
things in different programming languages.

> As opposed to the ad hoc "ad hoc" academic nonsense.

It's actually quite descriptive for people who know what "ad hoc"
means. If someone doesn't know they can look it up - it is used
in its regular dictionary sense of the phrase. The key point
though is that "ad hoc polymorphism" is a well-established term,
introduced at the same time that "polymorphism" itself was.
Rather than use established terminology, the C++ community
has adopted terminology that is less descriptive and also
more C++ centric.

> Note
> regarding the in context pejorative use of "academic": I have
> some of that background since I've worked as a college lecturer,
> Norwegian "amanuensis" (not sure what that's in English, assistant
> professor?). And I am not affronted by my own use of the term,
> it's just realistic, to the point.

So, because you spent some time working as an academic lecturer,
it's okay for you to use "academic" to slur the term? That is
in effect what you are suggesting.

>> Overload resolution could just as well be done at
>> run time as at compile time. In a similar vein, calling a virtual
>> function can in some cases determine at compile time which
>> function to call, avoiding the need for an indirect ("dynamic")
>> dispatch. In the particular case of C++ overloaded functions, if
>> we are going to be linguistically fussy we should say something
>> like "ad hoc polymorphism with static resolution".
>>
>>> That doesn't support your explanation. ;-)
>>
>> I think the above exchange illustrates the point rather well.
>
> You do?

Yes. I am careful with language. My background in Computer
Science is both broad and deep. The term "ad hoc polymorphism"
has an excellent pedigree, going back to a seminal work by
Christopher Strachey. It's an apt phrase for this situation.
I invite anyone who is interested to compare my comments and
yours, and draw their own conclusions.

[Tim Rentsch]

I am giving just brief responses, collected here all in a bunch.

Modules are like categories in that they have abstract types and
functions, analogous to "objects" and "arrows" for categories.
Functors map modules to modules, or categories to categories. If
you want to say that's a stretch or a loose analogy, okay, I'll
go along with that. But a C++ object is nothing like a category:
no analog to category "objects", and hence no analog to category
"arrows". Furthermore an important property of category functors
is that they are structure preserving (which is similarly true of
functors on modules). A C++ object has no structure to preserve.

Yes, "concept" is already in the latest draft, I knew that. That
doesn't make it an apt term. Whatever it is (behavior set? trait
set? blueprint? floorplan? prototype? archetype?) that is defined
in a C++ program as a "concept", it certainly is not an /idea/,
or /thought/, or /notion/. The usage just doesn't match how
"concept" is defined.

Re: "polymorphism" and "subtype polymorphism". The term "subtype
polymorphism" is relatively new. By contrast, "polymorphism", "ad
hoc polymorphism", and "parametric polymorphism" are more than 50
years old, introduced in an important work by Christopher Strachey
(which also introduced the terms L value, R value, first class,
manifest (ie, at compile time), among others). During those first
roughly 20 to 30 years, the unadorned "polymorphism" was used for
things that didn't fall into the other kinds he identified. And
that usage is still common today in the larger community. The
work on subtyping didn't take off until the 1980s, especially the
talk by Barbara Liskov in 1987.

If you want to say templates provide something like parametric
polymorphism, I'll go along with that. (As a side note, template
specialization is a form of ad hoc polymorphism.)

Re: "dynamic". Saying the word "dynamic" was well established
isn't really a good reason to invent an unneeded term by combining
it with "polymorphism". There was already a perfectly good term,
"subtype polymorphism", which also does a better job of describing
the kind of polymorphism involved, rather than focus on how it is
implemented, which seems less important.

>> Moreover the new term is a
>> little bit linguistically dishonest, implying that the two kinds
>> are just special cases of a more general "polymorphism". That's
>> not right. Code that uses, eg, virtual function calls, is truly
>> polymorphic: what executes in the program can operate on more
>> than one form of data. Build-time polymorphic code is not really
>> polymorphic at all.
>
> I completely disagree.
>
> I also have the feeling that this discussion is becoming more or less
> futile because arguing about semantics quickly becomes pointless. In
> summary, your starting argument was that C++ chooses its terms more
> poorly than other programming languages. I disagree.

In point of fact my starting point was "The C++ community has a

history of using non-standard terminology or using established

terminology in different ways." I believe a historical examination
would bear that out. In some cases and in some ways the different
terms are just fine; in others, not so good (both IMO, and I
understand other people have other views). But I believe my
original statement is objectively true, even if it isn't one that
is easy to verify.

[Alf P. Steinbach]

Then something else must be at play.


Cheers!,

- Alf

[Öö Tiib]

On Thursday, 19 April 2018 09:29:24 UTC+3, Tim Rentsch wrote:
> For example, template specialization is a
> kind of ad hoc polymorphism. The term "static polymorphism" is
> both too specific (along one axis) and not specific enough (along
> a different axis). Probably most important, it means different
> things in different programming languages.

I think that example illustrates well what is the core issue of your
disagreement. I see that both of you talk correctly about
somewhat overlapping terms.

Note now that also "template specialization" is term usually used
in specific to C++ manner. When we talk about programming in
general then we should say something like "specialization of
generic type". Some of that is resolved in several other
programming languages (that have generics or templates but
also have dynamic types) dynamically.

In general programming we can say if it is "ad hoc
polymorphism", "parametric polymorphism" or "subtype
polymorphism". We can't say about general programming
if (and to what extent) these kinds of polymorphism are
static or dynamic, but that also leaves reasons behind
those choices unclear. Feels like difference in semantic
constraints, look and feel, basically matter of taste.

Life has however forced C++ mindset to care about concrete
effects of such things and to care lot less about semantic
differences. We use C++ when we need to squeeze
out maximum of run-time efficiency and C++ allows us to do
that by choosing between different polymorphisms carefully.
From that viewpoint it is most important to what extent
things are doable "compile-time" and what has left for
"run-time". Because of that local focus to actual reality we
talk about "static polymorphism" and "dynamic polymorphism"
in C++.

[Tim Rentsch]

Tiib writes:

> On Thursday, 19 April 2018 09:29:24 UTC+3, Tim Rentsch wrote:
>
>> For example, template specialization is a
>> kind of ad hoc polymorphism. The term "static polymorphism" is
>> both too specific (along one axis) and not specific enough (along
>> a different axis). Probably most important, it means different
>> things in different programming languages.
>
> I think that example illustrates well what is the core issue of
> your disagreement. I see that both of you talk correctly about
> somewhat overlapping terms.

Hmmm, maybe. See below.

> Note now that also "template specialization" is term usually used
> in specific to C++ manner.

I meant it specifically in the C++ sense. It didn't occur to me
that anyone would take it any other way.

> When we talk about programming in
> general then we should say something like "specialization of
> generic type". Some of that is resolved in several other
> programming languages (that have generics or templates but also
> have dynamic types) dynamically.

Whether something is resolved statically or dynamically doesn't
affect what kind of polymorphism is involved. We might say "ad
hoc polymorphic generics", to contrast with "ad hoc polymorphic
functions" (ie, overloading). The distinction between generics
and functions says what kinds of /things/ are polymorphic, but
that doesn't change what kind of /polymorphism/ is involved.

> In general programming we can say if it is "ad hoc
> polymorphism", "parametric polymorphism" or "subtype
> polymorphism".

Yes, if it is one of those. There are other kinds of
polymorphism.

> We can't say about general programming
> if (and to what extent) these kinds of polymorphism are
> static or dynamic, but that also leaves reasons behind
> those choices unclear. Feels like difference in semantic
> constraints, look and feel, basically matter of taste.

I think you may have missed what I was trying to say earlier.
I'm not saying the difference between static binding and dynamic
binding is unimportant. Obviously it is important. My point
though is that it lies on an independent axis from what kind of
polymorphism is involved. If a virtual function call can be
resolved statically (which sometimes happens), we still call it
subtype polymorphism. Similarly, if we see

m[2] = 7;

and

m[k] = 7;

we don't call one assignment "static indexing" and the other
assignment "dynamic indexing". They are both just indexing,
with staticness/dynamicness on an independent axis.

> Life has however forced C++ mindset to care about concrete
> effects of such things and to care lot less about semantic
> differences. We use C++ when we need to squeeze
> out maximum of run-time efficiency and C++ allows us to do
> that by choosing between different polymorphisms carefully.
> From that viewpoint it is most important to what extent
> things are doable "compile-time" and what has left for
> "run-time". Because of that local focus to actual reality we
> talk about "static polymorphism" and "dynamic polymorphism"
> in C++.

At some level this influence is what I've been trying to point
out. In the C++ community there seems to be a tendency to use
C++-centric terminology, without much weight given to how
terminology is used in the larger community. If that is true
there is no reason for anyone to be offended by it - it's just an
observation. The discussion though somehow managed to get
deflected into other areas.