How would you distribute a D module in a library without giving away the source code?  Can you just stub out the function calls in the module source that you distribute along with the library?  Even with this approach I can't see how you wouldn't be giving away the store because you would need to include the declarations for all the modules in the application.

What am I missing?

D compliers auto-generates the header files.

"Joe Battelle" <b-a-t-t-e-l-l-e@mail.com> wrote in message news:aja2id$4dj$1@digitaldaemon.com...
> How would you distribute a D module in a library without giving away the source code?  Can you just stub out the function calls in the module
source
> that you distribute along with the library?  Even with this approach I
can't
> see how you wouldn't be giving away the store because you would need to include the declarations for all the modules in the application.
>
> What am I missing?
>
>

"Joe Battelle" <b-a-t-t-e-l-l-e@mail.com> wrote in news:aja2id$4dj$1@digitaldaemon.com:

> How would you distribute a D module in a library without giving away the source code?
> 
> What am I missing?


You can use a source code generated doc.
See the coddoc thread above.

On Mon, 12 Aug 2002 21:44:39 -0700 "Joe Battelle" <b-a-t-t-e-l-l-e@mail.com> wrote:

> How would you distribute a D module in a library without giving away the source code?  Can you just stub out the function calls in the module source that you distribute along with the library?  Even with this approach I can't see how you wouldn't be giving away the store because you would need to include the declarations for all the modules in the application.
> 
> What am I missing?

Currently, there is no way to hide the source. In the future, it will most likely be much like Free Pascal - when module is compiled, it also generates a binary file which contains interface for that module.

> D compliers auto-generates the header files.
Not using header files and, thereby,  comingling definitions and declarations is not the same as "auto-generating" header files.  I see nothing that says header files are "generated," such as you would need to do for external linking with a library that you don't have source for.  I could picture a world where you could specifiy a .LIB file on the DMD command line and have the module definition sucked out of that, but that is not implemented (AFAIK) and certainly wouldn't be implemented with the GCC port.

Your right, I think it's in the plan.

"Joe Battelle" <b-a-t-t-e-l-l-e@mail.com> wrote in message news:ajbr21$1uck$1@digitaldaemon.com...
> > D compliers auto-generates the header files.
> Not using header files and, thereby,  comingling definitions and declarations is not the same as "auto-generating" header files.  I see nothing that says header files are "generated," such as you would need to
do
> for external linking with a library that you don't have source for.  I
could
> picture a world where you could specifiy a .LIB file on the DMD command
line
> and have the module definition sucked out of that, but that is not implemented (AFAIK) and certainly wouldn't be implemented with the GCC
port.
>
>

"Joe Battelle" <b-a-t-t-e-l-l-e@mail.com> wrote in message news:aja2id$4dj$1@digitaldaemon.com...
> How would you distribute a D module in a library without giving away the source code?  Can you just stub out the function calls in the module
source
> that you distribute along with the library?  Even with this approach I
can't
> see how you wouldn't be giving away the store because you would need to
> include the declarations for all the modules in the application.
> What am I missing?

Good question. There are a couple of answers. The first is you can strip out all the function bodies, and leave the function declarations, like a C++ .h file. This will work in D - it will link successfully to a library compiled with the full source. The file phobos/gc.d is an example.

The second answer is that the compiler can generate a symbol file for each compiled module, and then just read in that symbol file to satisfy the import statements. For reasons of sloth and laziness, the current D compiler does not do that.

I would be good if this could link in with a D doc gen (when one is created) to alow for more readable output.

"Walter" <walter@digitalmars.com> wrote in message news:ajhtlr$a8o$1@digitaldaemon.com...
>
> "Joe Battelle" <b-a-t-t-e-l-l-e@mail.com> wrote in message news:aja2id$4dj$1@digitaldaemon.com...
> > How would you distribute a D module in a library without giving away the source code?  Can you just stub out the function calls in the module
> source
> > that you distribute along with the library?  Even with this approach I
> can't
> > see how you wouldn't be giving away the store because you would need to
> > include the declarations for all the modules in the application.
> > What am I missing?
>
> Good question. There are a couple of answers. The first is you can strip
out
> all the function bodies, and leave the function declarations, like a C++
.h
> file. This will work in D - it will link successfully to a library
compiled
> with the full source. The file phobos/gc.d is an example.
>
> The second answer is that the compiler can generate a symbol file for each compiled module, and then just read in that symbol file to satisfy the import statements. For reasons of sloth and laziness, the current D
compiler
> does not do that.
>
>

>file. This will work in D - it will link successfully to a library compiled with the full source. The file phobos/gc.d is an example.

Playing around with this I noticed two things about the current linker, both pertaining to linking in a module twice.

1) You _CANNOT_ link program P.d with module A.obj and library L.lib containing
module A.obj if _ANY_ of the defitions in the two module A's differ.
2) You _CAN_ link program P with module A.obj and library L.lib containing
module A.obj if the two versions of module A are disjoint.

What this means: (1) disallows a user of an opaque module from over-riding it's behavior; (2) allows the designer of the opaque library to leave some behavior up to the user of the library.  These seem very reasonable to me, however, I would like case 1 relaxed with a link-time switch so that the designer of an opaque library could allow the user to overide default behavior.

I'm wondering if this is intentional and can be relied on in the future, or if this is just an artifact of the current implementation?

--- source code for those who are lost ---
This example implements one function (d) in the module and leaves another (a) up
to the user of the library.

//file A.d
module A;
version (special) {
int a() { return 0xA; }
int d() ;
} else {
int a() ;
int d() { return 0xD; }
}

//file test.d
import c.stdio;
import A;

int main (char[][] args)
{
printf("d()=%X a()=%X\n", d(), a());
return 0;
}

dmd -c A
lib L.lib /c +A.obj;
dmd -c -version=special A
dmd test A.obj L.lib
test
>d()=D a()=A

Yes, it is intentional behavior of the linker, which is a standard linker. To override part of the functionality of a library, the right way to do it is to replace the entire module or derive from a class.

"Joe Battelle" <Joe_member@pathlink.com> wrote in message news:aji7m4$kn2$1@digitaldaemon.com...
> >file. This will work in D - it will link successfully to a library
compiled
> >with the full source. The file phobos/gc.d is an example.
>
> Playing around with this I noticed two things about the current linker,
both
> pertaining to linking in a module twice.
>
> 1) You _CANNOT_ link program P.d with module A.obj and library L.lib
containing
> module A.obj if _ANY_ of the defitions in the two module A's differ.
> 2) You _CAN_ link program P with module A.obj and library L.lib containing
> module A.obj if the two versions of module A are disjoint.
>
> What this means: (1) disallows a user of an opaque module from over-riding
it's
> behavior; (2) allows the designer of the opaque library to leave some
behavior
> up to the user of the library.  These seem very reasonable to me, however,
I
> would like case 1 relaxed with a link-time switch so that the designer of
an
> opaque library could allow the user to overide default behavior.
>
> I'm wondering if this is intentional and can be relied on in the future,
or if
> this is just an artifact of the current implementation?
>
> --- source code for those who are lost ---
> This example implements one function (d) in the module and leaves another
(a) up
> to the user of the library.
>
> //file A.d
> module A;
> version (special) {
> int a() { return 0xA; }
> int d() ;
> } else {
> int a() ;
> int d() { return 0xD; }
> }
>
> //file test.d
> import c.stdio;
> import A;
>
> int main (char[][] args)
> {
> printf("d()=%X a()=%X\n", d(), a());
> return 0;
> }
>
> dmd -c A
> lib L.lib /c +A.obj;
> dmd -c -version=special A
> dmd test A.obj L.lib
> test
> >d()=D a()=A
>
>