[Exceptional C++ Style] Fw: const data - was Item 17

[Jon Jagger]

Kevlin Henney wrote:

> In message <41CC8DC7.4020409 at jaggersoft.com>, Jon Jagger 
> <jon at jaggersoft.com> writes
>
>> Kevlin Henney wrote:
>>
>>> So, back to immutable data. Public immutable data is more 
>>> encapsulated  than public mutable data because it eliminates a large 
>>> class of  incorrect usages, ie it has few unintended and malign 
>>> affordances. It  may or may not simplify usage, but that depends on 
>>> the specific  situation. The one Jon has presented it seems not to 
>>> cause any  problems. However, the degrees of freedom open to the 
>>> implementor are  restricted, eg should Jon wish to switch to a 
>>> handle-body  representation he cannot.
>>
>>
>> This depends on the language. In C# (CLR) the proxying facilities 
>> allow interception. I could intercept field access if I wanted to. 
>> And yes I do mean fields and not properties (of course I could 
>> intercept properties too if I wanted). There would be no change 
>> required to the users code.
>
>
> True, but the representation of the field must still exist for it to 
> be intercepted, and anything much beyond operationally as opposed to 
> functionally related extension of semantics might be considered 
> surprising unless that is an accepted part of the architecture.
>
I can use public fields, public properties, or public getter methods. 
Whichever I choose the representation of the chosen thing must still 
exist and (in the CLR) all three have scope for extension. Surely any 
operational extension would be pretty much equally acceptable in all 
three cases and any functional extension would be equally unacceptable 
in all three cases?

These public fields are in a class and the class _does_ have an 
interface. But clearly the fields are not in the interface. And neither 
are any properties. So what is in the interface? Answer, an indexer. You 
provide a string name and the subclass provides the non-terminal with 
that name. Why do I have this? Because it proved wonderfully useful in 
XML driven test code (for example).

The natural syntax is, I still maintain, field-like access. I started 
with that, in its simplest form (viz genuine public data) and provided 
an abstraction (based on a real need) "above". And I still have the 
option of switching to interception or property based access without the 
users needing to edit their code. And if I switched to property based 
access I could declare the properties in the interface. But why do this 
unless/until I need to? Why, in this case, in C#, would I even consider 
using a getter method?

I accept that in C++ things would be a bit different. C++ does not have 
properties so there is a stronger pressure to use getter methods. But in 
this specific case, even in C++, I maintain that I would still use 
genuine public const data members; if I used getter methods I feel I 
would be guilty of "over abstraction".

Cheers
Jon