View mode: basic / threaded / horizontal-split · Log in · Help
January 23, 2013
Make dur a property?
I was using dur, and as powerful as it is, I *hate* typing:

//----
Thread.sleep(dur!"msecs"(100));
//----

Then, this reminded me of an older thread I started:
Neat: UFCS for integer dot operator suffix
http://forum.dlang.org/thread/uchcycnsvykuojzhuokh@forum.dlang.org

And then it struct me:
//----
Thread.sleep(100.dur!"msecs");
//----

Yay! Or even better:
//----
alias msecs = dur!"msecs"
...
Thread.sleep(100.msecs); //Wow. Talk about expressive !!!
//----

Sweet-o! How much cooler can this get?

...

Well, if you are compiling with "-property", the compiler forces 
you to type:
//----
Thread.sleep(100.msecs());
//----

It is *almost* the same thing, but actually not the same at all. 
It shatters the "native" feeling of the suffix notation.

AFAIK, the "-property" switch enforces that non-property 
functions use parenthesis, so removing an "@property" attribute 
is potentially breaking. The opposite though is not so true. You 
can add @property to anything, and never break code.

...

So I thought I'd discuss: Would there be a reason to not make dur 
a property? This should impact no-one, but make ufcs usage that 
much more convenient. Can I get the go-ahead to make and document 
the change?

What about making things like msecs public aliases? How do you 
feel about that?
January 23, 2013
Re: Make dur a property?
On 01/23/2013 06:03 PM, monarch_dodra wrote:
> ...
>
> Well, if you are compiling with "-property", the compiler forces you to
> ...

So don't.

> AFAIK, the "-property" switch enforces that non-property functions use parenthesis, so removing an "@property" attribute is potentially breaking. The opposite though is not so true. You can add @property to anything, and never break code.

That is completely nonsensical behaviour. Just ignore -property.
January 23, 2013
Re: Make dur a property?
On 01/23/2013 09:13 AM, Timon Gehr wrote:
> On 01/23/2013 06:03 PM, monarch_dodra wrote:
>> ...
>>
>> Well, if you are compiling with "-property", the compiler forces you to
>> ...
>
> So don't.
>
>> AFAIK, the "-property" switch enforces that non-property functions use
>> parenthesis, so removing an "@property" attribute is potentially
>> breaking. The opposite though is not so true. You can add @property to
>> anything, and never break code.
>
> That is completely nonsensical behaviour. Just ignore -property.

+1.

Ali
January 23, 2013
Re: Make dur a property?
On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
> That is completely nonsensical behaviour. Just ignore -property.


Amen! -property MUST die. @property should fix the real problems 
with properties, not leave that broken while adding new problems.
January 23, 2013
Re: Make dur a property?
On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:
> On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
> >That is completely nonsensical behaviour. Just ignore -property.
> 
> 
> Amen! -property MUST die. @property should fix the real problems
> with properties, not leave that broken while adding new problems.

I'm starting to think that perhaps @property should be disposed of
completely. Just unify properties with nullary functions and be done
with it. There is no semantic difference between them anyway. (Didn't D1
used to do that?)

Compiling with -property also makes *compile-time* unary functions look
ridiculous:

	int ctfeFunc(int arg)() { return dotDotDotMagic(arg); }
	void main() {
		//int x = ctfeFunc!(123);	// doesn't work with -property!
		int x = ctfeFunc!(123)();	// looks ridiculous
	}


T

-- 
They say that "guns don't kill people, people kill people." Well I think
the gun helps. If you just stood there and yelled BANG, I don't think
you'd kill too many people. -- Eddie Izzard, Dressed to Kill
January 23, 2013
Re: Make dur a property?
23-Jan-2013 21:13, Timon Gehr пишет:
> On 01/23/2013 06:03 PM, monarch_dodra wrote:
>> ...
>>
>> Well, if you are compiling with "-property", the compiler forces you to
>> ...
>
> So don't.
>
>> AFAIK, the "-property" switch enforces that non-property functions use
>> parenthesis, so removing an "@property" attribute is potentially
>> breaking. The opposite though is not so true. You can add @property to
>> anything, and never break code.
>
> That is completely nonsensical behaviour. Just ignore -property.

+111

-- 
Dmitry Olshansky
January 23, 2013
Re: Make dur a property?
On Wednesday, January 23, 2013 18:03:19 monarch_dodra wrote:
> So I thought I'd discuss: Would there be a reason to not make dur
> a property? This should impact no-one, but make ufcs usage that
> much more convenient. Can I get the go-ahead to make and document
> the change?

No. It's not conceptually a property, so it shouldn't be marked with 
@property. It's a factory function.

> What about making things like msecs public aliases? How do you
> feel about that?

We have aliases already. If you don't like dur!"msecs"(100), you can do 
msecs(100). The same with days, minutes, etc.

- Jonathan M Davis
January 23, 2013
Re: Make dur a property?
On Wednesday, 23 January 2013 at 17:47:44 UTC, H. S. Teoh wrote:
> I'm starting to think that perhaps @property should be disposed 
> of completely.

There is a problem @property can potentially solve: a property 
returning a callable.

alias void delegate() Callable;

struct test {
   @property Callable foo() { ... }
}

test t;
Callable c = t.foo; // should work
t.foo(); // should call the returned function
t.foo()(); // this should NOT work


Currently, t.foo()() DOES work and t.foo() gives the callable, 
without actually calling it (i.e. does not work as it should).

-property and the current @property implementation do not even 
try to address this.




My preferred solution is:

1) all functions without @property work exactly the same way they 
do now (optional parenthesis, callable as setters with =)

2) all functions with @property are ALWAYS rewritten so that a 
reference to them instead references the return value and/or the 
setter function.

So the result would be similar to #define t.foo (t.foo()). The 
type system then takes care of the parenthesis - no special code 
is required for syntax.
January 23, 2013
Re: Make dur a property?
On Wed, 23 Jan 2013 18:03:19 +0100
"monarch_dodra" <monarchdodra@gmail.com> wrote:

> I was using dur, and as powerful as it is, I *hate* typing:
> 
> //----
> Thread.sleep(dur!"msecs"(100));
> //----
> 

I completely agree. It's absolutely hideous. And the flexibility of
having the unit be a template param is only rarely useful. What we *do*
fortunately have is these:

msecs(100)
hours(12)
days(30)
etc...

But beyond that, unfortunately, it's all been discussed before, and the
guy in charge of std.datetime is very strongly opposed to such changes
and feels that 'dur!"msecs"(100)' is great-looking. It was a ridiculous
uphill battle just to get the aliases above approved and included, and
even then the phobos devs rejected the portions of the pull request that
cleaned up phobos's internal usages of "durrrr" with the
vastly cleaner aliases. Such code cleanup was deemed to be pointless
and something to be avoided.


> 
> Well, if you are compiling with "-property", the compiler forces 
> you to type:
> //----
> Thread.sleep(100.msecs());
> //----
> 
> It is *almost* the same thing, but actually not the same at all. 
> It shatters the "native" feeling of the suffix notation.

The behavior *without* -property turned out to be a broken idea and the
*with* -property was created as the new replacement, intended to
deprecate the old ultimately-flawed behavior. Although that was a long
time ago and there seems to be a lot of reluctance to finally make the
switch because even the admins who admitted the change was necessary
are big fans of the old behavior.

Apparently, there's some fear about breaking code by making -propery
the default *as was always intended*. But that potential breakage was
the whole damn reason for adding the switch in the first place, as a
transitional measure (which has now become what, about a two year
"transition"?). Nevermind that we've had bigger breakages since then
that didn't even have any transition period, and we got by just fine.
January 23, 2013
Re: Make dur a property?
Am Wed, 23 Jan 2013 09:45:49 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:
> > On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
> > >That is completely nonsensical behaviour. Just ignore -property.
> > 
> > 
> > Amen! -property MUST die. @property should fix the real problems
> > with properties, not leave that broken while adding new problems.
> 
> I'm starting to think that perhaps @property should be disposed of
> completely.

Please do not forget the main reason for @property: Returning a
delegate from a function can become ambiguous without it:

int a(){return 42;}
void b() {return &a;}

auto var = b; //OK
auto var2 = b(); //is var2 == b or == 42?

It might be an extreme corner case, but it's inconsistent behavior and
confusing. Need a real-world example?
http://www.digitalmars.com/d/archives/digitalmars/D/ModuleInfo.unitTest_cannot_be_called_twice_183357.html
(with proper @property the first example should work as expected).

So if most people really think @property is such a problem we can
probably remove it, but we have to make sure examples like this one are
not ambiguous.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home