On Sat, Feb 28, 2009 at 5:35 PM, Derek Parnell <derek@psych.ward> wrote:
>> 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.

Then, as Andrei suggested, we need a more flexible and fine-grained reflection mechanism.  :)

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

> Then, as Andrei suggested, we need a more flexible and fine-grained reflection mechanism.  :)

Agreed, but are you also suggesting that a simple __FUNCTION__ should also exist?

By the way, my fear for D is that it is turning into an ASCII version of APL.

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

"grauzone" <none@example.net> wrote in message news:goc97a$15il$1@digitalmars.com...
> 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.
>

*smacks self in forehead*, You know, I've even used that in my own code already, and still didn't think of it when I made that post.

Andrei Alexandrescu escribió:
> 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.

The contextual keyword iota, right?

> 
> Andrei

Derek Parnell wrote:
> On Sat, 28 Feb 2009 17:42:55 -0500, Jarrett Billingsley wrote:
> 
>> Then, as Andrei suggested, we need a more flexible and fine-grained
>> reflection mechanism.  :)
> 
> Agreed, but are you also suggesting that a simple __FUNCTION__ should also
> exist?
> 
> By the way, my fear for D is that it is turning into an ASCII version of
> APL.
> 

I don't know much about APL, what was wrong with it?

Andrei

Ary Borenszweig wrote:
> Andrei Alexandrescu escribió:
>> 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.
> 
> The contextual keyword iota, right?

That's the one! I think it even got a serious answer :o).


Andrei

Andrei Alexandrescu wrote:
> I don't know much about APL, what was wrong with it?

It needed a special keyboard.

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> I don't know much about APL, what was wrong with it?
> 
> It needed a special keyboard.

There is an input method for APL that supports standard keyboards, I believe.

Christopher Wright wrote:
> Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> I don't know much about APL, what was wrong with it?
>>
>> It needed a special keyboard.
> 
> There is an input method for APL that supports standard keyboards, I believe.

Yeah, many kludge-o-matic workarounds have appeared over the years, none of which are very satisfactory.

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

These macros are the wrong idea. As you say the bare macros can go on forever. What is really needed in a reflection library is the ability to  'reflect' all D constructs, and you would get much more than just the name in such a library.

So pushing for __FUNCTION__, __CLASS__ etc. etc. is just a quick-fix solution whereas a real reflection library gives so much more.

I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities.