@property

[Jonathan M Davis]

Max Samukha wrote:

> On 06/25/2010 12:51 AM, Jonathan M Davis wrote:
> 
>>
>> writeln() isn't a property because it makes no sense to replace it with a
>> getter or setter. The same goes for save() or popFront() on a range.
>> However, things like length() and empty() are properties because they
>> could be replaced with functions like getLength() and isEmpty().
>>
> 
> I don't think the rule applies universally. For example, .NET is full of
> functions starting with Set/Get that are not properties because they
> perform complex/lengthy computations or for some other washy reason.

Well, that means that they probably decided that not only do properties have 
to essentially be nicer getters and/or setters but that they have to be at 
least close to as efficient as getting or setting a public member variable - 
likely at minimum requiring that they be O(1).

Also, there are functions - particularly for getters - where it makes sense 
to start them with get or set but where they really aren't properties of the 
object - rather the object is fetching whatever you asked it to get rather 
than returning the value of one of its member variables.

Still, there are bound to be cases that are a bit fuzzy. save is one example 
that we have in D already (aside from the naming issue). Naming functions 
can be a hard thing to do. But I think that the basic idea that a property 
is effectively a fancy member variable is the basic grounds for choosing 
whether a particular function counts as a property or not. As with many 
things, however, it's up to the programmer to decide exactly what to do in a 
given situation, and applying rules too strictly can cause other problems.

- Jonathan M davis