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