> Ant
> (underground, from work :)

Well met again, old chap. :)

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

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.

>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

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.