Overloading property vs. non-property

[Robert Jacques]

On Sat, 17 Jul 2010 17:13:02 -0400, Jonathan M Davis  
<jmdavisprog at gmail.com> wrote:
> On Saturday 17 July 2010 11:14:26 Robert Jacques wrote:
>> As for @properties and Methods-as-properties, I know I dropped out of  
>> the
>> properties debate when the removal of Methods-as-properties was taken  
>> out
>> of the proposal. The more I use @property and see it used, the more I  
>> feel
>> that it's solving its motivating problems by exclusion: i.e. it's  
>> fixing a
>> problematic corner case by virally applying itself to everything else.  
>> So
>> perhaps like throw and nothrow, noproperty would be a superior  
>> alternative
>> to property. But in either case, no/property is a preemptive /
>> retrospective patch to the problem of opCall hijacking. And although I
>> appreciate the value of having the tools to fix an opCall hijack once
>> detected, I'd much rather have a generic solution that detects them at
>> compile-time.
>
> Whereas I would have argued that the whole point of properties was for  
> them to
> be distinct from methods and

Sadly, on a technical level this isn't true. (As it would be really cool  
if the compiler could exceed the limits of a method by knowing it was a  
'property')

> have it be decided by the programmer whether
> something was a property or a method.

On which we agree. We disagree on which programmer gets to make this  
decision: the library writer vs the library user.

> As such, the fact that you methods became
> properties based on their signature was an implementation issue of how
> properties were implemented in D,

And in Eiffel and Ruby.

> and that such an implementation was bug prone.

Actually, @property isn't really any less prone to nasty bugs. i.e. the  
ones that compile fine, but run wrong (all of which are really rare corner  
cases). What @property allows is the seamless upgrading of an opCall-able  
field to a property without fixing dozens of compile errors.

> I suppose that it all depends on what you consider properties to really  
> be and
> how you look at them.
>
> - Jonathan M Davis

Yes, although in retrospect, I think part of the problem was calling D's  
solution 'Methods-as-properties' in the first place; it's really more of  
an application of the Uniform Access Principle.  
(http://www.eiffel.com/general/column/2005/Sept_October.html)
For those who don't want to read the article (or who like cute summaries):  
The Uniform Access Principle is to properties what ranges are to  
iterators. :)