On Wed, Jan 30, 2013 at 07:49:58PM -0500, Steven Schveighoffer wrote:
> On Tue, 29 Jan 2013 18:09:44 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 
> >On Tuesday, January 29, 2013 12:10:04 Steven Schveighoffer wrote:
> >>Sound crazy? Ridiculous? Impossible? Insulting?
> >
> >It seems like it could work, but without a way to explictly make something a getter property, it will be impossible to change a property function into a variable later without risking breaking code, because then people will still be able to call the property function with parens. Using parens on getter properties has to be illegal for that to work.
> 
> I don't think this is quite right.
> 
> You can never *exactly* replace a field with a property, or vice versa.  There are aspects that are different for both.
> 
> But there are two separate cases here.  One is, you define a property that is specific to a type, and then replace it with a field.  The other is that there is a DEFINED API, and you replace it with a field.
> 
> In the first case, yes, you would have to go through and replace () instances with ones that do not have it.  If your documentation is clear, then it really is on the user to have made that mistake. With the idea I specified later where getX would require no parentheses, you could specify a property that could not be called like a function unless you use the getX version.
> 
> But in the second case, consider for instance a range.  A range has an empty field/property.  If you called it via empty(), then your code is broken for all different types of ranges which use a field (or enum).
[...]

Actually, this got me thinking. The range API only requires that .empty evaluates to a bool, right? It doesn't matter if it's a function, a public variable, or an enum, as long as it evaluates (or can be evaluated) to a bool. Some ranges indeed do define .empty as an enum (c.f. infinite ranges), so you couldn't take the address of .empty.

Now consider class/struct fields in general. It's entirely possible that a particular class starts off with some fields defined as enums (of the manifest constant sort), say as an enum string. Later on, you may decide that the value should be changeable, so you make it a string class variable. Yet later, you may decide to implement a getter/setter for it for whatever reason.

In the process, the only time it's valid to take the address of the field is when it's a string variable. So in that sense, the API of the class really only should specify that field xyz is a value of type string; user code should not depend on its particular implementation (enum, variable, or getter).

Marking fields as @property is starting to make more and more sense.


T

-- 
BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL

On Tue, 29 Jan 2013 23:57:14 -0500, Jesse Phillips <Jessekphillips+d@gmail.com> wrote:

> Sorry I have to oppose this. It is in no way a compromise as it is completely different from everything suggested. I'm going to take this opportunity to highjack your thread.

You are welcome to it!  I don't know if there is a thread on this newsgroup about properties that hasn't been hijacked.

I should explain that my reasoning behind this is:

1. Walter wants to get rid of @property
2. Dispite 4 years of assuming @property will be implemented, the old D1-style crap is still in place.
3. I've been using Objective C for the last 10 months, which implements a similar scheme to properties.

The compromise is: OK, you want to ditch @property?  I can live with that as long as we have some way to designate properties.  How about this?

> Can an pro-@property members claim that the current behavior is what you want? I believe this answer is no.

The answer is no, but only because what we asked for was never implemented.  What was ORIGINALLY designed with @property (enforcement of parentheses on functions, enforcement against parentheses on properties) is what we wanted.

> It seems at least some members for @property feel that currently functions are being annotated with @property that shouldn't be.

This is unavoidable.  It's like saying I feel some functions are incorrectly named.  @property has nothing to do with it.  There is no "right" answer to whether something should be a @property or not, just like there is no "right" name for a function.

> It also seems those for @property aren't fighting optional parens as much? Can we discuss fixing the issues we have with this. I think a good change is to require parens if returning a callable (opposite of Walters suggestion).

Yes, if the choice is between having the previous implementation (D1) and optional parentheses with a way to designate properties, I'll choose the latter.

> If I have my above claims mostly correct, then I'd say @property needs to be put back in the drawing board and re-implemented.

If you want to replace @property, we need a replacement.  @property still serves a purpose, even in it's currently crippled form.

> I'd be for removing it from the language and if we decide on what in needs to enforce and should be part of the language, then its implementation is completed in a feature branch and remains out of the language until it meets the needed enforcement and behavior.

Fine, but leave @property in until you have completed the replacement feature.

> Granted I'm not concerned if it doesn't ever come back. I believe it has a legitimate role in allowing a change from field to function without harming usage that can not be achieved without an annotation. However it seems we can't achieve this with the combination of features D employs.

Ah, your subtle bias shines through ;)

The real fact of the matter is, if D never had the "hack" properties it did, I actually wouldn't care.  Calling functions instead of setting or getting properties is not that horrible.  But writeln = "hi" is horrible.

>
> I don't agree with the argument that properties provide a convince to identify low overhead access. While I'm not experienced in this area, profile code should indicate where performance is poor, it would be bad to assume "that looks like a field, so it must not be where the performance is bad."

In general, the idea is to implement fields without having to create storage for them.  It will never perform as well as a field.

>
> ---------------------
>
> So let us decide to keep optional (), fix what we can there.
>
> Define what is desired of properties, but for now get rid of what we currently know as @property. Then with a complete proposal, we can say it must meet these goals or it won't exist. Since optional () remain, introducing @property again will not break code and we will only deal with broken code now (and there would be some just to fix the current behavior and its disconnect with -property)

In other words, go back to D1 properties.  No thanks.

-Steve

On Thursday, 31 January 2013 at 01:26:19 UTC, Steven Schveighoffer wrote:
> The compromise is: OK, you want to ditch @property?  I can live with that as long as we have some way to designate properties.  How about this?

It's only natural that a person wants to advocate for his or her own proposal. That having been said, can I interest you in mine? :-)

http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dlang.org

That a long link. Here's a shorter one if it doesn't work (my experience with these forums is limited, sometimes the line gets truncated wrongly):
http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2

If it fails to solve any of your problems, perhaps you could tell me how or why. It is necessary to read the whole discussion to get insight on how the proposal is developing. Also note that the top proposal is not directly related to the @property discussion, so you have to skip down a few lines to get to the property part.

On Thursday, 31 January 2013 at 00:54:54 UTC, Steven Schveighoffer wrote:
> On Wed, 30 Jan 2013 03:05:37 -0500, q66 <quaker66@gmail.com> wrote:
>
>> On Wednesday, 30 January 2013 at 03:02:38 UTC, deadalnix wrote:
>>> On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
>>>> It deeply disturbs me that people even take the original post seriously.
>>>
>>> Well, you may give some arguments instead of no, just no, to convince people.
>>
>> It just gives another meaning to foo.bar, and ENFORCING camelCase by the language while lowercasing shit is just horrible. Anyone with a slightest trace of language design sense realizes that.
>
> Apparently not the designers of objective-C.
>
> -Steve

Not contradictory, Objective-C is not a well designed language :)

On Thu, 31 Jan 2013 08:14:15 -0500, q66 <quaker66@gmail.com> wrote:

> On Thursday, 31 January 2013 at 00:54:54 UTC, Steven Schveighoffer wrote:
>> On Wed, 30 Jan 2013 03:05:37 -0500, q66 <quaker66@gmail.com> wrote:
>>
>>> On Wednesday, 30 January 2013 at 03:02:38 UTC, deadalnix wrote:
>>>> On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
>>>>> It deeply disturbs me that people even take the original post seriously.
>>>>
>>>> Well, you may give some arguments instead of no, just no, to convince people.
>>>
>>> It just gives another meaning to foo.bar, and ENFORCING camelCase by the language while lowercasing shit is just horrible. Anyone with a slightest trace of language design sense realizes that.
>>
>> Apparently not the designers of objective-C.
>>
>> -Steve
>
> Not contradictory, Objective-C is not a well designed language :)

Now we're just name calling ;)  I tend to think that for the most successful company in the business to standardize on it is a pretty good testimony to it being well designed.  I certainly have grown fond of it, there are some really nice features in it.  But truly, xcode has played a large role in making the language seem good.

As another option, what about changing my proposal so instead of setX, it's set_x, and then casing concerns are eliminated?  I think C++.net does that.

-Steve

> Now we're just name calling ;)  I tend to think that for the most successful company in the business to standardize on it is a pretty good testimony to it being well designed.

This is a really bad argument. The facts that language is being used by a large companies does not make it well designed. See PHP, for example - a *horrible* mess of a language, but it is being used at Facebook.

(I don't have an opinion on objective C though, as I don't know the language)

On Thu, 31 Jan 2013 14:39:56 -0000, jerro <a@a.com> wrote:

>> Now we're just name calling ;)  I tend to think that for the most successful company in the business to standardize on it is a pretty good testimony to it being well designed.
>
> This is a really bad argument. The facts that language is being used by a large companies does not make it well designed. See PHP, for example - a *horrible* mess of a language, but it is being used at Facebook.

Small point.  "using" != "standadized on".  The latter implies some evaluation and decision making was done prior to the choice, the former.. well..

> (I don't have an opinion on objective C though, as I don't know the language)

Neither.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wed, 30 Jan 2013 21:49:35 -0500, Zach the Mystic <reachBUTMINUSTHISzach@googlymail.com> wrote:

> On Thursday, 31 January 2013 at 01:26:19 UTC, Steven Schveighoffer wrote:
>> The compromise is: OK, you want to ditch @property?  I can live with that as long as we have some way to designate properties.  How about this?
>
> It's only natural that a person wants to advocate for his or her own proposal. That having been said, can I interest you in mine? :-)
>
> http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dlang.org
>
> That a long link. Here's a shorter one if it doesn't work (my experience with these forums is limited, sometimes the line gets truncated wrongly):
> http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2
>
> If it fails to solve any of your problems, perhaps you could tell me how or why. It is necessary to read the whole discussion to get insight on how the proposal is developing. Also note that the top proposal is not directly related to the @property discussion, so you have to skip down a few lines to get to the property part.

What you describe is almost exactly something I suggested when the original @property debate occurred.  It's actually a version of C#'s properties but with multiple get/set functions.

Can't find it right now, but I found several suggestions of that type.  I even found a few that propose exactly what I have!

It actually is a bit depressing, we have to reset the clock back to late 2009 to start over with properties...

-Steve

On Thu, 31 Jan 2013 09:39:56 -0500, jerro <a@a.com> wrote:

>> Now we're just name calling ;)  I tend to think that for the most successful company in the business to standardize on it is a pretty good testimony to it being well designed.
>
> This is a really bad argument. The facts that language is being used by a large companies does not make it well designed. See PHP, for example - a *horrible* mess of a language, but it is being used at Facebook.

From what I remember Andrei saying, they write their code in C++ and compile it to php, or something like that.

Besides, facebook was a pet project by a single person that accidentally grew into an empire.  Apple was around long before Steve Jobs brought Next Step OS (and it's usage of Objective-C) to Apple to become MacOS.  You can't really argue that Mac is a horrible OS, it may not suit your tastes, but it performs well.

Nick, please ignore this thread.

-Steve

On Thursday, 31 January 2013 at 14:28:39 UTC, Steven Schveighoffer wrote:
> On Thu, 31 Jan 2013 08:14:15 -0500, q66 <quaker66@gmail.com> wrote:
>
>> On Thursday, 31 January 2013 at 00:54:54 UTC, Steven Schveighoffer wrote:
>>> On Wed, 30 Jan 2013 03:05:37 -0500, q66 <quaker66@gmail.com> wrote:
>>>
>>>> On Wednesday, 30 January 2013 at 03:02:38 UTC, deadalnix wrote:
>>>>> On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
>>>>>> It deeply disturbs me that people even take the original post seriously.
>>>>>
>>>>> Well, you may give some arguments instead of no, just no, to convince people.
>>>>
>>>> It just gives another meaning to foo.bar, and ENFORCING camelCase by the language while lowercasing shit is just horrible. Anyone with a slightest trace of language design sense realizes that.
>>>
>>> Apparently not the designers of objective-C.
>>>
>>> -Steve
>>
>> Not contradictory, Objective-C is not a well designed language :)
>
> Now we're just name calling ;)  I tend to think that for the most successful company in the business to standardize on it is a pretty good testimony to it being well designed.  I certainly have grown fond of it, there are some really nice features in it.  But truly, xcode has played a large role in making the language seem good.
>
> As another option, what about changing my proposal so instead of setX, it's set_x, and then casing concerns are eliminated?  I think C++.net does that.
>
> -Steve

No, that is not a solution either. Any of these setBlah or set_blah or whatever are ugly hacks. There should be explicit property syntax. By explicit, I mean explicit - at least like C#'s get/set stuff (and I don't really like C# either).