www.digitalmars.com         C & C++   DMDScript  

D - dynamic class loading in D

reply Marcel Meyer <meyerm fs.tum.de> writes:
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
Jan 26 2004
parent reply Stephan Wienczny <wienczny web.de> writes:
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
Jan 26 2004
next sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
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!
Jan 26 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Georg Wrede" <Georg_member pathlink.com> wrote in message
news:bv4481$269r$1 digitaldaemon.com...

 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!



I'm afraid these techniques form part of a two big chapters about how to
overcome C++'s lack of a standard ABI from the current book - "Imperfect
C++"; due out mid-2004. ;)
Jan 27 2004
prev sibling parent reply Marcel Meyer <meyerm fs.tum.de> writes:
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
Jan 27 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Jan 27 2004
parent reply Marcel Meyer <meyerm fs.tum.de> writes:
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.
Jan 27 2004
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
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?


=20
 Yup! :-)
=20
 I don't know what to call - the extreme would be not even knowing the n=


ame

 of the class during compile time. Just take an editor as example. Of co=


urse

 the plugin could offer some generic "doSomethingWithTheSelectedText(*te=


xt)"

 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=20
usual with plug-in systems. If it weren't so, they would be useless. ;)=20
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=20
dispatcher method which accepts the "real" method name or ordinal and=20
another to return an array of method names.

However, we already have ability to inspect class fields. Walter said=20
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=20
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=20
unused and thus may be considered bloat. (google: "Are we all in the=20
same bloat?")

Gr=FC=DFe an die andere Stra=DFenseite! ;) How did you become aware of D?=
 If=20
it's from hearsay, there's a chance that it's due to me. ;)

-eye
Jan 27 2004
prev sibling next sibling parent davepermen <davepermen_member pathlink.com> writes:
if you know how to call the method, it's easy to dispatch by name. same for
objects with known interfaces.

this is the most used way anyways.

if you don't know it, the best would be a scripting language anyways. i never
seen use yet for reflection except for real scripting purposes. and they work
well without it, if you use some nice scriptinglanguage.

D is compile time. you have to use your stuff at compile time => you have to
know how to use it then => you can define that interface then => you don't need
reflection for it at all.

In article <bv60kq$28p8$1 digitaldaemon.com>, Marcel Meyer says...

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.
Jan 27 2004
prev sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bv60kq$28p8$1 digitaldaemon.com>, Marcel Meyer says...

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


If the plugin really should do things the original application programmer
never thought of, then the plugin must resume responsibility in those
situations. In practice this means that you have to have a main class 
in the plugin that presents the new choices to the user, and classes 
that implement them.

The App (the original extendable program) of course has to invoke this
main class. For this, there has to be a method of a specific name in 
the class. (Call it plugin_init or plugin_main or whatever.) 

Opening GoF, (_The_ Design Patterns book) reveals on the inside cover
some patterns that you have to/really should use here. Decorator is 
the first pattern that hits the eye in this regard. Then pops Facade up.
Abstract Factory and/or Factory Method look like they should be used
in the plugin. 

The App and the Plugin cooperate, more by the Plugin calling code in
the App, than the App calling code in the Plugin. This is because the
Plugin has to have control during the activities it is written for.
Either the App has a documented API for this, or otherwise the Plugin
writer knows more about the App than the App writer about this future
Plugin. 

Summing this all up, I'm not sure that reflection is at all needed 
for plugins.


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


This web page lists things you can do with reflection. Of course the
immediate thought about each is "wow, with that I could [whatever]".
Which of course leads to the individual wishing these were part of
his own programming language. I think the page would do a favor to 
all if it instead listed situations where you really _cannot_ 
survive without reflection.

Immediately after the list it says: "Don't use the reflection API 
when other tools more natural to the Java programming language 
would suffice." And I think this applies to programming in general.
Jan 28 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
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 :)
Jan 27 2004
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
(underground, from work :)


Hey, good to see you!!
Jan 27 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Ant
 (underground, from work :)


Well met again, old chap. :)
Jan 27 2004
prev sibling parent davepermen <davepermen_member pathlink.com> writes:
Ant
(underground, from work :)


And you're sure I'm not your wife, underground from home?

:D

nice to see you. bether get that cleaned up to be officially in here again.
just... uhm.. clone yourself:D
Jan 27 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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. ;)
Jan 27 2004