Overloading property vs. non-property

Jonathan M Davis jmdavisprog at gmail.com
Sat Jul 17 14:13:02 PDT 2010


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 have it be decided by the programmer whether 
something was a property or a method. 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 that such an implementation was bug prone. 
I suppose that it all depends on what you consider properties to really be and 
how you look at them.

- Jonathan M Davis


More information about the Digitalmars-d mailing list