View mode: basic / threaded / horizontal-split · Log in · Help
January 23, 2013
Re: Make dur a property?
On 1/23/13 5:32 PM, Nick Sabalausky wrote:
> I'd rather not see more "Sometimes the language lets me skip XXXX, and
> sometimes it complains" get introduced into the language. That
> complicates the language and makes the language harder to understand.
>
> There are cases where that strategy has certainly made sense, but at
> this point I think you're just grasping for ways to justify leaving in
> the non-beneficial "Use either 'foo' or 'foo()', whichever you want,
> anytime you want" sloppiness. And making sure that non-feature can
> remain by introducing more special-cases into the language to patch
> over the problems with the non-feature.

UFCS has effectively buried the case for requiring parens.

Andrei
January 23, 2013
Re: Make dur a property?
On 1/23/13 5:40 PM, Nick Sabalausky wrote:
> On Wed, 23 Jan 2013 15:14:21 -0500
> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>
>> On 1/23/13 1:48 PM, Nick Sabalausky wrote:
>>> Having the *caller* decide whether something is a property or not
>>> makes as much sense as having the caller decide the function's name,
>>> signature and semantics.
>>
>> No. The caller does get to decide a variety of syntactic aspects of
>> the invocation.
>>
>
> Yes, but it's unfortunate that includes a part of the syntax that
> carries semantic/conceptual implications for something (action or
> data) that is already *inherently* determined by writer of the *callee*.

"Semantic" and "conceptual" sound interesting but are a bit out of 
context here. We're talking simple syntax here, and in particular an 
option available to other languages already.

>>> If anything, that's an issue with template syntax, it has nothing
>>> to do with properties, let alone the beloved practice of abusing
>>> properties for the sake of things that clearly are not properties.
>>
>> The implied assumption here is that if it doesn't have parens it's a
>> property. Well it's a function call.
>>
>
> Right, it's a function call. So what in the world do we gain by
> allowing the caller to make it look like something it isn't? Nothing.

Never answer your own rhetorical question :o).


Andrei
January 23, 2013
Re: Make dur a property?
On 1/23/13 5:46 PM, Adam D. Ruppe wrote:
> On Wednesday, 23 January 2013 at 22:24:20 UTC, Nick Sabalausky wrote:
>> that provides absolutely no useful value whatsoever.
>
> Do you think so many of us would be arguing for it and using it if it
> was of no value whatsoever?
>
>> Note that properties are *not* functions
>
> Indeed, which is why I separate out -property, a stupid waste of time,
> and @property, a good idea.
>
> Parenthesis and properties have nothing to do with each other. But when
> @property was proposed, we didn't talk about what it *is*
> (indistinguishable semantics from the return value), but instead what it
> *looks like* (must not be called with parenthesis).
>
> That's where all this pain comes from. Two separate features got
> intertwined due to a sloppy DIP.

We need a good DIP on this. UFCS has destroyed all arguments in favor of 
requiring parens. There is no question we must do this. Anyone inclined 
toward writing a detailed DIP?

Andrei
January 23, 2013
Re: Make dur a property?
On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
> On Wed, 23 Jan 2013 21:29:14 +0100
> Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>
>> On 1/23/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
>>> On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
>>> Amen! -property MUST die. @property should fix the real problems
>>> with properties, not leave that broken while adding new problems.
>>
>> About @property problems, I've recently ran into this:
>> ModuleInfo.unitTest is defined as
>>
>> @property void function() unitTest() nothrow pure;
>>
>> And if I use it:
>>
>>      foreach (m; ModuleInfo)
>>      {
>>          if (m is null)
>>              continue;
>>
>>          if (auto fp = m.unitTest)
>>          {
>>              fp();           // calls it
>>              m.unitTest();   // doesn't call it
>>              m.unitTest()(); // calls it
>>          }
>>      }
>>
>> This is regardless of the -property switch. I would expect the second
>> call to work. Anyone know if this is filed already?
>
> Don't know if it's filed, but yea: Optional empty-parens and
> the practice of conflating properties with functions is riddled with
> corner-cases. We can either try to patch over these corner cases
> with increasingly detailed new rules,

What are those "new" rules? The rules we already have are sufficient. 
Now the compiler needs to implement them properly.

> as Andrei is proposing, or we
> can just accept "the writing on the wall" (if you'll pardon my 80's-ism)
> that properties != functions.
>

That is not even the point of this discussion.

a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()
January 23, 2013
Re: Make dur a property?
On Wednesday, January 23, 2013 18:35:24 Andrei Alexandrescu wrote:
> UFCS has effectively buried the case for requiring parens.

Honestly, I'd love to require parens even with UFCS, but I think that it's 
clear that most folks want the parens to be optional for UFCS, and at this 
point, requiring parens would break a lot of code. So, even if it were 
generally agreed upon that it's a great idea to require them, the cost in code 
breakage would risk making the change unacceptable.

- Jonathan M Davis
January 24, 2013
Re: Make dur a property?
On Wed, 23 Jan 2013 18:39:49 -0500
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
> We need a good DIP on this. UFCS has destroyed all arguments in favor
> of requiring parens.

Uhh, how exactly?
January 24, 2013
Re: Make dur a property?
On Thu, 24 Jan 2013 00:30:43 +0100
Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 01/23/2013 11:40 PM, Nick Sabalausky wrote:
> > On Wed, 23 Jan 2013 15:14:21 -0500
> > Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> >
> >> On 1/23/13 1:48 PM, Nick Sabalausky wrote:
> >>> Having the *caller* decide whether something is a property or not
> >>> makes as much sense as having the caller decide the function's
> >>> name, signature and semantics.
> >>
> >> No. The caller does get to decide a variety of syntactic aspects of
> >> the invocation.
> >>
> >
> > Yes, but it's unfortunate that includes a part of the syntax that
> > carries semantic/conceptual implications for something (action or
> > data) that is already *inherently* determined by writer of the
> > *callee*.
> >
> 
> Keeping or leaving out the parens has no semantic implications.
> 

foo.bar() // Perform action
foo.bar   // Access data
January 24, 2013
Re: Make dur a property?
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
Alexandrescu wrote:
> We need a good DIP on this. [snip]

DIPs are good in theory but I think the process really needs to 
be formalized.  In the past 3 years there have been thirteen DIPs 
with only one being approved and implemented.  Perhaps 12 of 
those really weren't good enough to pursue but, upon looking at 
some of the proposals I really like, I think it's probably more 
the case that they get proposed and then the community forgets 
about them.  DIPs seem to be the place where good ideas go to die.

I think just applying the phobos module review process to DIPs 
would help a lot (although that process suffers from a lack of 
initiative in actually running reviews but I think that's 
something that can be overcome).  It'd force the community to 
make a yea or nay decision instead of just letting them languish 
in the wiki.

BA
January 24, 2013
Re: Make dur a property?
On Wed, 23 Jan 2013 18:38:11 -0500
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/23/13 5:40 PM, Nick Sabalausky wrote:
> > On Wed, 23 Jan 2013 15:14:21 -0500
> > Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
> >
> >> On 1/23/13 1:48 PM, Nick Sabalausky wrote:
> >>> Having the *caller* decide whether something is a property or not
> >>> makes as much sense as having the caller decide the function's
> >>> name, signature and semantics.
> >>
> >> No. The caller does get to decide a variety of syntactic aspects of
> >> the invocation.
> >>
> >
> > Yes, but it's unfortunate that includes a part of the syntax that
> > carries semantic/conceptual implications for something (action or
> > data) that is already *inherently* determined by writer of the
> > *callee*.
> 
> "Semantic" and "conceptual" sound interesting but are a bit out of 
> context here. We're talking simple syntax here, and in particular an 
> option available to other languages already.
> 

I realize that you think properties are purely a syntactic matter, but
that misunderstanding is the heart of the problem. You're thinking "Do
I feel like calling this function with or without parens?" That's
completely wrong and demonstrates a continued misunderstanding of
properties.

The real question is "Is this an action or data?" (And obviously I mean
when viewed from outside the encapsulation, I don't mean the
implementation.) Note that the answer to that question is NOT
subjective to the context of the caller, only the callee. Blindly
discounting the "conceptual" matter (ie "action or data?") is a
convenient way contort the issue so that it fits back into the "Call
with/without parens?" strawman.

There have already been enough problems shown that have arisen as a
direct result of mistreating the matter of properties as merely
an "optional paren" syntax matter. You suggest various additional rules
to patch over those symptoms, but when you consider the very simple,
time-honored, and frankly very very common, association of:

foo.bar() // Perform action
foo.bar   // Read/Write data

Then you'll notice that all those edge cases created by the "optional
paren" mindset simply vanish as natural straightforward consequences of
the above rule. No need for any additional rules or "sometimes
required, sometimes optional" puzzles.

This is a problem that other languages have *already* solved, with
well-known, well-understood solutions (ie: the "action==paren,
data==no parem" rule). Unfortunately, despite the readily available
solution, D is still trying to wrap its head around the matter, and
winds up flailing around in a sea of issues because it is (you are)
desperately clinging to the failed (ie: it creates problems) and
unimportant notion of "No matter what happens with properties, I *must*
be able to decide on a whim whether I feel like calling a particular
func with or without parans". Try detaching from that desire for a while
and explore it plays out.


> >>> If anything, that's an issue with template syntax, it has nothing
> >>> to do with properties, let alone the beloved practice of abusing
> >>> properties for the sake of things that clearly are not properties.
> >>
> >> The implied assumption here is that if it doesn't have parens it's
> >> a property. Well it's a function call.
> >>
> >
> > Right, it's a function call. So what in the world do we gain by
> > allowing the caller to make it look like something it isn't?
> > Nothing.
> 
> Never answer your own rhetorical question :o).
> 

I think there's also another overrated rule that prohibits use of the
word "you" ;)

But fine:

"Right, it's a function call. So what in the world do we gain by
allowing the caller to make it look like something it isn't?"
January 24, 2013
Re: Make dur a property?
Nick Sabalausky:

> This is a problem that other languages have *already* solved, 
> with
> well-known, well-understood solutions (ie: the "action==paren,
> data==no parem" rule). Unfortunately, despite the readily 
> available
> solution, D is still trying to wrap its head around the matter, 
> and
> winds up flailing around in a sea of issues because it is (you 
> are)
> desperately clinging to the failed (ie: it creates problems) and
> unimportant notion of "No matter what happens with properties, 
> I *must*
> be able to decide on a whim whether I feel like calling a 
> particular
> func with or without parans". Try detaching from that desire 
> for a while
> and explore it plays out.

+1 :-)

Bye,
bearophile
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home