On Thu, 21 Apr 2011 17:17:27 -0400, Jonathan M Davis <[email protected]>
wrote:
On Thu, 21 Apr 2011 15:41:17 -0400, David Simcha <[email protected]>
wrote:
> On Thu, Apr 21, 2011 at 3:39 PM, Jonathan M Davis
[snip]
>> I know that there are a number of people on the list - particularly
>> newer
>> posters - who fully expect @property to be strict and are surpised
when
>> it
>> isn't. And I see _zero_ problem with strong property enforcement as
>> long as
>> the compiler isn't buggy with regards to properties (which it
currently
>> is).
>> So, I'm 100% behind strict enforcement.
>>
>> - Jonathan M Davis
What about the fact that no two people can agree what should and
shouldn't
be a property? Or, more practically, that third party library A won't
conform with organization B's coding policies? Or how about that an O(1)
property which gets re-factored into a big expensive O(N) operation
(i.e.
see bug 5813) Or ranges/containers that may all have different mixes of
function-like methods and field-like methods. Speaking of templates,
what
about how well/poorly opDispatch, etc compose with @property? Oh, and
then
there are entire articles against the @property solution to the
field/method syntax problem in computer science literature (look up the
Uniform access principle used in Ruby and Eiffel).
Also, surprise isn't necessarily a bad thing. Methods-as-properties
surprised me I received when I first started using D and it put a
massive
smile of joy onto my face in the process.
It's a property if it's marked with @property. If it's not marked with
@property, it isn't.
The concept of a property is entirely synthetic. It grew out of the desire
to utilize field access syntax with methods. It's also somewhat fluid
between languages, since in some it's exclusive, and in others it's not.
Programmers can argue until they're blue in the face
about whether a function should be marked with @property and thus used
as a
property or not, but by strictly enforcing @property, it becomes
completely
consistent.
But that's exactly the problem: without consensus _enforced_ consistency
means adapting yourself to one or more programming
styles/school-of-thought simultaneously.
Every @property functions is called as a property and no function
which isn't @property is called as a property.
But the fact that you're arguing this point shows that this isn't true.
The issue is that unlike fields, functions, objects, etc, no two people
really have the same concept of a 'property' in their heads. So when you
say 'property' and I say 'property', we can mean very different things.
This ambiguity is something fairly rare in programming languages; we
expect that 'noun_X' has a single specific meaning/concept and it doesn't.
So when someone talks about a 'property' they really mean as implemented
in C# (or Java or Python, etc).
Sometimes I wonder if this is all a nomenclature issue; if
Methods-as-Properties was simply called Methods-as-Fields and it was
explained somewhere prominently as something unique to D with
examples/benefits X/Y/Z, would anyone have an issue with it?
And yes, there are definitely bugs with @property. They're going to need
to be
sorted out before @property is enforced, but the fact that bugs exist
doesn't
mean that we should never strictly enforce @property.
I've been taking this into account and (hopefully) haven't been holding
quality of implementation against @property. If any of my arguments were
QoI issues, please let me know.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
