Re: Derived private interface

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:nwyetwf3hqn7$.gm3c388p0s3c$.dlg@40tude.net...
> On Tue, 2 Aug 2011 16:16:27 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1nvqqny2226ro$.1ixvoiht8zu8l$.dlg@40tude.net...
>>> On Mon, 1 Aug 2011 16:56:17 -0500, Randy Brukardt wrote:
...
>>>> It did eliminate one thing, the need to have a scheme to create an 
>>>> object of
>>>> each tagged type. That forced the use of either a case statement or an
>>>> access-to-subprogram, either of which is error-prone.
>>>
>>> I don't consider the case statement because it is just a wrong pattern.
>>> Regarding mappings type ID to either a constructing function or tag, 
>>> they
>>> are equivalent. Both require the same amount of maintenance.
>>
>> There are more sources of error when using access-to-subprogram; it's 
>> easy
>> to forget to create a routine or use the wrong one.
>
> Yes there is some advantage that the function in dispatching constructor 
> is
> primitive:
>
>   function Create (...) return T;

There's another advantage (for this use): the language requires you to 
override it, or you get an error. So it is impossible to forget to write the 
routine or have it return the wrong kind of object. Errors of omission are 
the hardest to find, and this property at least prevents those errors. (Of 
course, it doesn't prevent putting the wrong contents into that object.)

                              Randy.