On 2012-06-14 15:57, Regan Heath wrote:

> Good point. A module level free function in D is essentially a static
> class method for /all/ classes in the module. I think people like static
> methods over free functions for aesthetic/organisational reasons, not
> for functional ones. Except.. if it's a static method then as it's
> called with syntax like <class>.<method> it cannot collide with a free
> function called <method>. So, perhaps it helps with function lookup and
> collisions, much like namespaces do.
>
>> What would be the use case for such a feature ?
>
> Assuming;
> 1. You have no control over the class Foo, nor it's module
> 2. You don't want private or protected access to Foo's members
>
> Then all you'd get with static UFCS is nicer calling syntax, and
> possibly less lookup/collisions, that's it really.

Exactly.

-- 
/Jacob Carlborg

On 2012-06-14 14:33, deadalnix wrote:

> I already think that static method was a bad idea from the « everything
> have to be an object » time.
>
> The need for static function is pretty weak when we have free function
> and that they can access private objects data as needed.
>
> What would be the use case for such a feature ?

Originally the idea pop up in my head when I was thinking if it was possible to implement, in library code, the magic meta namespace the community has been talking about a couple of times in the past.

Something like this:

import std.meta;

class Foo
{
    void bar (){}
}

auto methods = Foo.meta.methods;

-- 
/Jacob Carlborg

Le 14/06/2012 15:57, Regan Heath a écrit :
> Good point. A module level free function in D is essentially a static
> class method for /all/ classes in the module. I think people like static
> methods over free functions for aesthetic/organisational reasons, not
> for functional ones. Except.. if it's a static method then as it's
> called with syntax like <class>.<method> it cannot collide with a free
> function called <method>. So, perhaps it helps with function lookup and
> collisions, much like namespaces do.
>
>> What would be the use case for such a feature ?
>
> Assuming;
> 1. You have no control over the class Foo, nor it's module
> 2. You don't want private or protected access to Foo's members
>
> Then all you'd get with static UFCS is nicer calling syntax, and
> possibly less lookup/collisions, that's it really.
>
> R
>

Or for the namespace reason. It is a valid point.

But UFCS is no help when it come to name collisions. Actually, it can increase it. So it is still unclear to me what is the benefit of « static UFCS ».

On 06/14/12 16:19, Jacob Carlborg wrote:
> On 2012-06-14 14:33, deadalnix wrote:
> 
>> I already think that static method was a bad idea from the « everything have to be an object » time.
>>
>> The need for static function is pretty weak when we have free function and that they can access private objects data as needed.
>>
>> What would be the use case for such a feature ?
> 
> Originally the idea pop up in my head when I was thinking if it was possible to implement, in library code, the magic meta namespace the community has been talking about a couple of times in the past.
> 
> Something like this:
> 
> import std.meta;
> 
> class Foo
> {
>     void bar (){}
> }
> 
> auto methods = Foo.meta.methods;

Polluting local namespaces with magic identifiers is a really bad idea. What's wrong with "auto methods = meta!Foo.methods;" which works right now?

artur

> I already think that static method was a bad idea from the « everything have to be an object » time.
>
> The need for static function is pretty weak when we have free function and that they can access private objects data as needed.
>

I sometimes use structs with static members in a way similar
to ML functors:

struct A
{
    alias SomeType T;
    T foo(){ ... }
    void bar(T a, T b){ ... }
}

struct B(S)
{
// some static members that use S.T, S.foo and S.bar
}

...

B!(A).someMember();

> What would be the use case for such a feature ?

I haven't ever felt a need to have the feature discussed in
this thread either.

On 2012-06-14 17:41, Artur Skawina wrote:

> Polluting local namespaces with magic identifiers is a really bad idea.
> What's wrong with "auto methods = meta!Foo.methods;" which works right now?

There's nothing wrong with that except for the syntax doesn't look as nice as "Foo.meta.methods". And If I recall correctly the syntax of of the suggested meta namespace was: "Foo.meta.methods".

I actually did tak a look in the archives and I was wrong. The suggestion looked like this:

meta.compiles(XXX)
meta.isArithmetic; // note, property syntax OK if no arguments
meta.isArithmetic(int*);

-- 
/Jacob Carlborg

On 6/13/2012 11:46 PM, Jacob Carlborg wrote:
> Is it possible, somehow, to emulate adding new _static_ methods to a class,
> something like this:
>
> void fooBar (/*something*/, int x) {}
>
> Making this possible:
>
> Foo.fooBar(4);

What's the compelling use case?

On 6/14/12, Jacob Carlborg <doob@me.com> wrote:
> Is it possible, somehow, to emulate adding new _static_ methods to a class, something like this:

Of course there is, this is D not Java! Enjoy:

import std.stdio;
import std.metastrings;

void fooBar(T : Foo)(int x) { writeln(x); }

struct Foo
{
    static auto opDispatch(string name, Params...)(Params params)
    {
        enum strOf = typeof(this).stringof;
        enum str = Format!("return .%s!%s(params);", name, strOf);
        mixin(str);
    }
}

void main()
{
    Foo.fooBar(4);
}

On 6/16/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>     static auto opDispatch(string name, Params...)(Params params)

Maybe "auto ref" there actually.

On 2012-06-16 03:18, Andrej Mitrovic wrote:

> Of course there is, this is D not Java! Enjoy:
>
> import std.stdio;
> import std.metastrings;
>
> void fooBar(T : Foo)(int x) { writeln(x); }
>
> struct Foo
> {
>      static auto opDispatch(string name, Params...)(Params params)
>      {
>          enum strOf = typeof(this).stringof;
>          enum str = Format!("return .%s!%s(params);", name, strOf);
>          mixin(str);
>      }
> }
>
> void main()
> {
>      Foo.fooBar(4);
> }

That's cheating :)

-- 
/Jacob Carlborg