Digital Mars - D - Modern Features?

↑ ↓ ← → 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

↑ ↓ ← → "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

↑ ↓ ← → 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

↑ ↓ ← → "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

↑ ↓ ← → 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

↑ ↓ ← → "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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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