@property fields

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Wed Dec 4 11:46:39 UTC 2024


On 05/12/2024 12:12 AM, Dom DiSc wrote:
> On Tuesday, 3 December 2024 at 23:50:20 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> The ``@property`` attribute has been left in the lurch for quite some 
>> time, where only one behaviour related to its return value being of 
>> any value.
>>
>> There are two parts of this proposal, however I am only confident in 
>> the first part, fields.
> 
> Why do we need @property fields?
> I mean, it's nice tho have the setter and getter beeing created 
> automatically, but one of the important properties of @property is to 
> have control if you want only a getter (read only) or only a setter 
> (write only), but here you get always both.

Yes, this has been discussed plenty in the past.

However, both behaviors can be implemented using a method yourself. 
Which is the reason I suspect for none of them being accepted.

These setter and getter proposals have gone no where, partly because 
everything they do, can be done yourself. There are no new semantic 
behaviors provided.

This proposal introduces new semantic behavior that can only be accessed 
via this syntax.

> Also, I mainly use @property if I do NOT have a field, but the value is 
> generated on the fly from other data (getter) or the input produces 
> other effects/change multiple fields (setter).

What you are describing has nothing to do with the attribute.

Anyway, no changes to existing methods are proposed (although there may 
still be an interaction so we may need to limit it to newer editions). 
So your previous usage will still work as it has.



More information about the dip.ideas mailing list