View mode: basic / threaded / horizontal-split · Log in · Help
January 23, 2013
Re: Make dur a property?
On Wednesday, 23 January 2013 at 19:18:09 UTC, Johannes Pfau 
wrote:
> int DG() {return 42};
> int delegate() getDG() {return &DG};
>
> auto dg = getDG; //OK
> auto ??? = getDG();
>
> The last line could be a call to getDG with optional 
> parenthesis,
> so ??? = DG. Or it could be a call to getDG without optional
> parenthesis and a call to the returned DG, so ??? = 42.

If getDG is a @property, ??? == 42, because getDG() is rewritten 
into (getDG())() - parens there would ALWAYS mean "call the 
return value", so any @property is indistinguishable from its 
return value. (if we get @property like I want)

Without @property, it'd return DG because while parenthesis are 
optional, if they are present, they always apply to the preceding 
thing directly; getDG == getDG() in all cases. (This is the 
status quo, which I'd retain)


The type system will help catch errors here better than the 
syntax.
January 23, 2013
Re: Make dur a property?
On Wednesday, 23 January 2013 at 19:29:44 UTC, Nick Sabalausky 
wrote:
> int foo() {...}
> int delegate() {...} bar;
>
> auto x = foo; // call it
> auto y = bar; // don't call it

I don't have a problem with that because delegates and functions 
are different beasts anyway. For one major example, you can't 
rebind a function, but you can rebind a delegate, so "bar" has a 
meaning that "foo" doesn't (and &bar and &foo are different 
beasts too, one is address of a (rebindable) pointer, the other 
is address of a function, so they won't match up either).
January 23, 2013
Re: Make dur a property?
On 1/23/13 1:18 PM, Johannes Pfau wrote:
> 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.

Agreed. I think we should require @property only for those cases, and 
not any others.

Andrei
January 23, 2013
Re: Make dur a property?
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.

> 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.


Andrei
January 23, 2013
Re: Make dur a property?
On Wednesday, 23 January 2013 at 18:02:05 UTC, Jonathan M Davis 
wrote:
> 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.
>

I agree. It's important we don't conflate properties with 
parentheses-less calling.  They are two separate things.

I want to be able to call without parentheses but we shouldn't 
abuse @property to accomplish it.

BA
January 23, 2013
Re: Make dur a property?
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?
January 23, 2013
Re: Make dur a property?
On 2013-01-23 18:03, monarch_dodra wrote:
> 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 !!!

This is how it should look like. Date ranges in Ruby on Rails can be 
really beautiful:

date = 2.days.ago

I think we should have the same in D.

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

Go for it.

-- 
/Jacob Carlborg
January 23, 2013
Re: Make dur a property?
On 2013-01-23 19:08, Adam D. Ruppe wrote:

> 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.

What about functions not marked with @property?

writeln = "asd";

Doesn't look very nice.

-- 
/Jacob Carlborg
January 23, 2013
Re: Make dur a property?
On 2013-01-23 19:18, Johannes Pfau wrote:

> 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).

Yeah, that was kind of embarrassing.

-- 
/Jacob Carlborg
January 23, 2013
Re: Make dur a property?
On 2013-01-23 19:48, 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.

In Ruby parentheses are optional when calling a method. I have never had 
any problem with that, although in Ruby you invoke a callable object 
with ".call". Property setters are more explicit in Ruby than D:

def foo= (value)
end

The equal sign is actually part of the method name.

-- 
/Jacob Carlborg
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home