"Walter" <walter@digitalmars.com> wrote in message news:ahgfa7$sgf$1@digitaldaemon.com...

> > This could be hard/impossible to achieve in the face of dynamic loading.
>
> Yes, but currently D is not defined to deal with dynamic loading. <g>

   But it will at some point, won't it? ;-)

Salutaciones,
                         JCAB

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ahk5pu$2ao$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ahgfa7$sgf$1@digitaldaemon.com...
> > > This could be hard/impossible to achieve in the face of dynamic
loading.
> > Yes, but currently D is not defined to deal with dynamic loading. <g>
>    But it will at some point, won't it? ;-)

I'm not sure how that would work out.

"Walter" <walter@digitalmars.com> wrote in message news:ahk9fv$1b1h$1@digitaldaemon.com...

> > > Yes, but currently D is not defined to deal with dynamic loading. <g>
> >    But it will at some point, won't it? ;-)
>
> I'm not sure how that would work out.

   You'd need to provide a way to express the binary interface of the DLL.
For example, inhibiting inheritance from specific classes outside of the DLL
where they reside would get you a large portion of the way there.

   In general, the interface would somehow be:

- List of classes that are abstract from outside the DLL. Useful for
handle-style APIs.
- List of classes, variables and functions that are publicly accessible from
outside the DLL.
- List of classes that are also inheritable from outside the DLL.

   Now, you can optimize the hell out of everything in the DLL, except those
classes you can inherit from.

Salutaciones,
                         JCAB

"Walter" <walter@digitalmars.com> wrote in message news:ahk9fv$1b1h$1@digitaldaemon.com...
>
> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ahk5pu$2ao$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:ahgfa7$sgf$1@digitaldaemon.com...
> > > > This could be hard/impossible to achieve in the face of dynamic
> loading.
> > > Yes, but currently D is not defined to deal with dynamic loading. <g>
> >    But it will at some point, won't it? ;-)
>
> I'm not sure how that would work out.
>



I'd like it to compile/load C style DLL's and simply have a handle attached to each method (or as a state machine) for classes. That way you could DLL write code in C (or C++ interfaced by C) and use it in D dynamicly. Also you could write a DLL in D and use it dynamicly in C. Parhaps exceptions could be used to test if functions exist.

It's annoying having to type the same code over and over in C to simply test and extract all the functions from a DLL in C. Parhaps D could also complie a sample dynamic loading code with all the funcion/methods defintions included or one better, create a .d file that does it for that file. Parhaps for classes it may look something like:

class eatMe : mouth;

loadDLibrary(Filename, eatME);

eatME Object;

//But that'll need more work.

And a for a function list (called functionList) DLL with a pre-produced .d
file (functionlist.d).

import functionlist;

loadFunctionList(Filename);

//Of course that would only allow one set of functionList, but classes should generaly be used for more the one anyway. Besides parhaps they could be indexed using a state machine type structure.

setFunctionList(int Index); //Index to the current set of functions

Of course there's the other side to look at:

Parhaps for classes...

dll class eatME : mouth
{
...
}

and functions

dll void func()
{
...
}

These are just a starting point, and probably need alot of work.