www.digitalmars.com         C & C++   DMDScript  

D - Let's talk about dlls again

reply SpookyET <not4_u hotmail.com> writes:
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/
Feb 29 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Feb 29 2004
parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
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/
Feb 29 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Feb 29 2004
parent reply SpookyET <not4_u hotmail.com> writes:
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/
Feb 29 2004
parent "Jan-Eric Duden" <jeduden whisset.com> writes:
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/
Mar 03 2004
prev sibling next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
| 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
Feb 29 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
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
Feb 29 2004