Final by default?

Michel Fortin michel.fortin at michelf.ca
Sat Mar 15 11:33:53 PDT 2014


On 2014-03-15 18:18:27 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 3/15/2014 2:21 AM, Paulo Pinto wrote:
>> In any language with properties, accessors also allow for:
>> 
>> - lazy initialization
>> 
>> - changing the underlying data representation without requiring client code to
>> be rewritten
>> 
>> - implement access optimizations if the data is too costly to keep around
> 
> You can always add a property function later without changing user code.

In some alternate universe where clients restrict themselves to 
documented uses of APIs yes. Not if the client decides he want to use 
++ on the variable, or take its address, or pass it by ref to another 
function (perhaps without even noticing).

And it also breaks binary compatibility.

If you control the whole code base it's reasonable to say you won't 
bother with properties until they're actually needed for some reason. 
It's easy enough to refactor your things whenever you decide to make 
the change.

But if you're developing a library for other to use though, it's better 
to be restrictive from the start... if you care about not breaking your 
client's code base that is. It basically comes to the same reasons as 
to why final-by-default is better than virtual-by-default: it's better 
to start with a restrictive API and then expand the API as needed than 
being stuck with an API that restricts your implementation choices 
later on.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca



More information about the Digitalmars-d mailing list