On Thu, 21 Apr 2011 19:26:16 -0400, Jonathan M Davis <[email protected]>
wrote:
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.
It's enforced only insomuch as a function marked as @property then must
use
property syntax, and those not marked with @property can't use property
syntax. If that's not the case, then what is the point of @property?
What does
it do? The _only_ case which I see where it gives you _anything_ is that
@property could help distinguish where a callable value is returned by a
getter, but if you're allowing property functions to be called without
the
property syntax, then that introduces an ambiguity which renders even
that
benefit of @property useless.
First, you've correctly identified the point of @property. And second, I
believe everyone wants calling @property functions using parenthesizes to
be disabled. Honestly, so far @property is only a keyword in D, which is
somewhat confusing to D newbies.
Allowing for @property functions to be called with parens or
non-@property
functions to be called without parens leads to major inconsistencies in
usage
of functions, and generally makes @property pointless. Even if you make
it so
that @property functions can't be called with parens while allowing non-
@property functions to be called without them, then that leads to
inconsistent
syntax for function calls and makes it harder to know whether something
is
actually a property function or not.
Why is this a benefit? Since your concept of a 'property' differs from
mine, @property can only muddy the waters (unless we're both writing code
using the same standards document). Being able to switch between call
styles, allows me to self document my own (or my company's) guide-lines
into the code. Besides, why should I care if something is a 'property'
function or a regular function? or even a field, for that matter? There's
field syntax and there's method syntax, but why should the library care
how I choose to access their code? They don't have to read/review it. I
(and my team/managers, etc) do.
I really don't understand what benefit
there is in not strictly enforcing @property. Yes, the change will break
code,
but if you don't make it, then very nearly the only benefit of @property
is to
serve as documentation saying that that was the way that the programmer
who
wrote the function intended it to be called.
First, strictly enforcing @property, has to provide a tangible benefit in
order to justify breaking code. (Well, beyond @property calls using ()s)
Second, both David and I have been pointing out use cases and examples of
code and API designs which fundamentally can not be expressed under a
strict @property enforcement.
> 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?
Yes. There will always be arguments over whether something is
conceptually a
property and should be marked with @property. But as far as the language
is
concerned, if @property defines whether the property syntax is used or
not,
then the programmer writing the function can dictate whether a function
is a
property function or not, and the calling of that function is then
completely
consistent. It also allows for the programmer to later make it so that an
@property function is a variable instead. If @property isn't enforced,
then
you can't do that,
Actually, you can do that without @property in languages which implement
the uniform access principal:
http://en.wikipedia.org/wiki/Uniform_access_principle.
And practically, you often can't revert from a 'property' to a method, due
to inheritance, etc.
and the interchangeability of public member variables and
@property functions is supposed to be part of the point of properties in
the
first place.
And it's also a major point of Methods-as-Fields, and of the Uniform
Access Principal.
There is a difference between the concept of a property and whether a
function
is a property function or not. Programmers can (and sometimes do) argue
until
they're blue in the face about whether something is conceptually a
property or
not. Ideally, anything which is conceptually a property would either be a
public member variable or a property function, but it's up to the
programmer
to determine whether they'll make a function a property function or not.
Once
it's a property function, then it should be treated as a property and
use the
property syntax. So, the correctness of whether a property function
actually
represents a conceptual property is irrelevant as far as calling the
function
goes. The programmer who wrote the function made a decision, and then
that's
the API. As long as that is strictly enforced by the compiler, it
eliminates
ambiguity on the manner. It could be a poor design decision to have made
it a
property function, but there's no ambiguity on the part of the compiler
or in
how the function should be used.
True, but remember the only ambiguity that exists with the current system
is with field of a type which is callable with no arguments being upgraded
to a 'property'. And then its mainly an issue of having to fix all the
compilation errors, though silent program changes are possible.
> 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.
The lack of chaining on some level at least is a quality of
implementation
issue (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=2883 ). Whether
chaining assignments calls both the getter and the setter or tries to
use the
return value of a setter (which it shouldn't have) is primarily a QoI
issue.
Most of what you've been discussing hasn't been, but some of it is at
least
partially a QoI issue.
Well, I've been assuming that chaining of getters would work. It's method
chaining of setters which I've been highlighting and that's not a QoI
issue; @property simply can't handle them.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
