The D language should really have a decent reflection system. Or why not?

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

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

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

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

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

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

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

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

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