Thread overview | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 26, 2003 Modern Features? | ||||
---|---|---|---|---|
| ||||
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#? |
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Berin Loritsch | "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 |
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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? |
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Berin Loritsch | "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 |
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Berin Loritsch | "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 |
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Berin Loritsch | 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. |
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lars Ivar Igesund | 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.
|
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam Treat | 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.
|
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Berin Loritsch | > 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. > |
November 26, 2003 Re: Modern Features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charles Sanders | 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.
|
Copyright © 1999-2021 by the D Language Foundation