Final by default?

Manu turkeyman at gmail.com
Fri Mar 14 05:06:17 PDT 2014


On 14 March 2014 16:39, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 3/12/2014 11:44 PM, Manu wrote:
>
>> But you understand the danger in creating a situation where experts can't
>> optimise their code even if they want to; if at some later time it
>> becomes an
>> issue, or some new customer comes along with more stringent requirements.
>> These are not unrealistic hypothetical scenarios. Libraries exist, and
>> they have
>> customers by definition. Requirements change over time. Defaulting to an
>> inflexible position is dangerous.
>>
>
> As I pointed out in another post, virtuality is hardly the only thing that
> can change in an interface that strongly affects performance. The existence
> of destructors is another. About everything about an interface affects
> performance.
>

In my experience, API layout is the sort of performance detail that library
authors are much more likely to carefully consider and get right. It's
higher level, easier to understand, and affects all architectures equally.
It's also something that they teach in uni. People write books about that
sort of thing.
Not to say there aren't terrible API designs out there, but D doesn't make
terrible-api-design-by-default a feature.
Stuff like virtual is the sort of thing that only gets addressed when it is
reported by a user that cares, and library authors are terribly reluctant
to implement a breaking change because some user reported it. I know this
from experience.
I can say with confidence, poor API design has caused me less problems than
virtual in my career.

Can you honestly tell me that you truly believe that library authors will
consider, as a matter of common sense, the implications of virtual (the
silent default state) in their api?
Do you truly believe that I'm making a big deal out of nothing; that I will
never actually, in practise, encounter trivial accessors and properties
that can't inline appearing in my hot loops, or other related issues.

Inline-ability is a very strong API level performance influence, especially
in a language with properties.

Most programmers are not low-level experts, they don't know how to protect
themselves from this sort of thing. Honestly, almost everyone will just
stick with the default.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140314/72e314cb/attachment.html>


More information about the Digitalmars-d mailing list