View mode: basic / threaded / horizontal-split · Log in · Help
December 13, 2011
Re: Fixing const arrays
On 12/13/2011 01:08 AM, Steven Schveighoffer wrote:
> On Mon, 12 Dec 2011 19:00:35 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
>>> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
>>>> Insisting on the current property semantics was a sizeable mistake of
>>>> this community, and I am sorry we gave into it.
>>>
>>> Aside from the fact that the behavior of -property isn't the default,
>>> what's
>>> the problem with @property?
>>
>> Other than it being completely useless, requiring more rote
>> memorization, and fomenting time-wasting discussion? None.
>
> Wait, are we talking about @property or .save?
>
> -Steve

definitely @property.
December 13, 2011
Re: Fixing const arrays
On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
> > On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
> >> Insisting on the current property semantics was a sizeable mistake of
> >> this community, and I am sorry we gave into it.
> > 
> > Aside from the fact that the behavior of -property isn't the default,
> > what's the problem with @property?
> 
> Other than it being completely useless, requiring more rote
> memorization, and fomenting time-wasting discussion? None.

So, you prefer the situation where any function with no arguments can be used 
as a getter and any function with a single argument can be used as a setter? 
Not only is that incredibly lax, but it makes it impossible to be able to 
switch between public member variables and property functions without breaking 
code, which is supposed to be one of the main purposes of property functions 
in programming languages in general. With @property, such a switch _is_ 
possible (aside from a few corner cases such as when someone takes the address 
of a public member variable). It will also lead to a consistent use of 
parentheses instead of having the syntax used with a function varying wherever 
it's used.

Sure, you then get arguments over whether a function should be a property or 
not, but that's generally just part of the discussion of how to name a 
function, and with that, there's always risk that someone will disagree later, 
so I'm not sure that it makes the situation all that much worse, and IMHO it's 
well worth the advantage of having proper properties. What D had was better 
than nothing, but it was inconsistent and lacked the ability to swap member 
variables and property functions, which made it far worse than @property IMHO.

- Jonathan M Davis
December 13, 2011
Re: Fixing const arrays
On 12/13/11 10:32 AM, Jonathan M Davis wrote:
> On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
>> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
>>> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
>>>> Insisting on the current property semantics was a sizeable mistake of
>>>> this community, and I am sorry we gave into it.
>>>
>>> Aside from the fact that the behavior of -property isn't the default,
>>> what's the problem with @property?
>>
>> Other than it being completely useless, requiring more rote
>> memorization, and fomenting time-wasting discussion? None.
>
> So, you prefer the situation where any function with no arguments can be used
> as a getter and any function with a single argument can be used as a setter?

No. That would be a false choice.

Andrei
December 13, 2011
Re: Fixing const arrays
On Tuesday, December 13, 2011 14:02:51 Andrei Alexandrescu wrote:
> On 12/13/11 10:32 AM, Jonathan M Davis wrote:
> > On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
> >> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
> >>> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
> >>>> Insisting on the current property semantics was a sizeable mistake
> >>>> of
> >>>> this community, and I am sorry we gave into it.
> >>> 
> >>> Aside from the fact that the behavior of -property isn't the
> >>> default,
> >>> what's the problem with @property?
> >> 
> >> Other than it being completely useless, requiring more rote
> >> memorization, and fomenting time-wasting discussion? None.
> > 
> > So, you prefer the situation where any function with no arguments can be
> > used as a getter and any function with a single argument can be used as
> > a setter?
> No. That would be a false choice.

I'm not saying that those are the only choices, but you seem to think that the 
current situation is worse than what we had before, which I don't understand. 
The current situation looks all around better to me.

- Jonathan M Davis
December 13, 2011
Re: Fixing const arrays
On Tuesday, December 13, 2011 12:25:12 Jonathan M Davis wrote:
> On Tuesday, December 13, 2011 14:02:51 Andrei Alexandrescu wrote:
> > On 12/13/11 10:32 AM, Jonathan M Davis wrote:
> > > On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
> > >> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
> > >>> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
> > >>>> Insisting on the current property semantics was a sizeable
> > >>>> mistake
> > >>>> of
> > >>>> this community, and I am sorry we gave into it.
> > >>> 
> > >>> Aside from the fact that the behavior of -property isn't the
> > >>> default,
> > >>> what's the problem with @property?
> > >> 
> > >> Other than it being completely useless, requiring more rote
> > >> memorization, and fomenting time-wasting discussion? None.
> > > 
> > > So, you prefer the situation where any function with no arguments
> > > can be used as a getter and any function with a single argument can
> > > be used as a setter?
> > 
> > No. That would be a false choice.
> 
> I'm not saying that those are the only choices, but you seem to think that
> the current situation is worse than what we had before, which I don't
> understand. The current situation looks all around better to me.

In fact, what _would_ you prefer to @property if it's not what we had before?

- Jonathan M Davis
December 13, 2011
Re: Fixing const arrays
On 12/13/11 2:25 PM, Jonathan M Davis wrote:
> On Tuesday, December 13, 2011 14:02:51 Andrei Alexandrescu wrote:
>> On 12/13/11 10:32 AM, Jonathan M Davis wrote:
>>> On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
>>>> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
>>>>> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
>>>>>> Insisting on the current property semantics was a sizeable mistake
>>>>>> of
>>>>>> this community, and I am sorry we gave into it.
>>>>>
>>>>> Aside from the fact that the behavior of -property isn't the
>>>>> default,
>>>>> what's the problem with @property?
>>>>
>>>> Other than it being completely useless, requiring more rote
>>>> memorization, and fomenting time-wasting discussion? None.
>>>
>>> So, you prefer the situation where any function with no arguments can be
>>> used as a getter and any function with a single argument can be used as
>>> a setter?
>> No. That would be a false choice.
>
> I'm not saying that those are the only choices, but you seem to think that the
> current situation is worse than what we had before, which I don't understand.
> The current situation looks all around better to me.

There's a phrase in Romanian that quite applies: "From the lake into the 
well".

Andrei
December 13, 2011
Re: Fixing const arrays
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu 
wrote:
> There's a phrase in Romanian that quite applies: "From the lake 
> into the well".

I believe the English version is "Out of the frying pan, into the 
fire" :)

Inconsequential space-filler opinion: I am OK with @property, 
mainly because it's a common feature among PLs, it's better than 
nothing, and don't know better solutions.
December 13, 2011
Re: Fixing const arrays
On Monday, 12 December 2011 at 15:32:05 UTC, Jakob Ovrum wrote:
> (Unrelated side-note: I am using the web interface and I'm not 
> well seasoned with using newsgroups, is there a better way to 
> reply to multiple small posts than replying to each 
> individually like I just did? I apologize if I'm being spammy.)

I don't think that's a problem.

But to answer your question, no. The next best thing is to reply 
to the posts' common parent, or the thread's first post. Cite 
authors preserving the name/timestamp line and relevant quoted 
context.
December 13, 2011
Re: Fixing const arrays
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
> On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote:
>> There's a phrase in Romanian that quite applies: "From the lake into
>> the well".
>
> I believe the English version is "Out of the frying pan, into the fire" :)
>
> Inconsequential space-filler opinion: I am OK with @property, mainly
> because it's a common feature among PLs, it's better than nothing, and
> don't know better solutions.

In my opinion, it's not better than nothing.

What it gives you:

1. A bit of syntactic sugar.
2. The ability to refactor member look up easily.

What it costs:

1. Overloads syntax.
 a. obj.field can now be an arbitrary function call.
 b. May have arbitrary cost (e.g. T[].length)
2. Complicating the language (proof: this discussion)
3. Another thing to learn.
4. Another thing for tools to process.


I don't think the syntax sugar it provides counts for anything really.

The ability to refactor member look ups is nice, but I find that this 
rarely occurs in practice and even when it occurs, it's not hard to 
replace obj.field with obj.field() or obj.getField().

The costs far outweigh the benefits IMO.
December 13, 2011
Re: Fixing const arrays
On 12/13/11 5:14 PM, Peter Alexander wrote:
> On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
>> On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote:
>>> There's a phrase in Romanian that quite applies: "From the lake into
>>> the well".
>>
>> I believe the English version is "Out of the frying pan, into the
>> fire" :)
>>
>> Inconsequential space-filler opinion: I am OK with @property, mainly
>> because it's a common feature among PLs, it's better than nothing, and
>> don't know better solutions.
>
> In my opinion, it's not better than nothing.
>
> What it gives you:
>
> 1. A bit of syntactic sugar.
> 2. The ability to refactor member look up easily.
>
> What it costs:
>
> 1. Overloads syntax.
> a. obj.field can now be an arbitrary function call.
> b. May have arbitrary cost (e.g. T[].length)
> 2. Complicating the language (proof: this discussion)
> 3. Another thing to learn.
> 4. Another thing for tools to process.
>
>
> I don't think the syntax sugar it provides counts for anything really.
>
> The ability to refactor member look ups is nice, but I find that this
> rarely occurs in practice and even when it occurs, it's not hard to
> replace obj.field with obj.field() or obj.getField().
>
> The costs far outweigh the benefits IMO.

We could have inferred property intention from the code pattern, without 
requiring any keyword. That solution (which was discussed and rejected 
in this newsgroup) was miles ahead from the drivel of @property we have now.

I noticed there's a tunnel vision phenomenon when it comes to 
keyword-based solutions: once a special notation is on the table, 
there's no appreciation for anything else. That's what happened with 
lazy (another design misfire I'm very unhappy about) and with @property. 
I literally feel my heart rate getting up when I think of them.


Andrei
5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home