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

"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

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?

"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

"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

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

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.

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.

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.

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

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.