In article <dakqub$2888$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Markus Dangl" <danglm@in.tum.de> wrote in message news:dakp99$273f$1@digitaldaemon.com...
>> Ben Hinkle schrieb:
>>>
>>> C:\dflect\dflect>dflect test.d
>>> C:\dflect\dflect>dmd dtest.d dflect.d testinfo.d test.d
>>> C:\dflect\dflect>dtest
>>> setter 100 hello
>>> getter hello
>>
>> Sorry, i can't find dflect.d in the zip file. Where can i get it?
>>
>> Markus
>
>I forgot that part. I've updated the zip file and make a page for it
>http://home.comcast.net/~benhinkle/dflect/
>You can call constructors and methods now. Return values are ignored
>currently. Also most likely lots of little things still don't work.

Ben,
I had no idea that this was a modified DMD front-end... at first glance it
looked like you had merely provided a way to spoof reflection via some other
means.  Bravo!

- EricAnderton at yahoo

"pragma" <pragma_member@pathlink.com> wrote in message news:daltti$35e$1@digitaldaemon.com...
> In article <dakqub$2888$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>
>>"Markus Dangl" <danglm@in.tum.de> wrote in message news:dakp99$273f$1@digitaldaemon.com...
>>> Ben Hinkle schrieb:
>>>>
>>>> C:\dflect\dflect>dflect test.d
>>>> C:\dflect\dflect>dmd dtest.d dflect.d testinfo.d test.d
>>>> C:\dflect\dflect>dtest
>>>> setter 100 hello
>>>> getter hello
>>>
>>> Sorry, i can't find dflect.d in the zip file. Where can i get it?
>>>
>>> Markus
>>
>>I forgot that part. I've updated the zip file and make a page for it
>>http://home.comcast.net/~benhinkle/dflect/
>>You can call constructors and methods now. Return values are ignored
>>currently. Also most likely lots of little things still don't work.
>
> Ben,
> I had no idea that this was a modified DMD front-end... at first glance it
> looked like you had merely provided a way to spoof reflection via some
> other
> means.  Bravo!
>
> - EricAnderton at yahoo

dlint and this reflection generator were the two reasons I wanted dmdfe so
I'm just getting around to doing what I wanted to do for a while. I figured
the dmd front end does all the work of figuring out the module semantics so
why not spit that metadata out?
It would also be interesting to spit out the meta data in another format
like XML or something instead of spitting out D code. I was going to look
into that eventually but if anyone wants to poke around they're certainly
welcome to experiment.

In article <dalvps$4pl$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"pragma" <pragma_member@pathlink.com> wrote in message news:daltti$35e$1@digitaldaemon.com...
>> In article <dakqub$2888$1@digitaldaemon.com>, Ben Hinkle says...
>>>
>>>
>>>"Markus Dangl" <danglm@in.tum.de> wrote in message news:dakp99$273f$1@digitaldaemon.com...
>>>> Ben Hinkle schrieb:
>>>>>
>>>>> C:\dflect\dflect>dflect test.d
>>>>> C:\dflect\dflect>dmd dtest.d dflect.d testinfo.d test.d
>>>>> C:\dflect\dflect>dtest
>>>>> setter 100 hello
>>>>> getter hello
>>>>
>>>> Sorry, i can't find dflect.d in the zip file. Where can i get it?
>>>>
>>>> Markus
>>>
>>>I forgot that part. I've updated the zip file and make a page for it
>>>http://home.comcast.net/~benhinkle/dflect/
>>>You can call constructors and methods now. Return values are ignored
>>>currently. Also most likely lots of little things still don't work.
>>
>> Ben,
>> I had no idea that this was a modified DMD front-end... at first glance it
>> looked like you had merely provided a way to spoof reflection via some
>> other
>> means.  Bravo!
>>
>> - EricAnderton at yahoo
>
>dlint and this reflection generator were the two reasons I wanted dmdfe so
>I'm just getting around to doing what I wanted to do for a while. I figured
>the dmd front end does all the work of figuring out the module semantics so
>why not spit that metadata out?
>It would also be interesting to spit out the meta data in another format
>like XML or something instead of spitting out D code. I was going to look
>into that eventually but if anyone wants to poke around they're certainly
>welcome to experiment.

Funny you should mention that.

I already made an experiment into generating XML with the first DMDFE release you wrote.

http://svn.dsource.org/projects/dsp/trunk/dexter/

I'm still learning how to get the most from the front-end.  I wanted to use this to write documentation, so it captures comments and associates them with D constructs.  Just pass the XML on to a stylesheet engine and presto: instant HTML documentation.

I seriously think this is the way to go for producing documentation with D.

- EricAnderton at yahoo

A request for input: what (if any) metadata tags (which aren't already in standard D) would people like to see? I'm thinking of C#'s attribute syntax and Java's annotations. I suppose the tags will have to be in comments in order to get past the D compiler. Should doxygen/javadoc comments be added to the metadata? For example I could imagine something very simple where any comment preceding a method gets added to the metadata for that method as a "description" property. Or it can try to pick apart tags like @doc, @author, @version, etc etc.

thoughts?

In article <dbbcdh$1rv6$1@digitaldaemon.com>, Ben Hinkle says...
>
>A request for input: what (if any) metadata tags (which aren't already in standard D) would people like to see? I'm thinking of C#'s attribute syntax and Java's annotations. I suppose the tags will have to be in comments in order to get past the D compiler. Should doxygen/javadoc comments be added to the metadata? For example I could imagine something very simple where any comment preceding a method gets added to the metadata for that method as a "description" property. Or it can try to pick apart tags like @doc, @author, @version, etc etc.
>
>thoughts?

Ben, here's my opinion. :)

Personally, I think a documentation parser (similar to my Dexter prototype) should be left to being its own tool.  From a maintenance standpoint, and a coding standpoint it just makes good sense.  At the very least, meshing dflect with a certain style of documentation reduces its usefulness as one may want to use a different doc tool along with dflect.

I think dflect could use a good general-purpose attribute hook similar to what NET has.  The most D-like way to achieve this would be to use a pragma():

> version(dflect){ pragma(attribute,<expression>); }

The above expression would be crammed into the static ctor() for the corresponding metadata module, and would have to evaluate to a certain type: say an Attribute class or somesuch.

- EricAnderton at yahoo

"pragma" <pragma_member@pathlink.com> wrote in message news:dbbgfc$1uk2$1@digitaldaemon.com...
> In article <dbbcdh$1rv6$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>A request for input: what (if any) metadata tags (which aren't already in
>>standard D) would people like to see? I'm thinking of C#'s attribute
>>syntax
>>and Java's annotations. I suppose the tags will have to be in comments in
>>order to get past the D compiler. Should doxygen/javadoc comments be added
>>to the metadata? For example I could imagine something very simple where
>>any
>>comment preceding a method gets added to the metadata for that method as a
>>"description" property. Or it can try to pick apart tags like @doc,
>>@author,
>>@version, etc etc.
>>
>>thoughts?
>
> Ben, here's my opinion. :)
>
> Personally, I think a documentation parser (similar to my Dexter
> prototype)
> should be left to being its own tool.  From a maintenance standpoint, and
> a
> coding standpoint it just makes good sense.  At the very least, meshing
> dflect
> with a certain style of documentation reduces its usefulness as one may
> want to
> use a different doc tool along with dflect.

I agree dflect isn't meant to be used to generate doc. The reason I mentioned the doc string is that dflect is gathering up information about a class for use at run-time. Help is part of that metadata. For example in MATLAB we use Java reflection to let users load jar files and dynamically instantiate and use Java classes from the MATLAB command line. Having short doc strings of what the user just loaded would be very helpful. Otherwise they are on their own to figure out what they have.

> I think dflect could use a good general-purpose attribute hook similar to
> what
> NET has.  The most D-like way to achieve this would be to use a pragma():
>
>> version(dflect){ pragma(attribute,<expression>); }
>
> The above expression would be crammed into the static ctor() for the
> corresponding metadata module, and would have to evaluate to a certain
> type: say
> an Attribute class or somesuch.
>
> - EricAnderton at yahoo

Good idea - though it's a pity the code is so verbose. I'll probably just skip the whole issue for now and dump the parse tree info and that's it.