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




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


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