www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - __FUNCTION__

reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
Can we get this please?  It's so simple and would be terribly useful.
Feb 28 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Jarrett,


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



++vote;
Feb 28 2009
parent "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff30f38cb67a8ee93108e news.digitalmars.com...

 Hello Jarrett,


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



 ++vote;



repeat(1, BCS_comment());
Feb 28 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.
Feb 28 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"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.

Also, I'd like to be able to do something like:

Reflect.invoke(__FUNCTION__, params);

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)
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.



 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
Feb 28 2009
next sibling parent reply BCS <none anon.com> writes:
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.
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.


Andrei
Feb 28 2009
next sibling parent reply grauzone <none example.net> writes:
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
Feb 28 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 28 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 grauzone wrote:

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



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



I use it in static constructors. If it doesn't work, well, that's news 
to me.

I don't know about "typeof(this) property;", though. I never tried it.


 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.



Runtime as well as compile time.
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Christopher Wright wrote:

 Andrei Alexandrescu wrote:

 grauzone wrote:

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



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



 I use it in static constructors. If it doesn't work, well, that's news 
 to me.
 
 I don't know about "typeof(this) property;", though. I never tried it.
 

 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.



 Runtime as well as compile time.



Compile-time. Runtime follows and only needs a little glue.

Andrei
Feb 28 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 Christopher Wright wrote:

 Andrei Alexandrescu wrote:

 grauzone wrote:

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



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



 I use it in static constructors. If it doesn't work, well, that's news 
 to me.

 I don't know about "typeof(this) property;", though. I never tried it.


 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.



 Runtime as well as compile time.



 Compile-time. Runtime follows and only needs a little glue.



That glue requires user intervention. Would you add "mixin(Reflect);" to 
every class you wrote? But even that isn't sufficient -- you would have 
to implement some interface indicating that this class has reflection 
information, and pass objects around via that interface rather than 
using Object.

There should be a way to suppress emitting complex reflection 
information -- a command-line flag and a pragma. But I think it's a bit 
much to ask users to mark every class they create in two different ways.


 Andrei
Mar 01 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"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.
Feb 28 2009
prev sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
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.
Feb 28 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Edward Diener wrote:

 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.



D2 will have reflection. (Walter doesn't know yet. He thinks D3 will 
have reflection.) It will be compile-time reflection because only 
run-time reflection only is missing the point.

Andrei
Feb 28 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:

 On Sat, Feb 28, 2009 at 10:49 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Edward Diener wrote:

 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.



 reflection.) It will be compile-time reflection because only run-time
 reflection only is missing the point.



 Will it be implemented through __traits, or *yet another* compile-time
 introspection facility?



Whatever it'll be, I'm sure it will not shut off your whine noise 
generator :o).

Andrei
Feb 28 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el  1 de marzo a las 11:07 me escribiste:

 On Sat, Feb 28, 2009 at 11:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Will it be implemented through __traits, or *yet another* compile-time
 introspection facility?



 Whatever it'll be, I'm sure it will not shut off your whine noise generator
 :o).



 :P
 
 I wasn't whining about it, I'd just rather not see a fifth method of
 compile-time introspection.



It will be nice not to use a keyword starting with "__" for a standard
feature either because that prefix has a long history of being used for
vendor-specific extensions (not to mention its awfulness =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Do not get mad with others
Because they know more than you
It is not their fault
Mar 02 2009
prev sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Andrei Alexandrescu wrote:

 Edward Diener wrote:

 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.



 D2 will have reflection. (Walter doesn't know yet. He thinks D3 will 
 have reflection.) It will be compile-time reflection because only 
 run-time reflection only is missing the point.



The whole debate about "compile-time" and "run-time" reflection  is 
irrelevant as long as one can invoke it without having to inject code 
into an already existing construct.

It must work through run-time code which can ask such reflection 
questions as: enumerate for me all of the classes in a particular module 
etc., or enumerate for me all the functions in a class etc. . It must 
work by allowing code from outside of a construct to query that 
construct and get its accessible constructs. How that run-time code is 
written, whether using "compile-time" reflection using templates, or 
run-time classes accessible from a library whose reflection data is 
produced by the D compiler, is not important from the user's point of 
view as long as the user has the access he wants and can write 
relatively clean and clear code to get it.

Of course from within any given construct one should also be able to 
write code in a clear manner which accesses the inner constructs.

Access to constructs via reflection should follow the same protection 
features as any other code, so that public constructs are always 
accessible but private constructs are only accessible following their 
normal rules.

So I do not know what you mean by "only run-time reflection only is 
missing the point" but certainly the ability to use reflection at 
run-time is vitally important from outside of a construct to any 3rd 
party tool which wants to introspect already existing constructs and 
create objects from those constructs based on the information run-time 
reflection can return.
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Edward Diener wrote:

 Andrei Alexandrescu wrote:

 Edward Diener wrote:

 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.



 D2 will have reflection. (Walter doesn't know yet. He thinks D3 will 
 have reflection.) It will be compile-time reflection because only 
 run-time reflection only is missing the point.



 The whole debate about "compile-time" and "run-time" reflection  is 
 irrelevant as long as one can invoke it without having to inject code 
 into an already existing construct.
 
 It must work through run-time code which can ask such reflection 
 questions as: enumerate for me all of the classes in a particular module 
 etc., or enumerate for me all the functions in a class etc. . It must 
 work by allowing code from outside of a construct to query that 
 construct and get its accessible constructs. How that run-time code is 
 written, whether using "compile-time" reflection using templates, or 
 run-time classes accessible from a library whose reflection data is 
 produced by the D compiler, is not important from the user's point of 
 view as long as the user has the access he wants and can write 
 relatively clean and clear code to get it.
 
 Of course from within any given construct one should also be able to 
 write code in a clear manner which accesses the inner constructs.
 
 Access to constructs via reflection should follow the same protection 
 features as any other code, so that public constructs are always 
 accessible but private constructs are only accessible following their 
 normal rules.
 
 So I do not know what you mean by "only run-time reflection only is 
 missing the point" but certainly the ability to use reflection at 
 run-time is vitally important from outside of a construct to any 3rd 
 party tool which wants to introspect already existing constructs and 
 create objects from those constructs based on the information run-time 
 reflection can return.



This is a long discussion, but in brief any runtime reflection engine 
needs some sort of compile-time metadata infrastructure. Some languages 
don't make that accessible within the language itself. Runtime 
reflection has been explored extensively, its possibilities and 
limitations are pretty well understood, I hardly smothered a yawn 
reading all you wrote. Compile-time reflection is much less understood 
and hides many more exciting possibilities. With the advances in 
compiler technology implemented by Walter, we have a chance to tackle 
reflection in a systematic manner.

Andrei
Feb 28 2009
parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Andrei Alexandrescu wrote:

 Edward Diener wrote:

 Andrei Alexandrescu wrote:

 Edward Diener wrote:

 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.



 D2 will have reflection. (Walter doesn't know yet. He thinks D3 will 
 have reflection.) It will be compile-time reflection because only 
 run-time reflection only is missing the point.



 The whole debate about "compile-time" and "run-time" reflection  is 
 irrelevant as long as one can invoke it without having to inject code 
 into an already existing construct.

 It must work through run-time code which can ask such reflection 
 questions as: enumerate for me all of the classes in a particular 
 module etc., or enumerate for me all the functions in a class etc. . 
 It must work by allowing code from outside of a construct to query 
 that construct and get its accessible constructs. How that run-time 
 code is written, whether using "compile-time" reflection using 
 templates, or run-time classes accessible from a library whose 
 reflection data is produced by the D compiler, is not important from 
 the user's point of view as long as the user has the access he wants 
 and can write relatively clean and clear code to get it.

 Of course from within any given construct one should also be able to 
 write code in a clear manner which accesses the inner constructs.

 Access to constructs via reflection should follow the same protection 
 features as any other code, so that public constructs are always 
 accessible but private constructs are only accessible following their 
 normal rules.

 So I do not know what you mean by "only run-time reflection only is 
 missing the point" but certainly the ability to use reflection at 
 run-time is vitally important from outside of a construct to any 3rd 
 party tool which wants to introspect already existing constructs and 
 create objects from those constructs based on the information run-time 
 reflection can return.



 This is a long discussion, but in brief any runtime reflection engine 
 needs some sort of compile-time metadata infrastructure. Some languages 
 don't make that accessible within the language itself. Runtime 
 reflection has been explored extensively, its possibilities and 
 limitations are pretty well understood, I hardly smothered a yawn 
 reading all you wrote. 



It was written because I have inevitably seen discussions about language 
reflection mechanisms end with talk about really neat new compile-time 
facilities which bring one no closer to real run-time reflection than 
before.


Compile-time reflection is much less understood 
 and hides many more exciting possibilities. With the advances in 
 compiler technology implemented by Walter, we have a chance to tackle 
 reflection in a systematic manner.



Good ! I look forward to seeing it and using it in D.
Mar 01 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Edward Diener wrote:

 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.



I believe it is a great idea, it's just that there are so many that I'm 
swamped.
Feb 28 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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.
Feb 28 2009
prev sibling next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
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.



 detail?  I feel
 like the two posts of this thread so far are talking in secret
 __FUNCTION__-dealer
 code.



 {
     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"?
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.



 detail?  I feel
 like the two posts of this thread so far are talking in secret
 __FUNCTION__-dealer
 code.



 {
     Stdout.formatln("{}", __FUNCTION__);
 }
  Output:
 foofunc
  Ie, basically the same as __FILE__ and __LINE__ and useful in the same
 ways.



 static reflection facility.


 Also, I'd like to be able to do something like:
  Reflect.invoke(__FUNCTION__, params);



 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)




 Andrei



 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
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 28 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 28 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

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



   Sarcasm starts working against the author if
   less than 25% of the audience recognize it.
                          --anon
Mar 01 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 10:49 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Edward Diener wrote:

 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.



 D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have
 reflection.) It will be compile-time reflection because only run-time
 reflection only is missing the point.



Will it be implemented through __traits, or *yet another* compile-time
introspection facility?
Feb 28 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 11:46 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Will it be implemented through __traits, or *yet another* compile-time
 introspection facility?



 Whatever it'll be, I'm sure it will not shut off your whine noise generator
 :o).



:P

I wasn't whining about it, I'd just rather not see a fifth method of
compile-time introspection.
Mar 01 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 2:15 PM, Nick Sabalausky <a a.a> wrote:

 void foofunc()
 {
 =A0 =A0Stdout.formatln("{}", __FUNCTION__);
 }

 Output:
 foofunc



It would probably be the fully-qualified name, especially when you
consider using it for reflection.
Feb 28 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
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.



 detail?  I feel
 like the two posts of this thread so far are talking in secret  
 __FUNCTION__-dealer
 code.



 {
     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;
}
Feb 28 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 We better use "..".

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

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



I hope this is a sarcastic reply :P
Feb 28 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Feb 28 2009
parent reply Derek Parnell <derek psych.ward> writes:
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
Feb 28 2009
parent reply Derek Parnell <derek psych.ward> writes:
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
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 28 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

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



It needed a special keyboard.
Feb 28 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Feb 28 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Feb 28 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 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?



Plenty.

It was a write-only language, on a par with brainf**ck.

I've known guru-level apl programmers who regularly couldn't read their 
own code the next week.

It's probably the most concise way of writing heavy and ultra efficient 
data manipulation code.

It's a bit like spending a week writing an 80-character hairy regexp, 
and later trying to figure out how the heck it actually works.

----

But I think some of us should stick with D1.
Mar 01 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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? =A0It's so simple and would be terribly useful.



 void foo()
 {
 =A0 =A0writefln(__FUNCTION__);
 }

 void foo(int x)
 {
 =A0 =A0writefln(__FUNCTION__);
 }

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

 module bar;
 void foo()
 {
 =A0 =A0writefln(__FUNCTION__);
 }

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

 class One
 {
 =A0void foo()
 =A0{
 =A0 =A0 writefln(__FUNCTION__);
 =A0}
 }


 struct Two
 {
 =A0void foo()
 =A0{
 =A0 =A0 writefln(__FUNCTION__);
 =A0}
 }

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

 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.
Feb 28 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 5:35 PM, Derek Parnell <derek psych.ward> wrote:

 As for multiple overloads - so what? =A0All 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 detai=




 to know that.



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