View mode: basic / threaded / horizontal-split · Log in · Help
November 19, 2012
Re: @property needed or not needed?
On 11/19/12 12:30 PM, Michel Fortin wrote:
> On 2012-11-19 06:52:11 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> said:
>
>> On 11/19/12 1:02 AM, Rob T wrote:
>>> So what's up with @property?
>>
>> It's a mistake on top of another. We need to redesign it to such that
>> the keyword '@property' is only required in cases that otherwise would
>> be ambiguous (functions returning functions).
>
> …or functions returning a type with an opCall.
>
> What about template functions with a parametrized return type that will
> sometime be ambiguous and sometime not depending on the template
> parameters?
>

Let's put all of these cases in a DIP so we can analyze them.

Thanks,

Andrei
November 19, 2012
Re: @property needed or not needed?
Why don't we just outright disallow expression-statements?

After all,

     2 + 3;

should not be a valid statement, and so

     foo.property;

should not be, either.
November 19, 2012
Re: @property needed or not needed?
11/19/2012 9:58 PM, monarch_dodra пишет:
> On Monday, 19 November 2012 at 17:42:28 UTC, Dmitry Olshansky wrote:
>> 11/19/2012 7:18 PM, monarch_dodra пишет:
>>> On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
>>>> On 11/19/12 4:01 AM, monarch_dodra wrote:
>>>>> I kind of agree with Jonathan here. @property really shines when you
>>>>> want to "add" an attribute to a struct.
>>>>
>>>> I kind of agree with him, too, but it would be a mistake to not reckon
>>>> a change in dynamics. UFCS makes all those extra parens just awkward,
>>>> and people will vote with their code regardless whether some
>>>> particular viewpoint from some particular angle considers the approach
>>>> backwards.
>>>>
>>>> Andrei
>>>
>>> One of the things that we may want to take into account, is that
>>> -property prevents any existing function from migrating to/from
>>> property. For example, if we want to make "retro" a property, we can't
>>> without breaking any and all UFCS usage of retro.
>>>
>>
>> The major problem about @property enforcement as it stands is that it
>> breaks the duality of things like retro:
>> a.retro
>> vs
>> retro(a)
>>
>> Both should be allowed as it's a matter of taste that shouldn't be
>> enforced. A lot of new code uses a.retro and a lot of older code uses
>> retro(a).
>>
>> If retro is property then only the first one compiles
>> If retro is a function then only the second one compiles.
>>
>> Which obviously means @property has to be reconsidered.
>
> Hum... Perhaps you meant:
> a.retro
> vs
> a.retro()

This one too.

> Because "retro(a)" works regardless of the property.

Hm.. being a while since I tried to use -property switch. I thought it 
was also disallowed. Not so bad then I guess.

Looking forward to DIP21.


-- 
Dmitry Olshansky
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 18:02:06 UTC, Adam D. Ruppe wrote:
> On Monday, 19 November 2012 at 15:01:36 UTC, Andrei 
> Alexandrescu wrote:
>> Would you please start a DIP with a paste of this idea?
>
> here it is:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21

Thanks a lot for doing this! It's a pity that the last bigger 
discussion didn't lead anywhere, I don't think there was much 
disagreement. Hopefully, having a DIP to discuss will catalyze 
the process a bit.

David
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 18:21:55 UTC, Mehrdad wrote:
> Why don't we just outright disallow expression-statements?
>
> After all,
>
>      2 + 3;
>
> should not be a valid statement, and so
>
>      foo.property;
>
> should not be, either.

 Hmmm I would say if it's const/immutable and pure then it would 
be an error (Side effects considered after all), otherwise 
popFront may not work (it is a property I believe...right?).

 So let's assume I make some struct to call the PC Speaker (for 
whatever reason) then the following would break.

struct PCSpeaker {
  int dingsCalled;
  void ding() @property {
    dingsCalled++;
    //some low level calls
  }
}

 However if it was...

  void ding() @property const pure

 We know there's no side effects (and it can't modify the 
struct), which then 'ding' could be an error on it's own 
(Although without a return value that would make the signature 
completely useless).
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 18:58:21 UTC, Era Scarecrow wrote:
> On Monday, 19 November 2012 at 18:21:55 UTC, Mehrdad wrote:
>> Why don't we just outright disallow expression-statements?
>>
>> After all,
>>
>>     2 + 3;
>>
>> should not be a valid statement, and so
>>
>>     foo.property;
>>
>> should not be, either.
>
>  Hmmm I would say if it's const/immutable and pure then it 
> would be an error (Side effects considered after all), 
> otherwise popFront may not work (it is a property I 
> believe...right?).

... wrong ;)

front is a property. popFront is a method.

>  So let's assume I make some struct to call the PC Speaker (for 
> whatever reason) then the following would break.
>
> struct PCSpeaker {
>   int dingsCalled;
>   void ding() @property {
>     dingsCalled++;
>     //some low level calls
>   }
> }
>
>  However if it was...
>
>   void ding() @property const pure
>
>  We know there's no side effects (and it can't modify the 
> struct), which then 'ding' could be an error on it's own 
> (Although without a return value that would make the signature 
> completely useless).

You could argue that since a property-function is meant to 
emulate an attribute, that calling one and doing nothing is 
*always* wrong, regardless of side effect. I mean, in the sense 
that doing the side effect would make no sense if there is no 
consumer for the side effect in question.

Back to retro: I think that it actually could be an attribute. In 
that case, when you write:

a.retro;

then there is no consumer, and it creates a compile error.

After thinking about more, I think a great definition of property 
would be "a function that returns a value that *must* be 
consumed". This would give it more power than the mere 
parenthesis, no-parenthesis status: Imagine "chain" 
property-attributed. In that case:

chain(a, b);

This would fail to compile, because there is no consumer for 
chain, regardless of side effect...
November 19, 2012
Re: @property needed or not needed?
On Monday, November 19, 2012 21:42:25 Dmitry Olshansky wrote:
> 11/19/2012 7:18 PM, monarch_dodra пишет:
> > On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
> >> On 11/19/12 4:01 AM, monarch_dodra wrote:
> >>> I kind of agree with Jonathan here. @property really shines when you
> >>> want to "add" an attribute to a struct.
> >> 
> >> I kind of agree with him, too, but it would be a mistake to not reckon
> >> a change in dynamics. UFCS makes all those extra parens just awkward,
> >> and people will vote with their code regardless whether some
> >> particular viewpoint from some particular angle considers the approach
> >> backwards.
> >> 
> >> Andrei
> > 
> > One of the things that we may want to take into account, is that
> > -property prevents any existing function from migrating to/from
> > property. For example, if we want to make "retro" a property, we can't
> > without breaking any and all UFCS usage of retro.
> 
> The major problem about @property enforcement as it stands is that it
> breaks the duality of things like retro:
> a.retro
> vs
> retro(a)
> 
> Both should be allowed as it's a matter of taste that shouldn't be
> enforced. A lot of new code uses a.retro and a lot of older code uses
> retro(a).
> 
> If retro is property then only the first one compiles
> If retro is a function then only the second one compiles.
> 
> Which obviously means @property has to be reconsidered.

The thing is that if @property is really an abstraction for variables, then it 
_doesn't_ make sense to allow both, because it's _not_ a matter of taste. 
Either it's a variable, or it's a function. Not both. And if it's a variable, 
then obviously no parens should be used with it. And if it's a function, then 
obviously parens should be used with it.

If you're viewing it as just a way to not have to use parens on functions, 
then that's something else entirely. And if that's what we're looking to 
support, then using @property for that makes no sense at all.

Personally, I hate the fact it's legal to have any kind of optional parens. I 
think that it's incredibly sloppy and goes against the abstractions of 
variables and functions. I'm all for forcing the full set of parens in a long 
chain of UFCS. But clearly plenty of other folks don't agree.

Because of all of those folks, it may make sense to make it so that parens are 
optional on functions but are outright verboten on @property functions. That 
way, anyone wanting to use @property for actual properties can do so with 
proper enforcement, but those who want to just leave parens off of normal 
function calls can. I really don't like the idea, but at this point, I think 
that it's fairly clear that there are a lot of people who _like_ the sloppy 
nature of being able to leave parens off much as a number of the rest of us 
hate it.

- Jonathan M Davis
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 20:04:24 UTC, Jonathan M Davis 
wrote:
> The thing is that if @property is really an abstraction for 
> variables, then it
> _doesn't_ make sense to allow both, because it's _not_ a matter 
> of taste.
> Either it's a variable, or it's a function. Not both. And if 
> it's a variable,
> then obviously no parens should be used with it. And if it's a 
> function, then
> obviously parens should be used with it.

That makes perfect sense to me if that's what the meaning of 
@property is supposed to be, and if so then it can constrain the 
usage to that of a variable, which currently is not the case.

> If you're viewing it as just a way to not have to use parens on 
> functions,
> then that's something else entirely. And if that's what we're 
> looking to
> support, then using @property for that makes no sense at all.

That makes sense to me as well, and indicates that the @property 
topic is getting mixed up with another topic, which concerns the 
optional use of () for empty parameter lists.

What may be forgotten, is that we currently have the ability to 
not only drop the (), but also to perform optional assignments, 
eg Foo = 23;, without defining a function Foo to be @property.

In one case we're talking about variable abstractions, and in 
another case we're talking about simply making () optional, these 
are two entirely separate topics that are mangled up together.

I think you understand this already, but perhaps not everyone 
else does.

To further complicate things, I find that when deciding to define 
a function as @property or not is like trying to decide if Pluto 
is a planet or not, it's often not clear which way you should go, 
and that may be why I really did enjoy not having to specify 
@property to make use of the semantics it (was supposed to) 
provide when and where I saw fit to do so.

> Personally, I hate the fact it's legal to have any kind of 
> optional parens. I
> think that it's incredibly sloppy and goes against the 
> abstractions of
> variables and functions. I'm all for forcing the full set of 
> parens in a long
> chain of UFCS. But clearly plenty of other folks don't agree.

I seriously don't think you should try to constrain coding style, 
instead it makes much more sense to provide the user with a means 
to constrain it themselves as they see fit. Look at languages 
that constrain coding style too much vs languages that don't, and 
consider the popularity among them.

My two cents :)

--rt
November 19, 2012
Re: @property needed or not needed?
On Monday, November 19, 2012 22:04:02 Rob T wrote:
> I seriously don't think you should try to constrain coding style,
> instead it makes much more sense to provide the user with a means
> to constrain it themselves as they see fit. Look at languages
> that constrain coding style too much vs languages that don't, and
> consider the popularity among them.

Excep that i don't think that it's really a question of style. It's treating a 
function as if it were a variable, when it's not only not a variable, but it's 
not even acting like one. It's implying that the code has one set of semantics 
when it has another. Dropping parens when specifically creating a function 
which is intended to emulate a variable makes sense. But dropping parens just 
because you feel like it then makes a function look like a variable when it's 
not and not intended to even act like one. That violates the very difference 
between function and variable on even a conceptual level. It would be one 
thing to make a particular character or sequence of characters optional when 
doing so doesn't make it look like it's something else entirely  (e.g. 
optional braces don't make anything look like anything else - they just drop 
some characters, and they don't introduce any ambiguities in the process). But 
it's quite another to make those characters optional when they make one 
language construct look like another.

- Jonathan M Davis
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 20:00:27 UTC, monarch_dodra wrote:
> You could argue that since a property-function is meant to 
> emulate an attribute, that calling one and doing nothing is 
> *always* wrong, regardless of side effect.


That's EXACTLY what I'm saying.

    foo.property;

is ALWAYS wrong semantically speaking, regardless of what it 
_could_ or _happens_ to do if it was/is defined.
So even if popFront() was a property, my point would be that it 
should not be a property in the first place.



It's like saying you should be able to add integers and function 
pointers just because they're both integers underneath.

Sure, the machine can do it, but we disallow it because it makes 
no sense.

Ditto here.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home