Jump to page: 1 213  
Page
Thread overview
UFCS for D
Mar 29, 2012
F i L
Mar 29, 2012
Jesse Phillips
Mar 29, 2012
Walter Bright
Mar 30, 2012
Walter Bright
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Walter Bright
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Walter Bright
Mar 30, 2012
Andrej Mitrovic
Mar 30, 2012
Jacob Carlborg
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
bls
Mar 30, 2012
deadalnix
Mar 30, 2012
bls
Mar 30, 2012
Walter Bright
Mar 30, 2012
foobar
Mar 30, 2012
deadalnix
Mar 30, 2012
Jacob Carlborg
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Nick Sabalausky
Apr 02, 2012
Don Clugston
Apr 02, 2012
Jacob Carlborg
Apr 03, 2012
deadalnix
Apr 03, 2012
Rory McGuire
Apr 03, 2012
deadalnix
Apr 03, 2012
Rory McGuire
Apr 03, 2012
James Miller
Apr 03, 2012
Rory McGuire
Mar 30, 2012
Jacob Carlborg
Mar 30, 2012
Jacob Carlborg
Mar 30, 2012
deadalnix
Mar 30, 2012
Piotr Szturmaj
Mar 30, 2012
Walter Bright
Mar 30, 2012
Piotr Szturmaj
Apr 01, 2012
Walter Bright
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Adam D. Ruppe
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
deadalnix
Mar 30, 2012
Adam D. Ruppe
Mar 30, 2012
Jacob Carlborg
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
deadalnix
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
foobar
Mar 30, 2012
deadalnix
Mar 30, 2012
deadalnix
Mar 30, 2012
Jacob Carlborg
Mar 30, 2012
deadalnix
Mar 30, 2012
Walter Bright
Mar 30, 2012
Walter Bright
Mar 31, 2012
Walter Bright
Mar 31, 2012
Walter Bright
Apr 01, 2012
Simen Kjærås
Apr 02, 2012
deadalnix
Mar 29, 2012
deadalnix
Mar 29, 2012
Timon Gehr
Mar 29, 2012
bearophile
Mar 30, 2012
Timon Gehr
Mar 29, 2012
Simon
Mar 29, 2012
Nick Sabalausky
Mar 29, 2012
Walter Bright
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Jacob Carlborg
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Adam D. Ruppe
Mar 30, 2012
Nick Sabalausky
OT: video games (was Re: UFCS for D)
Mar 30, 2012
Adam D. Ruppe
Re: video games (was Re: UFCS for D)
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Bernard Helyer
Mar 31, 2012
Nick Sabalausky
Mar 31, 2012
Adam D. Ruppe
Mar 31, 2012
Nick Sabalausky
Mar 31, 2012
Walter Bright
Mar 31, 2012
Nick Sabalausky
Mar 31, 2012
Adam D. Ruppe
Mar 31, 2012
Sean Kelly
Mar 31, 2012
Sean Kelly
Mar 31, 2012
Nick Sabalausky
Mar 31, 2012
Jonathan M Davis
Apr 01, 2012
Jonathan M Davis
Apr 01, 2012
Nick Sabalausky
Apr 02, 2012
Nick Sabalausky
Mar 31, 2012
Adam D. Ruppe
Mar 31, 2012
Walter Bright
Mar 31, 2012
Nick Sabalausky
Apr 01, 2012
Adam D. Ruppe
Apr 01, 2012
Nick Sabalausky
Apr 01, 2012
Sean Kelly
Mar 31, 2012
Adam D. Ruppe
Mar 31, 2012
Nick Sabalausky
Mar 31, 2012
Adam D. Ruppe
Apr 01, 2012
Nick Sabalausky
Apr 01, 2012
Adam D. Ruppe
Apr 01, 2012
Nick Sabalausky
Apr 01, 2012
so
Apr 01, 2012
Nick Sabalausky
Apr 01, 2012
so
Apr 02, 2012
Nick Sabalausky
Mar 31, 2012
Robert Clipsham
Mar 31, 2012
Andrej Mitrovic
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Walter Bright
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
dennis luehring
Mar 30, 2012
Walter Bright
Mar 30, 2012
deadalnix
Mar 30, 2012
Nathan M. Swan
March 29, 2012
http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/

Andrei
March 29, 2012
On Thursday, 29 March 2012 at 00:21:38 UTC, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>
> Andrei

Awesome! Been wanting this ever since I bought TDPL! :D

One question though, what takes priority, UFCS or opDispatch?
March 29, 2012
On Thursday, 29 March 2012 at 00:21:38 UTC, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>
> Andrei

I won't be going out of my way to check this, but there is a mention of adding the range primatives. This works, but it doesn't make the class a range for any other module, so std.algorithms won't recogonise it as a range.
March 29, 2012
Le 29/03/2012 02:21, Andrei Alexandrescu a écrit :
> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>
>
> Andrei

The example of std.algorithm should have been used. The importance of such a syntax become obvious when using it.
March 29, 2012
On 03/29/2012 02:21 AM, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>
>
> Andrei

I think the article does not mention that it also works for primitive types.
March 29, 2012
On 29/03/2012 01:21, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>
>
> Andrei

I do wish you guys would just post the direct link as well.

I hate reddit, I've zero interest in the comments on there and jumping through that hoop just slows down my browsing.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
March 29, 2012
"Simon" <s.d.hammett@gmail.com> wrote in message news:jl2j1u$1p3p$1@digitalmars.com...
> On 29/03/2012 01:21, Andrei Alexandrescu wrote:
>> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>>
>>
>> Andrei
>
> I do wish you guys would just post the direct link as well.
>
> I hate reddit, I've zero interest in the comments on there and jumping through that hoop just slows down my browsing.
>

Yea, reddit *is* extremely slow whenever there's a reasonable number of comments. And *that's* with JS *off* (and using it that way prevents you from doing *anything* there other than read existing comments, which of course is retarded). And then with JS on, reddit is *insanely* slow. Seriously takes fucking forever. Easily one of the slowest sites I've ever come across. Total piece of shit implementation they have there (and a perfect example of what's wrong with "cloud" and "web 2.0"). It's almost as if the GitHub guys wrote it.


March 29, 2012
On 3/29/2012 3:00 PM, Nick Sabalausky wrote:
> Yea, reddit *is* extremely slow whenever there's a reasonable number of
> comments. And *that's* with JS *off* (and using it that way prevents you
> from doing *anything* there other than read existing comments, which of
> course is retarded). And then with JS on, reddit is *insanely* slow.
> Seriously takes fucking forever. Easily one of the slowest sites I've ever
> come across. Total piece of shit implementation they have there (and a
> perfect example of what's wrong with "cloud" and "web 2.0"). It's almost as
> if the GitHub guys wrote it.


True, but I upgraded recently to 64 bit Win 7, with a 6 core processor and SSD drive. Reddit seems a lot zippier :-)
March 29, 2012
On Wed, 28 Mar 2012 21:53:57 -0400, Jesse Phillips <jessekphillips+D@gmail.com> wrote:

> I won't be going out of my way to check this, but there is a mention of adding the range primatives. This works, but it doesn't make the class a range for any other module, so std.algorithms won't recogonise it as a range.

At first thought, I believed this should be fixable -- if not working already.  Consider that std.algorithm doesn't include *your* module, yet you can pass types defined in your module into std.algorithm and it works just fine.

But I realized after typing about 2 messages in response to this (and deleting them), you are right, there is a fundamental problem here.  Because the template instantiation is based solely on the type.  It does *not* include the type and whatever other modules you may have included that could define extension methods.  I don't think it's an implementation issue, I think it's a design issue -- there simply is no way to do this.

A counter case:

module1.d:

int foo(T)(T t)
{
   return t.bar();
}

module2.d:

struct S { int x;}

module3.d:

import module1, module2;

int bar(S s) { return s.x * 2;}

void baz1()
{
   S s(2);
   assert(foo(s) == 4);
}

module4.d:

import module1, module 2;

int bar(S s) { return s.x * 3;}

void baz2()
{
   S s(2);
   assert(foo(s) == 6);
}

// and to drive the point further:
module5.d:
import module3, module4;

void main()
{
   baz1();
   baz2();
}

In order for the asserts to *both* pass, there has to be two different instantiations of foo!S, one for module3, and one for module4.

So two possible sane rules:
1. A template instantiation can *only* use UFCS from functions defined in or imported from the module in which the template is defined. (i.e. the way it works now I think)
or
2. A template instantiation can *only* use UFCS from functions defined in or imported from the module in which the template is defined, *and* from functions as defined or imported by the module that defines the type on which UFCS is being used.  In other words, from my example above, only functions defined in or imported from module1.d and module2.d.  Therefore, the bar extension defined in module3 and module4 cannot be called from module1.

For builtin types (such as arrays or numbers), there wouldn't be a module that the type was defined.  However, object.di is imported by everything, so extensions could be put in there.

This kind of puts a damper on certain expectations for how UFCS could be used.  But I don't see any other way (other than adding the current module into the instantiation somehow -- imagine the template bloat...).

Even with this limitation, UFCS still allows a lot of cool things.  One misleading suggestion from the article however, it's not very easy to create non-friend non-member functions using UFCS, considering that every function in a given module is a friend.  In order to do this, you would need a helper module for each module that wants to define such non-friend functions.  Given the above proof, the helper module would also have to be imported by the main module.

-Steve
March 29, 2012
Timon Gehr:

> I think the article does not mention that it also works for primitive types.

But there is a small problem with primitive properties: http://d.puremagic.com/issues/show_bug.cgi?id=7773

Bye,
bearophile
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11