Okay, you people said that you can't change the dll format to support classes/interfaces because other languages like C and Delphi wouldn't be able to access them.  But you can have 2 dll formats and use a compiler switch to create one that is able to talk to other languages and one that is able to talk only with D which supports classes and interfaces.  Also if you add reflection to the language and metadata to the dll (like mp3s) it would eliminate header files.

import "foobar.dll"

void main()
{
	Foobar foobar = new Foobar();
	foobar.foo();
}

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

SpookyET wrote:

> Okay, you people said that you can't change the dll format to support  classes/interfaces because other languages like C and Delphi wouldn't be  able to access them.  But you can have 2 dll formats and use a compiler  switch to create one that is able to talk to other languages and one that  is able to talk only with D which supports classes and interfaces.  Also  if you add reflection to the language and metadata to the dll (like mp3s)  it would eliminate header files.
>
> import "foobar.dll"
>
> void main()
> {
>     Foobar foobar = new Foobar();
>     foobar.foo();
> }

In this particular case you mite as well use a lib wrapper and use a standard dll.  I would like more reflection information.  Any meta-data in a dll for reflection could be bound within dll functions (using the standard dll).  Also class information could be represented in dll's using structs and special name mangling.  C and Delphi would just see these as regular functions.

-- 
-Anderson: http://badmama.com.au/~anderson/

DLLs work fine if they just expose D interfaces and plain functions:

"COM objects are analogous to D interfaces. Any COM object can be expressed as a D interface, and every D object with an interface X can be exposed as a COM object X. This means that D is compatible with COM objects implemented in other languages. "

-- 
Jan-Eric Duden
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:c1tcho$2u9m$1@digitaldaemon.com...
> SpookyET wrote:
>
> > Okay, you people said that you can't change the dll format to support classes/interfaces because other languages like C and Delphi wouldn't be  able to access them.  But you can have 2 dll formats and use a compiler  switch to create one that is able to talk to other languages and one that  is able to talk only with D which supports classes and interfaces.  Also  if you add reflection to the language and metadata to the dll (like mp3s)  it would eliminate header files.
> >
> > import "foobar.dll"
> >
> > void main()
> > {
> >     Foobar foobar = new Foobar();
> >     foobar.foo();
> > }
>
> In this particular case you mite as well use a lib wrapper and use a standard dll.  I would like more reflection information.  Any meta-data in a dll for reflection could be bound within dll functions (using the standard dll).  Also class information could be represented in dll's using structs and special name mangling.  C and Delphi would just see these as regular functions.
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/

Jan-Eric Duden wrote:

>DLLs work fine if they just expose D interfaces and plain functions:
>
>"COM objects are analogous to D interfaces. Any COM object can be expressed
>as a D interface, and every D object with an interface X can be exposed as a
>COM object X. This means that D is compatible with COM objects implemented
>in other languages. "
>
>  
>
I keep forgetting that, as I've never used com (directly).  Still would like reflection.

-- 
-Anderson: http://badmama.com.au/~anderson/

| if you add reflection to the language and metadata to the dll (like mp3s)
| it would eliminate header files.
|
| import "foobar.dll"
|
| void main()
| {
| Foobar foobar = new Foobar();
| foobar.foo();
| }

I haven't looked into it but with embedding D code in html maybe the documentation could replace the header files.

import foobar; // make sure foobar.html is on the include path
void main()
{
Foobar foobar = new Foobar();
foobar.foo();
}

And doxygen could probably output the embedded header. I guess
the only tricky part is separating out example code from compilable
code.

My take on importing dll's directly is that it could be done
very cheaply: just embed the header file in the dll in some
unused static data. The only unfortunate side-effect is that
it will get loaded when you load the dll and that will waste
space. Plus it would make porting D to other platforms hard
- or maybe this capability of looking in static/dynamic libraries
for header info could be win32 only.

The bang-for-buck for any of these ideas still needs justification, though. Is it really that hard to distribute a header file?

-Ben

Why use all those hacks and workarounds when classes can be first class citizens.   The meta-data in dlls is what .net has which is information about every namespace, class, method, field. etc.

On Mon, 01 Mar 2004 03:27:35 +0800, J Anderson <REMOVEanderson@badmama.com.au> wrote:

> Jan-Eric Duden wrote:
>
>> DLLs work fine if they just expose D interfaces and plain functions:
>>
>> "COM objects are analogous to D interfaces. Any COM object can be expressed
>> as a D interface, and every D object with an interface X can be exposed as a
>> COM object X. This means that D is compatible with COM objects implemented
>> in other languages. "
>>
>>
> I keep forgetting that, as I've never used com (directly).  Still would like reflection.
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

SpookyET wrote:

> Okay, you people said that you can't change the dll format to support  classes/interfaces because other languages like C and Delphi wouldn't be  able to access them.  But you can have 2 dll formats and use a compiler  switch to create one that is able to talk to other languages and one that  is able to talk only with D which supports classes and interfaces.  Also  if you add reflection to the language and metadata to the dll (like mp3s)  it would eliminate header files.

You can write a build system to do just that. You need not call it a DLL, it can be anything, like a package of an interface and an actual DLL. Please, don't bother us with it now since it's a build system issue, not a language issue.

There is really too much important stuff to do, like clean up the compiler bugs and port it to other platforms, as well as write core libraries. And the most important thing now is to make sure that language contains no "features" which could hinder the evolvement of the language in a post-1.0 stage.

-eye

The problem is that Walter needs to implement complete .Net support into D
for this. ;)
And I guess that means a lot of trouble for him. :)
BTW, exposing interfaces over dll boundaries is not that bad.
Most of the time you dont want to give direct access to every member in the
dll anyway.
-- 
Jan-Eric Duden
"SpookyET" <not4_u@hotmail.com> wrote in message
news:opr35dzqkm1s9n15@saturn...
> Why use all those hacks and workarounds when classes can be first class citizens.   The meta-data in dlls is what .net has which is information about every namespace, class, method, field. etc.
>
> On Mon, 01 Mar 2004 03:27:35 +0800, J Anderson <REMOVEanderson@badmama.com.au> wrote:
>
> > Jan-Eric Duden wrote:
> >
> >> DLLs work fine if they just expose D interfaces and plain functions:
> >>
> >> "COM objects are analogous to D interfaces. Any COM object can be
> >> expressed
> >> as a D interface, and every D object with an interface X can be exposed
> >> as a
> >> COM object X. This means that D is compatible with COM objects
> >> implemented
> >> in other languages. "
> >>
> >>
> > I keep forgetting that, as I've never used com (directly).  Still would
> > like reflection.
> >
>
>
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/