Jump to page: 1 213  
Page
Thread overview
Make dur a property?
Jan 23, 2013
monarch_dodra
Jan 23, 2013
Timon Gehr
Jan 23, 2013
Ali Çehreli
Jan 23, 2013
Adam D. Ruppe
Jan 23, 2013
H. S. Teoh
Jan 23, 2013
Adam D. Ruppe
Jan 23, 2013
Johannes Pfau
Jan 23, 2013
Adam D. Ruppe
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Dmitry Olshansky
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Adam D. Ruppe
Jan 23, 2013
Adam D. Ruppe
Jan 23, 2013
Johannes Pfau
Jan 23, 2013
Adam D. Ruppe
Jan 23, 2013
Jacob Carlborg
Jan 23, 2013
Adam D. Ruppe
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Adam D. Ruppe
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
Brad Anderson
Jan 24, 2013
Jacob Carlborg
Jan 24, 2013
monarch_dodra
Jan 24, 2013
monarch_dodra
Jan 24, 2013
David Nadlinger
Jan 24, 2013
Jonathan M Davis
Jan 24, 2013
Johannes Pfau
Jan 24, 2013
Jonathan M Davis
Jan 24, 2013
deadalnix
Jan 24, 2013
Maxim Fomin
Jan 24, 2013
deadalnix
Jan 24, 2013
Maxim Fomin
Jan 24, 2013
deadalnix
Jan 25, 2013
deadalnix
Jan 23, 2013
Johannes Pfau
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Jonathan M Davis
Jan 23, 2013
Jacob Carlborg
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Timon Gehr
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
Jacob Carlborg
Jan 24, 2013
Johannes Pfau
Jan 24, 2013
Timon Gehr
Jan 25, 2013
Johannes Pfau
Jan 25, 2013
Timon Gehr
Jan 25, 2013
mist
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
Timon Gehr
Jan 25, 2013
Jacob Carlborg
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
bearophile
Jan 24, 2013
Dmitry Olshansky
Jan 25, 2013
deadalnix
Jan 25, 2013
Nick Sabalausky
Jan 25, 2013
Dmitry Olshansky
Jan 26, 2013
Jacob Carlborg
Jan 26, 2013
Nick Sabalausky
Jan 26, 2013
Jacob Carlborg
Jan 24, 2013
.
Jan 23, 2013
Jacob Carlborg
Jan 23, 2013
Andrej Mitrovic
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Timon Gehr
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
Jonathan M Davis
Jan 24, 2013
Timon Gehr
Jan 23, 2013
Adam D. Ruppe
Jan 23, 2013
anonymous
Jan 23, 2013
anonymous
Jan 23, 2013
Dmitry Olshansky
Jan 23, 2013
Jonathan M Davis
Jan 23, 2013
monarch_dodra
Jan 23, 2013
Brad Anderson
Jan 23, 2013
Nick Sabalausky
Jan 23, 2013
Jacob Carlborg
Jan 23, 2013
Jonathan M Davis
Jan 23, 2013
Jacob Carlborg
Jan 23, 2013
Jonathan M Davis
Jan 23, 2013
Timon Gehr
Jan 24, 2013
Nick Sabalausky
Jan 23, 2013
monarch_dodra
Jan 23, 2013
Timon Gehr
Jan 23, 2013
Adam D. Ruppe
[OT] Affect of typing styles on coding style (Was: Make dur a property?)
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
Jacob Carlborg
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
Adam D. Ruppe
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
monarch_dodra
Jan 24, 2013
Jonathan M Davis
Jan 24, 2013
Tommi
Jan 24, 2013
deadalnix
Jan 25, 2013
Timon Gehr
Jan 25, 2013
deadalnix
Jan 25, 2013
Jacob Carlborg
Jan 24, 2013
Simen Kjaeraas
Jan 24, 2013
Jacob Carlborg
Jan 24, 2013
monarch_dodra
Jan 24, 2013
Jacob Carlborg
Jan 23, 2013
Nick Sabalausky
Jan 24, 2013
Jacob Carlborg
Jan 24, 2013
Nick Sabalausky
Jan 24, 2013
Timon Gehr
Jan 23, 2013
Mike Wey
Jan 23, 2013
Nick Sabalausky
Jan 24, 2013
Jacob Carlborg
Jan 24, 2013
Dmitry Olshansky
January 23, 2013
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
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
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
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
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
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
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
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
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
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 6 7 8 9 10 11