Hi,

if I understand correctly, D does not support dynamic class loading. Is this true? If yes, how can one work around this limitation? And will it ever be implemented?

What is the exact reason this was not implemented? Is it not wanted because it's bad(tm), is it too complicated for the compilers or is there just not enough developer time to get such to work?

Thank you!
        Marcel

Marcel Meyer wrote:
> Hi,
> 
> if I understand correctly, D does not support dynamic class loading. Is this
> true? If yes, how can one work around this limitation? And will it ever be
> implemented?
> 
> What is the exact reason this was not implemented? Is it not wanted because
> it's bad(tm), is it too complicated for the compilers or is there just not
> enough developer time to get such to work?
> 
> Thank you!
>         Marcel

Do I understand you right:

You want to load classes from dlls?!?
This might help you

<---- snip ---->

module inerfaces;

 interface MyClassInterface
 {
	void SomeMethod();
 }

<---- snip ---->

module implementation

import interfaces;

class MyClass : public MyClassInterface
{
	void SomeMethod()
	{
		//foo();
	}		
}

extern(C) MyClassInterface CreateClass()
{
	return new MyClass();
}

<---- snip ---->

Now you can use the standard system methods of dynamically loading functionponters and create a dll class using CreateClass().
If you need a systemindepend (win32 linux) dll class. send me a mail and  I'll upload mine.

Stephan

In article <bv42bl$22t2$1@digitaldaemon.com>, Stephan Wienczny says...
>
>Marcel Meyer wrote:
>> Hi,
>> 
>> if I understand correctly, D does not support dynamic class loading. Is this true? If yes, how can one work around this limitation? And will it ever be implemented?
>> 
>> What is the exact reason this was not implemented? Is it not wanted because it's bad(tm), is it too complicated for the compilers or is there just not enough developer time to get such to work?
>> 
>> Thank you!
>>         Marcel
>
>Do I understand you right:
>
>You want to load classes from dlls?!?
>This might help you
>
><---- snip ---->
>
>module inerfaces;
>
>  interface MyClassInterface
>  {
>	void SomeMethod();
>  }
>
><---- snip ---->
>
>module implementation
>
>import interfaces;
>
>class MyClass : public MyClassInterface
>{
>	void SomeMethod()
>	{
>		//foo();
>	}
>}
>
>extern(C) MyClassInterface CreateClass()
>{
>	return new MyClass();
>}
>
><---- snip ---->
>
>Now you can use the standard system methods of dynamically loading functionponters and create a dll class using CreateClass().


>If you need a systemindepend (win32 linux) dll class. send me
>mail and I'll upload mine.

This ought to get into Matthew's D book!

Hi,

Stephan Wienczny wrote:
> Marcel Meyer wrote:
>> if I understand correctly, D does not support dynamic class loading. Is this true? If yes, how can one work around this limitation? And will it ever be implemented?
>> 
>> What is the exact reason this was not implemented? Is it not wanted because it's bad(tm), is it too complicated for the compilers or is there just not enough developer time to get such to work?
> 
> Do I understand you right:
> 
> You want to load classes from dlls?!?
Hmm, yes and no ;-)

I want to be able to find a .so (or .dll as the windows folks call it) file in a "plugin" directory and then use class reflection to find the offered methods. So you could write generic plugins for your program without constituting what methods may/must be available.

I must say that I never wrote anything in D up to now. Perhaps this is already perfectly possible? I just wanted to clear out things I think I will need before starting to invest too much time. GwydionDylan is also there to be learned ;-)

Thanks

Marcel Meyer wrote:
> Hmm, yes and no ;-)
> 
> I want to be able to find a .so (or .dll as the windows folks call it) file
> in a "plugin" directory and then use class reflection to find the offered
> methods. So you could write generic plugins for your program without
> constituting what methods may/must be available.

And how would you decide what methods to call if you don't know that in advance? Had you thought of that?

If you know that in advance, you can group your methods into interfaces. When you get an object from the library loader, you simply test whether it complies to any of the interfaces by casting.

If you don't know what you want to call, poking around at class methods would be useless to you either.

> I must say that I never wrote anything in D up to now. Perhaps this is
> already perfectly possible? I just wanted to clear out things I think I
> will need before starting to invest too much time. GwydionDylan is also
> there to be learned ;-)

The issue is not different at all from modern C++ or Delphi or other languages with the same compilation model.

-eye

In article <bv5un5$2550$1@digitaldaemon.com>, Marcel Meyer says...
>
>Hi,
>
>Stephan Wienczny wrote:
>> Marcel Meyer wrote:
>>> if I understand correctly, D does not support dynamic class loading. Is this true? If yes, how can one work around this limitation? And will it ever be implemented?
>>> 
>>> What is the exact reason this was not implemented? Is it not wanted because it's bad(tm), is it too complicated for the compilers or is there just not enough developer time to get such to work?
>> 
>> Do I understand you right:
>> 
>> You want to load classes from dlls?!?
>Hmm, yes and no ;-)
>
>I want to be able to find a .so (or .dll as the windows folks call it) file in a "plugin" directory and then use class reflection to find the offered methods. So you could write generic plugins for your program without constituting what methods may/must be available.
>
>I must say that I never wrote anything in D up to now. Perhaps this is already perfectly possible? I just wanted to clear out things I think I will need before starting to invest too much time. GwydionDylan is also there to be learned ;-)
>
>Thanks

I wanna do that to.
GTK (and I already started it for DUI) has an abstraction layer to
do it seamingless on all it's platforms ("GtkModule" in GTK
"Plugin" in DUI as "module" is a reserverd word in D).
unfortunatly the D compiler can't generate objects for ".so" yet.
I was reminded of that when I started testing the Plugin on DUI. :(

When will we be able to generate .so libraries for Linux? Is that still very low priority?

Ant
(underground, from work :)

Ilya Minkov wrote:

> Marcel Meyer wrote:
>> Hmm, yes and no ;-)
>> 
>> I want to be able to find a .so (or .dll as the windows folks call it) file in a "plugin" directory and then use class reflection to find the offered methods. So you could write generic plugins for your program without constituting what methods may/must be available.
> 
> And how would you decide what methods to call if you don't know that in advance? Had you thought of that?
Yup! :-)

I don't know what to call - the extreme would be not even knowing the name of the class during compile time. Just take an editor as example. Of course the plugin could offer some generic "doSomethingWithTheSelectedText(*text)" method. But it could also include several "sendSMTO" or "playTicTacToe" methods which are called by the user. You just offer them in a menu "plugins -> myPlugin -> MethodThis|MethodThat".

See http://java.sun.com/docs/books/tutorial/reflect/ as an example.

Marcel Meyer wrote:
>>And how would you decide what methods to call if you don't know that in
>>advance? Had you thought of that?
> 
> Yup! :-)
> 
> I don't know what to call - the extreme would be not even knowing the name
> of the class during compile time. Just take an editor as example. Of course
> the plugin could offer some generic "doSomethingWithTheSelectedText(*text)"
> method. But it could also include several "sendSMTO" or "playTicTacToe"
> methods which are called by the user. You just offer them in a menu
> "plugins -> myPlugin -> MethodThis|MethodThat".

Not knowing the name of the class at compile time is not extreme, but usual with plug-in systems. If it weren't so, they would be useless. ;) Such a plug-in system is easy to implement in D.

If all the methods have the same interface, then i would say write a dispatcher method which accepts the "real" method name or ordinal and another to return an array of method names.

However, we already have ability to inspect class fields. Walter said that he would consider also ability to inspect class methods if there is enough merit or use. I would say ability to inspect properties would be more important first, though it's a special case of methods, it's easier to implement and generates less information. And each of these decisions affects size of generated class information, which would be largely unused and thus may be considered bloat. (google: "Are we all in the same bloat?")

Grüße an die andere Straßenseite! ;) How did you become aware of D? If it's from hearsay, there's a chance that it's due to me. ;)

-eye

>(underground, from work :)

Hey, good to see you!!

"Marcel Meyer" <meyerm@fs.tum.de> wrote in message news:bv5un5$2550$1@digitaldaemon.com...
> Hi,
>
> Stephan Wienczny wrote:
> > Marcel Meyer wrote:
> >> if I understand correctly, D does not support dynamic class loading. Is this true? If yes, how can one work around this limitation? And will it ever be implemented?
> >>
> >> What is the exact reason this was not implemented? Is it not wanted because it's bad(tm), is it too complicated for the compilers or is
there
> >> just not enough developer time to get such to work?
> >
> > Do I understand you right:
> >
> > You want to load classes from dlls?!?
> Hmm, yes and no ;-)
>
> I want to be able to find a .so (or .dll as the windows folks call it)
file
> in a "plugin" directory and then use class reflection to find the offered methods. So you could write generic plugins for your program without constituting what methods may/must be available.
>
> I must say that I never wrote anything in D up to now. Perhaps this is already perfectly possible? I just wanted to clear out things I think I will need before starting to invest too much time. GwydionDylan is also there to be learned ;-)
>
> Thanks

It's not available in the way you mean because D is a fully-compiled language, and there are currently no protocols for defining dynamic object loading, nor is there much type information in the language.

If you want to come up with a protocol and/or extension to the type info, we'll be happy to criticise it, and if your idea is sound, we can all gang up on Walter. ;)