April 27, 2012
On Fri, 27 Apr 2012 08:11:48 -0400, so <so@so.so> wrote:

> On Friday, 27 April 2012 at 11:51:40 UTC, Steven Schveighoffer wrote:
>
>> The idea I came up with in my proposal (http://d.puremagic.com/issues/show_bug.cgi?id=6579) was to allow aliasing the static method into the instance namespace:
>>
>> struct S1
>> {
>>    static void foo() {}
>>    alias S1.foo this.foo;
>> }
>>
>> struct S2
>> {
>>    static void foo() {}
>> }
>>
>> void main()
>> {
>>    S1 i1;
>>    S2 i2;
>>    S1.foo(); // ok
>>    i1.foo(); // ok
>>    S2.foo(); // ok
>>    i2.foo(); // error
>> }
>>
>> -Steve
>
> But call site remains unchanged, which was the main reason of confusion. If we expect user to read the function declaration anyway, an extra alias won't do much good or probably complicate it even further.

Huh?  The main reason of confusion is that the static method is named in such a way that it looks like an instance method.  So we prevent that, unless the author of the class (who is deciding the name of the function) deems it should be called on instances

example:

struct File
{
   static File open(string name) {...} // factory method
   this(string name);
}

File f = File("hello");

f.open("world"); // oops!  Just opened file world and threw it away
f = File.open("world");// better!

I challenge you to name File.open some way where it *wouldn't* be confusing when called on an instance :)

-Steve
April 27, 2012
On Friday, 27 April 2012 at 12:35:53 UTC, Steven Schveighoffer wrote:

> Huh?  The main reason of confusion is that the static method is named in such a way that it looks like an instance method.  So we prevent that, unless the author of the class (who is deciding the name of the function) deems it should be called on instances
>
> example:
>
> struct File
> {
>    static File open(string name) {...} // factory method
>    this(string name);
> }
>
> File f = File("hello");
>
> f.open("world"); // oops!  Just opened file world and threw it away
> f = File.open("world");// better!

With your proposal you can still do "f.open("world");" and get the same result if the author provided alias. You are trying to solve another problem, that the author should better state if this is intended. The problem i see is user assumming author is a smart guy. But at the end he finds out the author is as dumb as himself {he should have RTFM :)}

> I challenge you to name File.open some way where it *wouldn't* be confusing when called on an instance :)
>
> -Steve

Easy! Don't call on an instance! openFile() out of the struct.
I always add "make_" before any static function, otherwise static methods should be precise as http://forum.dlang.org/post/araqkvvgyspzmdecxqxi@forum.dlang.org
April 27, 2012
On Fri, 27 Apr 2012 09:15:31 -0400, so <so@so.so> wrote:

> On Friday, 27 April 2012 at 12:35:53 UTC, Steven Schveighoffer wrote:
>
>> Huh?  The main reason of confusion is that the static method is named in such a way that it looks like an instance method.  So we prevent that, unless the author of the class (who is deciding the name of the function) deems it should be called on instances
>>
>> example:
>>
>> struct File
>> {
>>    static File open(string name) {...} // factory method
>>    this(string name);
>> }
>>
>> File f = File("hello");
>>
>> f.open("world"); // oops!  Just opened file world and threw it away
>> f = File.open("world");// better!
>
> With your proposal you can still do "f.open("world");" and get the same result if the author provided alias.

The point is, don't provide the alias.  Why would anyone do that in this case?

> You are trying to solve another problem, that the author should better state if this is intended. The problem i see is user assumming author is a smart guy. But at the end he finds out the author is as dumb as himself {he should have RTFM :)}

There is no protection D could ever provide against dumb authors ;)  He could have named it "close", or "r72" and the compiler is powerless to prevent this!  It's useless to try and prevent such things, D compiler is not a psychologist.

The problem I see here is that *smart* authors are inhibited from writing smart code.

>> I challenge you to name File.open some way where it *wouldn't* be confusing when called on an instance :)
>>
>> -Steve
>
> Easy! Don't call on an instance! openFile() out of the struct.
> I always add "make_" before any static function, otherwise static methods should be precise as http://forum.dlang.org/post/araqkvvgyspzmdecxqxi@forum.dlang.org

I like having open inside the struct, just a matter of preference.  I think File.open implies better than it returns a File more than openFile.

-Steve
April 27, 2012
On 2012-04-27 07:07, H. S. Teoh wrote:
> Is this a bug? Code:
>
> 	import std.stdio;
>
> 	struct S {
> 		static int func(int x) { return x+1; }
> 		int func(int x) { return x+2; }
> 	}
>
> 	void main() {
> 		S s;
> 		writeln(s.func(1));
> 	}
>
> DMD (latest git) output:
>
> 	test.d(10): Error: function test.S.func called with argument types:
> 		((int))
> 	matches both:
> 		test.S.func(int x)
> 	and:
> 		test.S.func(int x)
>
> The error message is unhelpful, but basically the complaint is that the
> static method is conflicting with the non-static method.
>
> But I would've thought it is unambiguous; I'd expect that s.func should
> resolve to the non-static method, and S.func to the static method. After
> all, no object is needed to invoke the static method, and the static
> method cannot be invoked without an object.

It's intended behavior but there's a suggestion to change that: http://d.puremagic.com/issues/show_bug.cgi?id=3345

-- 
/Jacob Carlborg
April 28, 2012
"Steven Schveighoffer" , dans le message (digitalmars.D:165141), a
> The idea I came up with in my proposal (http://d.puremagic.com/issues/show_bug.cgi?id=6579) was to allow aliasing the static method into the instance namespace:

+1
1 2
Next ›   Last »