January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to anonymous | On Thursday, 24 January 2013 at 09:03:45 UTC, anonymous wrote:
> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
>> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>>
>> Perhaps we should revert to a simple set of rules.
> [...]
>> 4. No more @property.
>
> You went half the way and now you're tired. Going back will be just as painful as going all the way.
> I say, keep @property and fix it.
+1
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote:
> I want to get rid of @property. It's an eyesore.
Yes!
And on falling flat on that please rethink uglinesses like `writefln'. Such mangling of values of parameters into the identifiers of procedures might kill maintainability. Or: is everyone able to "see" the values hidden in several of such appendices coming from several libraries written by several coders?
writefln, seefln, grabfln, killfln!
`write( format="%s", someExpression, eol);' is in fact longer than
`writefln( "%s", someExpression);'
Really?
-manfred
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | I am probably I minority here but I liked the most strict -property version and it made a lot of sense to me. Rationale is simple: some().ufcs().chaining(); - this is just a minor syntax inconvenience anything; - this drives me crazy, there is no way to understand if this a no-op statement variable of function call with some side-effect I'd really like to have all function types to be obliged to use () and use property syntax only to those of property semantics (no side-effect variable getter/setter) But looking at other comments this does not seem popular :( Well, I can only hope for something simple and non-revolutionary then. |
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return value taking (), the () go on the return value.
>
> 2. the:
> f = g
> rewrite to:
> f(g)
> only happens if f is a function that only has overloads for () and (one argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.
This is lazy design, plain and simple. You say it's turned into
a monster, but @property, at its core, is simpler than the heuristics
you've demonstrated here. To my mind, @property, properly implemented
is simple:
@property functions may be called with no parens or with assignment as
the singular argument. Non @property functions may not.
There. No complications. The only complications come from D's history.
And then you want to turn it back? This seems a terrible idea -- the
deed is done, pull the trigger. Make @property mandatory for property
functions.
-Bernard.
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bernard Helyer | Bernard Helyer:
> To my mind, @property, properly implemented is simple:
>
> @property functions may be called with no parens or with assignment as
> the singular argument. Non @property functions may not.
>
> There. No complications.
Sounds OK.
Instead of adding a -property, why wasn't this done since the beginning? (The right switch to add was -noproperty, to disable the feature, because most people do not use switches).
Bye,
bearophile
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 2013-01-24 13:35, bearophile wrote: > Instead of adding a -property, why wasn't this done since the beginning? It would break tons of code. -- /Jacob Carlborg |
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | Jacob Carlborg:
> It would break tons of code.
How much work does it take to change that makes and compilation scripts to compile that code using a "-noproperty" switch?
I think this silly fear of breaking user code was one of the main causes of the failure of @property in the first place. If you introduce a new feature, then you need to introduce it cleanly since the beginning, otherwise you will make a mess. So future D feature must be introduced in a much more clean way in future, or not introduced at all.
Bye,
bearophile
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Thursday, 24 January 2013 at 12:53:45 UTC, Jacob Carlborg wrote:
> On 2013-01-24 13:35, bearophile wrote:
>
>> Instead of adding a -property, why wasn't this done since the beginning?
>
> It would break tons of code.
And yet it must have been done at some point. With some year-ahead announcement or anything like that, but it was a horrible design error in first place which needs to be fixed.
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> 4. No more @property.
Looks fine for me. D2 code is better but sometimes so much
noisier than D1. There, I said it.
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to mist | mist:
> but it was a horrible design error in first place
> which needs to be fixed.
Don't forget that our discussions in this thread are mostly academic :-)
Bye,
bearophile
|
Copyright © 1999-2021 by the D Language Foundation