On Sat, 17 Jul 2010 17:13:02 -0400, Jonathan M Davis
<jmdavisp...@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. :)
