Andrei Alexandrescu wrote:
> BCS wrote:
>> Hello Andrei,
>>
>>> Nick Sabalausky wrote:
>>>
>>>> Stdout.formatln("{}", __FUNCTION__);
>>>
>>> I think instead of __FUNCTION__ we'll define a much more comprehensive
>>> static reflection facility.
>>>
>>
>> for the above case I think __FUNCTION__ is as good as it will get. Define it as a human readable identifier rather than reflection.
>>
>>
> 
> You will have it as a human readable identifier too. The problem with
> __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what
> happened to __STRUCT__, __MODULE__ et al?) can go forever.

For classes and structs, this is already possible: typeof(this).stringof

Now we only need a way to get some kind of compile time object for functions and modules (like the type for classes/structs). Then you simply can use .stringof on them.

> 
> Andrei

On Sat, Feb 28, 2009 at 4:10 PM, grauzone <none@example.net> wrote:
>
> For classes and structs, this is already possible: typeof(this).stringof
>
> Now we only need a way to get some kind of compile time object for functions and modules (like the type for classes/structs). Then you simply can use .stringof on them.

Oh, that'd be nice.  It'd be even nicer if .stringof had any more documentation than "returns a string representation of something." Like what format it's supposed to be in, what you're supposed to get when you get the string of something like:

struct S { int x; } pragma(msg, S.x.stringof);

that kind of stuff.  As it is I have *no* idea if any of my uses of stringof are legal, and it worries me even more that other compilers will freely implement it any way they choose, breaking my code on anything but DMDFE.

Denis Koroskin wrote:

> On Sat, 28 Feb 2009 23:39:41 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Nick Sabalausky wrote:
>>> "dsimcha" <dsimcha@yahoo.com> wrote in message news:goc1k7$qml$1@digitalmars.com...
>>>> == Quote from Jarrett Billingsley (jarrett.billingsley@gmail.com)'s
>>>> article
>>>>> Can we get this please?  It's so simple and would be terribly useful.
>>>> Can someone explain what __FUNCTION__ would do in a little more
>>>> detail?  I feel
>>>> like the two posts of this thread so far are talking in secret
>>>> __FUNCTION__-dealer
>>>> code.
>>>  void foofunc()
>>> {
>>>     Stdout.formatln("{}", __FUNCTION__);
>>> }
>>>  Output:
>>> foofunc
>>>  Ie, basically the same as __FILE__ and __LINE__ and useful in the same
>>> ways.
>>
>> I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.
>>
>>> Also, I'd like to be able to do something like:
>>>  Reflect.invoke(__FUNCTION__, params);
>>
>> Yah... and Variant needs to have something similar as well. We know quite what std.reflect needs to look like, just we want to keep our fingers out of too many pies at once.
>>
>>> Something funtionally equiveilent to that would aid maitenance of
>>> self-invoking functions (not only recusion, but also func overloads
>>> that are defined in terms of one "primary" overload).
>>>  Also would be nice for similar reasons: __CLASS__ (or something
>>> similar that would also work for structs)
>>
>> Yah.
>>
>> Andrei
> 
> Yes. When writing a recursive function, it is often desired to have a way to call the function recursively via some shortcut, something like 'fthis' (this function). It would be great to have something like this in D. That way _FUNCTION__ could be replaced by 'fthis.stringof' or something similar. It also gives small other advantages (easier code refactoring etc). Here is an example:
> 
> int factorial(int c)
> {
>     //writefln(fthis.stringof);
>     //writefln(typeof(fthis).stringof);
> 
>     if (c < 2) return 1;
>     return fthis(c - 1) * c;
> }

"fthis" does not sounds like a nice keyword. How about "self"?

grauzone wrote:
> Andrei Alexandrescu wrote:
>> BCS wrote:
>>> Hello Andrei,
>>>
>>>> Nick Sabalausky wrote:
>>>>
>>>>> Stdout.formatln("{}", __FUNCTION__);
>>>>
>>>> I think instead of __FUNCTION__ we'll define a much more comprehensive
>>>> static reflection facility.
>>>>
>>>
>>> for the above case I think __FUNCTION__ is as good as it will get. Define it as a human readable identifier rather than reflection.
>>>
>>>
>>
>> You will have it as a human readable identifier too. The problem with
>> __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what
>> happened to __STRUCT__, __MODULE__ et al?) can go forever.
> 
> For classes and structs, this is already possible: typeof(this).stringof

Not outside of a member function. This is crippling my Visitor implementation.

> Now we only need a way to get some kind of compile time object for functions and modules (like the type for classes/structs). Then you simply can use .stringof on them.

There's much more to reflection that we need to define.


Andrei

Johan Granberg wrote:
> Denis Koroskin wrote:
> 
>> On Sat, 28 Feb 2009 23:39:41 +0300, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Nick Sabalausky wrote:
>>>> "dsimcha" <dsimcha@yahoo.com> wrote in message
>>>> news:goc1k7$qml$1@digitalmars.com...
>>>>> == Quote from Jarrett Billingsley (jarrett.billingsley@gmail.com)'s
>>>>> article
>>>>>> Can we get this please?  It's so simple and would be terribly useful.
>>>>> Can someone explain what __FUNCTION__ would do in a little more
>>>>> detail?  I feel
>>>>> like the two posts of this thread so far are talking in secret
>>>>> __FUNCTION__-dealer
>>>>> code.
>>>>  void foofunc()
>>>> {
>>>>     Stdout.formatln("{}", __FUNCTION__);
>>>> }
>>>>  Output:
>>>> foofunc
>>>>  Ie, basically the same as __FILE__ and __LINE__ and useful in the same
>>>> ways.
>>> I think instead of __FUNCTION__ we'll define a much more comprehensive
>>> static reflection facility.
>>>
>>>> Also, I'd like to be able to do something like:
>>>>  Reflect.invoke(__FUNCTION__, params);
>>> Yah... and Variant needs to have something similar as well. We know
>>> quite what std.reflect needs to look like, just we want to keep our
>>> fingers out of too many pies at once.
>>>
>>>> Something funtionally equiveilent to that would aid maitenance of
>>>> self-invoking functions (not only recusion, but also func overloads
>>>> that are defined in terms of one "primary" overload).
>>>>  Also would be nice for similar reasons: __CLASS__ (or something
>>>> similar that would also work for structs)
>>> Yah.
>>>
>>> Andrei
>> Yes. When writing a recursive function, it is often desired to have a way
>> to call the function recursively via some shortcut, something like 'fthis'
>> (this function). It would be great to have something like this in D. That
>> way _FUNCTION__ could be replaced by 'fthis.stringof' or something
>> similar. It also gives small other advantages (easier code refactoring
>> etc). Here is an example:
>>
>> int factorial(int c)
>> {
>>     //writefln(fthis.stringof);
>>     //writefln(typeof(fthis).stringof);
>>
>>     if (c < 2) return 1;
>>     return fthis(c - 1) * c;
>> }
> 
> "fthis" does not sounds like a nice keyword. How about "self"?

We better use "..".

 int factorial(int c)
 {
     //writefln(fthis.stringof);
     //writefln(typeof(fthis).stringof);

     if (c < 2) return 1;
     return ..(c - 1) * c;
 }


Andrei

On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
> We better use "..".
>
>  int factorial(int c)
>  {
>     //writefln(fthis.stringof);
>     //writefln(typeof(fthis).stringof);
>
>     if (c < 2) return 1;
>     return ..(c - 1) * c;
>  }

I hope this is a sarcastic reply :P

Jarrett Billingsley wrote:
> On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> We better use "..".
>>
>>  int factorial(int c)
>>  {
>>     //writefln(fthis.stringof);
>>     //writefln(typeof(fthis).stringof);
>>
>>     if (c < 2) return 1;
>>     return ..(c - 1) * c;
>>  }
> 
> I hope this is a sarcastic reply :P

My second. I was afraid the first one wasn't transparent enough.

Andrei

On Sat, 28 Feb 2009 12:30:35 -0500, Jarrett Billingsley wrote:

> Can we get this please?  It's so simple and would be terribly useful.

void foo()
{
    writefln(__FUNCTION__);
}

void foo(int x)
{
    writefln(__FUNCTION__);
}

-------------------

module bar;
void foo()
{
    writefln(__FUNCTION__);
}

----------------

class One
{
  void foo()
  {
     writefln(__FUNCTION__);
  }
}


struct Two
{
  void foo()
  {
     writefln(__FUNCTION__);
  }
}

--------------

Any problems so far?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On Sat, Feb 28, 2009 at 5:24 PM, Derek Parnell <derek@psych.ward> wrote:
> On Sat, 28 Feb 2009 12:30:35 -0500, Jarrett Billingsley wrote:
>
>> Can we get this please?  It's so simple and would be terribly useful.
>
> void foo()
> {
>    writefln(__FUNCTION__);
> }
>
> void foo(int x)
> {
>    writefln(__FUNCTION__);
> }
>
> -------------------
>
> module bar;
> void foo()
> {
>    writefln(__FUNCTION__);
> }
>
> ----------------
>
> class One
> {
>  void foo()
>  {
>     writefln(__FUNCTION__);
>  }
> }
>
>
> struct Two
> {
>  void foo()
>  {
>     writefln(__FUNCTION__);
>  }
> }
>
> --------------
>
> Any problems so far?

I mentioned in a follow-up post that it would probably have to give a fully-qualified name in the presence of multiple modules and nesting and such.  As for multiple overloads - so what?  All I want is the name of the function.

On Sat, 28 Feb 2009 17:27:27 -0500, Jarrett Billingsley wrote:

> On Sat, Feb 28, 2009 at 5:24 PM, Derek Parnell <derek@psych.ward> wrote:
>> void foo()
>> {
>>    writefln(__FUNCTION__);
>> }
>>
>> void foo(int x)
>> {
>>    writefln(__FUNCTION__);
>> }


> I mentioned in a follow-up post that it would probably have to give a fully-qualified name in the presence of multiple modules and nesting and such.

Ah yes, I read that now ... {note to self: Should read all posts before replying :-)}

> As for multiple overloads - so what?  All I want is the name of the function.

But why? There could be conceivable circumstances in which one needed to know *which* 'foo' issued the message, one might need finer or more details to know that.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell