www.digitalmars.com         C & C++   DMDScript  

D - Modern Features?

reply Berin Loritsch <bloritsch d-haven.org> writes:
I have not dug super deep into D yet, and I know there are some nice
features, but what about some of the newer concepts such as Attributes,
reflection, and standardized library loading.

 From what I read (could be ages ago now) D is meant to have a standard
binary layout so that no matter what compiler generates the code, it will
link the same as long as the CPU is the same.

This sets the stage for a standardized shared library format, and
consequently, a standardized interface to load libraries.  Heck, while we
are at it, if you throw in a nice reflection API, we go the next step
toward making the reality of realistic D components work.

Consider all the machinations that you have to go through with the dclient.d
code.  Next, consider the fact that it is essentially using the win32 API
to do the dynamic library loading, so that the code would have to be rewritten
for Linux.

If we could boil it down to one simple interface to load and use classes from
a dynamic library, then each implementation of the "phobos" library or whatever
the standard D library is, would have the proper code to perform the action
for the platform.  This is one of the ways to properly separate interface and
implementation.

Next, the concept of attributes further make the overall picture really nice.
For container developers, user defined attributes make it easy to tool certain
functions for components.  They are essentially an extension to the reflection
API to help tool some very useful things.

And I guess the last wish list item would be delegates.  Delegates have a
two-fold purpose.  First, it provides an reference for a method, so you can pass
the method reference around.  If the delegate references a class method, then
the class method is fully bound to the object instance.  If the delegate
references a simple function, then it calls that function.  The concept of
passing methods around assists in writing certain types of search algorithms.
The other purpose is to provide an "event" mechanism where the class that
exposes a delegate can broadcast to all bindings for that delegate with one
call.

In a language that does not have a byte code, there is no way to create these
things dynamically at runtime.  We would need some level of language support.

So the sanity check would be, would it be reasonable to ever see an
implementation of these features in D, or should I stick with Java and C#?
Nov 26 2003
parent reply "Lars Ivar Igesund" <larsivar igesund.net> writes:
"Berin Loritsch" <bloritsch d-haven.org> wrote in message
news:bq2p9j$ke9$1 digitaldaemon.com...
 I have not dug super deep into D yet,

Maybe you should :)
 If we could boil it down to one simple interface to load and use classes

 a dynamic library, then each implementation of the "phobos" library or

 the standard D library is, would have the proper code to perform the

 for the platform.  This is one of the ways to properly separate interface

 implementation.

Why don't you suggest/implement such an API and submit it for possible inclusion in the standard library?
 Next, the concept of attributes further make the overall picture really

 For container developers, user defined attributes make it easy to tool

 functions for components.  They are essentially an extension to the

 API to help tool some very useful things.

Do you mean properties? (http://www.digitalmars.com/d/property.html)
 And I guess the last wish list item would be delegates.  Delegates have a
 two-fold purpose.  First, it provides an reference for a method, so you

 the method reference around.  If the delegate references a class method,

 the class method is fully bound to the object instance.  If the delegate
 references a simple function, then it calls that function.  The concept of
 passing methods around assists in writing certain types of search

 The other purpose is to provide an "event" mechanism where the class that
 exposes a delegate can broadcast to all bindings for that delegate with

 call.

Do you mean, eh, delegates? (http://www.digitalmars.com/d/type.html#delegates) Lars Ivar Igesund
Nov 26 2003
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Lars Ivar Igesund wrote:
 "Berin Loritsch" <bloritsch d-haven.org> wrote in message
 news:bq2p9j$ke9$1 digitaldaemon.com...
 
I have not dug super deep into D yet,

Maybe you should :)

Yep, maybe I should--but keep in mind I am used to Java, with a little C++. So some things I take for granted (like a rich API) have to be rediscovered somewhat.
 
 
If we could boil it down to one simple interface to load and use classes

from
a dynamic library, then each implementation of the "phobos" library or

whatever
the standard D library is, would have the proper code to perform the

action
for the platform.  This is one of the ways to properly separate interface

and
implementation.

Why don't you suggest/implement such an API and submit it for possible inclusion in the standard library?

Hmmm. I know that the ClassLoader stuff in Java works in many respects, but is somewhat broken in others. It's a tough one....
 
 
Next, the concept of attributes further make the overall picture really

nice.
For container developers, user defined attributes make it easy to tool

certain
functions for components.  They are essentially an extension to the

reflection
API to help tool some very useful things.

Do you mean properties? (http://www.digitalmars.com/d/property.html)

Close but not quite. I am refering to user defined attributes. For example, marking a class as an [AvalonComponent] or saying that a method has the attribute [Dependency(FooInterface, "alias", false /*is required? */)]. Things like that allow for some cool things to be done in a centrally managed way.
 
 
And I guess the last wish list item would be delegates.  Delegates have a
two-fold purpose.  First, it provides an reference for a method, so you

can pass
the method reference around.  If the delegate references a class method,

then
the class method is fully bound to the object instance.  If the delegate
references a simple function, then it calls that function.  The concept of
passing methods around assists in writing certain types of search

algorithms.
The other purpose is to provide an "event" mechanism where the class that
exposes a delegate can broadcast to all bindings for that delegate with

one
call.

Do you mean, eh, delegates? (http://www.digitalmars.com/d/type.html#delegates)

Err... (Hand slaps the forhead) Doh! It is not clear from the online docs, can I do something along these lines?: void delegate(ActionEvent) okbutton; and then any interested parties would be able to do something like this: okbutton += &this.okPressed okbutton += &other.notifyOk With the delegate calling each reference in the list of attached methods? Or is it more like a 1 to 1 type of thing?
Nov 26 2003
next sibling parent "Lars Ivar Igesund" <larsivar igesund.net> writes:
"Berin Loritsch" <bloritsch d-haven.org> wrote in message
news:3FC4FB6D.2010705 d-haven.org...

 Or is it more like a 1 to 1 type of thing?

Yep. Just like all other types and function pointers in C. Lars Ivar Igesund
Nov 26 2003
prev sibling next sibling parent reply "Lars Ivar Igesund" <larsivar igesund.net> writes:
"Berin Loritsch" <bloritsch d-haven.org> wrote in message
news:3FC4FB6D.2010705 d-haven.org...
 It is not clear from the online docs, can I do something along these

 void delegate(ActionEvent) okbutton;

 and then any interested parties would be able to do something like this:

 okbutton += &this.okPressed
 okbutton += &other.notifyOk

 With the delegate calling each reference in the list of attached methods?

The above example could be something like this: void delegate(ActionEvent) [] okbutton; void propagateEvent(ActionEvent event) { foreach(void delegate(ActionEvent) dg; okbutton) { dg(event); } } The array must be setup/initialized to size/whatever you like and decide wheter it's static or dynamic (see arrays). Then you can do okbutton ~= &this.okPressed; okbutton ~= &other.notifyOk; and propagateEvent(e); Lars Ivar Igesund
Nov 26 2003
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Lars Ivar Igesund wrote:

 "Berin Loritsch" <bloritsch d-haven.org> wrote in message
 news:3FC4FB6D.2010705 d-haven.org...
 
It is not clear from the online docs, can I do something along these

lines?:
void delegate(ActionEvent) okbutton;

and then any interested parties would be able to do something like this:

okbutton += &this.okPressed
okbutton += &other.notifyOk

With the delegate calling each reference in the list of attached methods?

The above example could be something like this: void delegate(ActionEvent) [] okbutton; void propagateEvent(ActionEvent event) { foreach(void delegate(ActionEvent) dg; okbutton) { dg(event); } } The array must be setup/initialized to size/whatever you like and decide wheter it's static or dynamic (see arrays). Then you can do okbutton ~= &this.okPressed; okbutton ~= &other.notifyOk; and propagateEvent(e);

Interesting. Of course, more often than not the number of listeners is dynamic. Perhaps this is where we would use generics I suppose. list<void delegate(ActionEvent)> okbutton; void notifyListeners(ActionEvent event) { foreach(void delegate(ActionEvent) dg; okbutton) { dg(event); } } So it would essentially be the same, but we use a list type instead. That would change the syntax to something like this: okbutton.add(&this.okPressed); okbutton.add(&other.notifyOk); If this is doable, it might even be preferable. It is definitely more clear and precise.
Nov 26 2003
parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
 If this is doable, it might even be preferable.  It is definitely more
 clear and precise.

Maybe to a non D person ;). lists, and most ( if not all ) of the STL containers are not needed in D since dynamic and associate arrays are built in. okbutton ~= &this.foo; okbutton ~= &this.bar; Use it a bit youll love it! ;) (~ is the concatenation operator btw ) C "Berin Loritsch" <bloritsch d-haven.org> wrote in message news:bq364k$17nc$1 digitaldaemon.com...
 Lars Ivar Igesund wrote:

 "Berin Loritsch" <bloritsch d-haven.org> wrote in message
 news:3FC4FB6D.2010705 d-haven.org...

It is not clear from the online docs, can I do something along these

lines?:
void delegate(ActionEvent) okbutton;

and then any interested parties would be able to do something like this:

okbutton += &this.okPressed
okbutton += &other.notifyOk

With the delegate calling each reference in the list of attached



 The above example could be something like this:

 void delegate(ActionEvent) [] okbutton;

 void propagateEvent(ActionEvent event)
 {
     foreach(void delegate(ActionEvent) dg; okbutton) {
         dg(event);
    }
 }

 The array must be setup/initialized to size/whatever you like and decide
 wheter
 it's static or dynamic (see arrays).

 Then you can do

 okbutton ~= &this.okPressed;
 okbutton ~= &other.notifyOk;

 and

 propagateEvent(e);

Interesting. Of course, more often than not the number of listeners is dynamic. Perhaps this is where we would use generics I suppose. list<void delegate(ActionEvent)> okbutton; void notifyListeners(ActionEvent event) { foreach(void delegate(ActionEvent) dg; okbutton) { dg(event); } } So it would essentially be the same, but we use a list type instead. That would change the syntax to something like this: okbutton.add(&this.okPressed); okbutton.add(&other.notifyOk); If this is doable, it might even be preferable. It is definitely more clear and precise.

Nov 26 2003
parent Berin Loritsch <bloritsch d-haven.org> writes:
Charles Sanders wrote:

If this is doable, it might even be preferable.  It is definitely more
clear and precise.

Maybe to a non D person ;). lists, and most ( if not all ) of the STL containers are not needed in D since dynamic and associate arrays are built in. okbutton ~= &this.foo; okbutton ~= &this.bar; Use it a bit youll love it! ;) (~ is the concatenation operator btw ) C

Hmm. Ok, so now I need a project to start on.... Nothing too deep or I'll get lost before I start.
Nov 26 2003
prev sibling parent reply Adam Treat <Adam_member pathlink.com> writes:
In article <3FC4FB6D.2010705 d-haven.org>, Berin Loritsch says... 
 Do you


 (http://www.digitalmars.com/d/property.html) 

Close but

marking a

attribute

Things like

way. 

D does have C# style properties, but does not have C# style attributes. At least not yet. Scroll down and look for "C# Style Attributes ..." for a discussion. The problem revolves around the lack of robust reflection/introspection since D is a native language without a bytecode interpreter/JIT to make runtime reflection a possibility. Compile time reflection though...
 Do you mean,


 (http://www.digitalmars.com/d/type.html#delegates) 

Err... (Hand slaps the forhead) Doh! It is not clear from the online docs, can I do something along these lines?: void delegate(ActionEvent) okbutton; and then any interested parties would be able to do something like this: okbutton += &this.okPressed okbutton += &other.notifyOk

Your illustration is exactly like C# style delegates. I think D has something similar for your purposes. Still, I would prefer Qt's signal/slot system to the delegate paradigm. The difference? Delegates are treated as crippled objects in their own right (I say crippled because they are objects, but you can't subclass them... so what is the point) where as Qt's signal/slots have all the benefits of delegates without the extra declaration call.
Nov 26 2003
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Adam Treat wrote:

  
 Your illustration is exactly like C# style delegates.  I think D has something 
 similar for your purposes.  Still, I would prefer Qt's signal/slot system to 
 the delegate paradigm.  The difference? Delegates are treated as crippled 
 objects in their own right (I say crippled because they are objects, but you 
 can't subclass them... so what is the point) where as Qt's signal/slots have 
 all the benefits of delegates without the extra declaration call. 
 
 

You can tell where I've been playing can't you? ;P The thing that delegates have going for them is that they are strongly typed. I'm not familiar with Qt's signal/slots approach, so I can't comment on that. Think about it though, do you really need to subclass a delegate? I can't think of a good reason to myself.
Nov 26 2003
parent reply Adam Treat <Adam_member pathlink.com> writes:
In article <bq36c5$17nc$2 digitaldaemon.com>, Berin Loritsch says... 
You can

 
The thing that delegates have

I'm not familiar with Qt's

 
Think about it though,

I can't think of a good reason to

No, I can't and that is pretty much my point. Why make it an object in its own right when you can't even subclass it? Qt's signal/slots are also typesafe, but do not have the syntactical overheard of C#'s delegates. Here is what they look like: You define the signal/slots in the header files of the QObject subclasses like so. class Foo: QObject { Q_OBJECT slots: void add( int x, int y ); }; class Bar: QObject { Q_OBJECT signals: void calculate( int x, int y ); }; then the slot could be... void Foo::add( int x, int y) { print ( x + y ); } and you'd connect them like... connect( &foo, SIGNAL(calculate(int,int), &bar, SLOT(add(int,int)) ); and then you'd emit the signal like so... emit calculate( 1, 1 ); and the slot is called. Of course, you can connect/disconnect as many slots to a signal as you wish. You can also connect signals to signals. All very sane and without the overhead of the delegates. Of course, I'd like to see a '+=' or '~=' operator for the connect call, but other than that I think it is much nicer... Here is an overview: http://www.trolltech.com/products/qt/whitepaper/qt-whitepaper-3.html
Nov 26 2003
parent reply Adam Treat <Adam_member pathlink.com> writes:
In article <bq39p8$1d8c$1 digitaldaemon.com>, Adam Treat says... 
 
Sorry about
the odd formatting. I'm using the forum html form direct from the 
website.  Not
sure why it is wrapping everything... 
Nov 26 2003
parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Ahh, ive seen that before so thought it was some weird client :).

C


"Adam Treat" <Adam_member pathlink.com> wrote in message
news:bq39sk$1df3$1 digitaldaemon.com...
 In article <bq39p8$1d8c$1 digitaldaemon.com>, Adam Treat says...

 Sorry about
 the odd formatting. I'm using the forum html form direct from the
 website.  Not
 sure why it is wrapping everything...

Nov 26 2003