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


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?


 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)


 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)

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


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);

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






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




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. 


 
D

least

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,




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 


 

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:


  

 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


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

 
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