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