www.digitalmars.com         C & C++   DMDScript  

D - it needs Reflection.

reply ben harper <ben_member pathlink.com> writes:
The D language should really have a decent reflection system. Or why not?
Oct 21 2003
next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Why?

"ben harper" <ben_member pathlink.com> wrote in message
news:bn4cdv$2pau$1 digitaldaemon.com...
 The D language should really have a decent reflection system. Or why not?

Oct 21 2003
prev sibling next sibling parent Helmut Leitner <leitner hls.via.at> writes:
ben harper wrote:
 
 The D language should really have a decent reflection system. Or why not?

It would help if you wouldn't just say "should really have" but describe the application that you are about to write for which you need it. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Oct 21 2003
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
ben harper wrote:
 The D language should really have a decent reflection system. Or why not?

Because it's impossible to implement in an efficient 100% compiled language. Mind you that Java's reflection is the main complaint of emplementors, which reduces the efficiency of implementations. Some sort of self-awareness is already in D with extended classinfo and typeinfo - which allows to introspect data without knowing the underlying data types at compile time. What else were you going to use reflection for? There are things such as compile-time reflection - which is BTW not *really* reflection - and there probably will be some effort in this direction. However, this is way too hard to implement, marginally useful, and is naturally put off until some indefinately late point in time. -eye
Oct 23 2003
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bn9aha$1maf$1 digitaldaemon.com...
 ben harper wrote:
 The D language should really have a decent reflection system. Or why


 Because it's impossible to implement in an efficient 100% compiled
 language. Mind you that Java's reflection is the main complaint of
 emplementors, which reduces the efficiency of implementations. Some sort
 of self-awareness is already in D with extended classinfo and typeinfo -
 which allows to introspect data without knowing the underlying data
 types at compile time. What else were you going to use reflection for?

 There are things such as compile-time reflection - which is BTW not
 *really* reflection - and there probably will be some effort in this
 direction. However, this is way too hard to implement, marginally
 useful, and is naturally put off until some indefinately late point in

 -eye

Why is it too hard to implement ? all that it is needed is some sort of entry in an object's vtable which gives back what attributes and methods the class has, what kind of class it is etc. For primitive types that are not objects, the run-time identification would be statically compiled. Each object could have a pseudo-member named 'class' which provides access to the methods and attributes of the class. Full reflection is important if D is ever to be used for GUI apps. It just makes IDE development so much easier.
Oct 23 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Argh! This is *not* reflection!!!!

This is class information!

I believe it's already there, it's just not documented yet.

-eye

Achilleas Margaritis wrote:

 Why is it too hard to implement ? all that it is needed is some sort of
 entry in an object's vtable which gives back what attributes and methods the
 class has, what kind of class it is etc.
 
 For primitive types that are not objects, the run-time identification would
 be statically compiled.
 
 Each object could have a pseudo-member named 'class' which provides access
 to the methods and attributes of the class.
 
 Full reflection is important if D is ever to be used for GUI apps. It just
 makes IDE development so much easier.
 
 
 

Oct 26 2003
parent reply Ilya Minkov <webmaster midiclub.de.vu> writes:
Argh! I was (as usual) wrong. It's neither there nor near.

However, i believe this is not a problem for creation of an IDE because:
  - if using an IDE, you need a compiler handy anyway;
  - DMD is very fast;
  - D does not have a separate notion of "pubished" properties, so you 
probably want to make up a simple Interface Description Language - which 
would be easy to parse, have a D-like syntax, and from which you could 
compile (using DMD as back-end) access plug-ins for the IDE.
  - With time, an automated creator of interface description files can 
be written.

I believe this is an optimal solution which would not lead to bloat of 
target executables.

-eye

Ilya Minkov wrote:
 Argh! This is *not* reflection!!!!
 
 This is class information!
 
 I believe it's already there, it's just not documented yet.
 
 -eye

Oct 28 2003
parent reply Ant <Ant_member pathlink.com> writes:
In article <bnlvv2$2t0e$2 digitaldaemon.com>, Ilya Minkov says...
Argh! I was (as usual) wrong. It's neither there nor near.

However, i believe this is not a problem for creation of an IDE because:
  - if using an IDE, you need a compiler handy anyway;
  - DMD is very fast;
  - D does not have a separate notion of "pubished" properties, so you 
probably want to make up a simple Interface Description Language - which 
would be easy to parse, have a D-like syntax, and from which you could 
compile (using DMD as back-end) access plug-ins for the IDE.
  - With time, an automated creator of interface description files can 
be written.

I believe this is an optimal solution which would not lead to bloat of 
target executables.

if ( IDE means RAD || interactive GUI builder ) { I intend to intergrate glade-2 with DUI and leds. http://glade.gnome.org/ my idea: http://ca.geocities.com/dante_ide glade-2 generats a XML output of the widget tree, that's 90%+ of the work done for a interactive GUI builder. my idea to create the D source from that in such a way that it will be used by subclassing only, no direct changes to the generated code. } Ant
Oct 28 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Ant wrote:
 if ( IDE means RAD || interactive GUI builder )
 {

Yup, that's what i meant.
 I intend to intergrate glade-2 with DUI and leds.
 http://glade.gnome.org/

That's an interesting idea, and it's relevant to GTK+, however it's not very silmilar to what Achilleas meant. He probably meant JavaBeans IDE GUI builder style, which is modelled after Delphi. JavaBeans uses reflection, Delphi doesn't and instead relies on bundled compiler, like my proposition. In these, you can have widgets register themselves and be available from IDE for placing and property editing. I believe you saw these 2-tabbed property editors, left the name, right the value. In Delphi, you could even write your own editors. All properties which are designated as Published will become visible. The only diference between Published and Public, is that Public ones can only be changed from the running program, and the Published ones from IDE as well. The wonderful magic of the whole thing, it would work not only with predefined widgets, but also with user-defined widgets in exactly the same manner!
 my idea: http://ca.geocities.com/dante_ide
 
 glade-2 generats a XML output of the widget tree,
 that's 90%+ of the work done for a interactive GUI builder.
 my idea to create the D source from that in such a way that it
 will be used by subclassing only,
 no direct changes to the generated code.
 }

Quite neat. BTW, what i was thinking of. GTK2+ seems to be extremely slow under Windows. At least, what i know of some benchmarks, and also from sodipodi, which is reported to be enjoyable under 100 MHz Pentium Linux, but slugs really slow on my 233 MHz Pentium Windows. Gotta get Linux on the can to reassure myself. :) So, what i was thinking of - would be to do a limited Windows rewrite of GTK2+, using native widgets. Do you think this is feasible? How much does GTK depend on being software-drawn? Probably using some thin intermediate layer like VXCL. Following that, native ports for MacOS X, BeOS (Zeta) and QNX might follow... -eye
Oct 28 2003
parent reply Ant <Ant_member pathlink.com> writes:
In article <bnm7hq$9c1$1 digitaldaemon.com>, Ilya Minkov says...
Ant wrote:
 if ( IDE means RAD || interactive GUI builder )
 {

Yup, that's what i meant.

BTW, what i was thinking of. GTK2+ seems to be extremely slow under 
Windows.

ah! you notice that. My windows box it's actually my old computer (PII350 new is celeron 1.7) so I wasn't sure. the DUI drawing test takes 20 times longer on windows, so that's not all the machine diferences.
So, what i was thinking of - would be to 
do a limited Windows rewrite of GTK2+, using native widgets. Do you 
think this is feasible? How much does GTK depend on being 
software-drawn? Probably using some thin intermediate layer like VXCL. 
Following that, native ports for MacOS X, BeOS (Zeta) and QNX might 
follow...

Sorry, I have no idea, I've limited resources (time) and cannot go there... GTK for windows is part of the "official" GTK release but seems to be maintain by 1 person only... :( (if the guy has a P4 at 3.06 he will never think on performance...) I believe (not sure) there is a version of GTK for the Mac (should be easy for OS 10) Ant
Oct 28 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Ant wrote:
 Sorry, I have no idea, I've limited resources (time) and cannot go
 there... GTK for windows is part of the "official" GTK release but
 seems to be maintain by 1 person only... :( (if the guy has a P4 at
 3.06 he will never think on performance...)

I have mailed this guy once, offering him help him fix Tablet support if he helped me through the code. The bug happens because in X, input device support is unified, and in Windows tablet support is separate. So events get triggered twice in most cases in Windows GTK - once with mouse source, once with tablet source and pressure information. To avoid it, one has either to listen to mouse only, and every time check tablet, whether the pen is in use, pressure, and so on; or, listen to tablet, and implement careful event filtering: tablet would may send events more often, and usually earlier than the mouse, thus allowing for better resolution - but one has to filter corresponding mouse events out then. But since his version has a bug, it's not possible to draw a solid line with a tablet in GIMP, because it switches mode between mouse and tablet about a few dozen times per second. So, i got no answer. :( I think i should have written in Finnish. Even better: i think i should just ignore him. He will not think of anything. I'm ignoring GIMP altogether, i don't know whether the bug has been fixed or not.
 I believe (not sure) there is a version of GTK for the Mac (should be
 easy for OS 10)

They are exact ports of the Unix GTK, that is they, by an old Unix tradition, do all the drawing in the application domain. This is not only something uncomfortable for Windows users, but even really irritating for Mac users. What i actually meant is not a port, but rather a *clone*, which would be a mostly compatible replacement for GTK. Sure, much work, one needs more interested people. -eye
Oct 28 2003
parent Ant <Ant_member pathlink.com> writes:
In article <bnmo81$10mm$2 digitaldaemon.com>, Ilya Minkov says...
Ant wrote:
 Sorry, I have no idea, I've limited resources (time) and cannot go
 there... GTK for windows is part of the "official" GTK release but
 seems to be maintain by 1 person only... :( (if the guy has a P4 at
 3.06 he will never think on performance...)

I have mailed this guy once, So, i got no answer. :(

I kinda understand him: probably he receives hundreads of those emails a week I bet you he reply to the first couple dozen and then just give up... Some of these popular projects with a small teams (1) have very rispid messages saying "Don't ask me that...", "ask this over there, not here", "I've nothing to do with such and such"... Any way the project [GTK for windows] seems popular enough to have more the one maintainer, so some thing is going on there ... (?)
irritating for Mac users. What i actually meant is not a port, but
rather a *clone*, which would be a mostly compatible replacement for GTK.

I understand that, Walter stated once (don't make search the posts again) that the best way (on his view) to have a D gui is to rewrite a good one from another language in D, seems that your idea goes on the same direction (maybe with different goals)
Sure, much work, one needs more interested people.

No doub... (but if you're going to have that much trouble make sure GTK is your best choice before commiting) Ant
Oct 28 2003