Ilya Minkov wrote:
> I recall dig compiler driver (look for undig at dsource) would usually be able to do the trick, but someone was working on a better utility.

I was at one time, is that the one you mean?  I basically scrapped most of it pending some changes in both D and Mango... I guess I ought to get that thing written now.  Just hadn't needed it myself, so there was no hurry.

-Chris S.
-Invironz

David Tiktin wrote:

> Would it be possible to do something like this?  A module could (optionally) use 2 files, say x.d and x.i.  x.d would be the "stripped" interface file.  x.i would be the "full" implementation file.  x.d would have a statement like: 
> 
> module x;
> implementation x;
> 
> When building the object x.obj, the compiler would "bring in" the implementation and compile the "combined" file.  When compiling any other object using "import x" it would not.  It would just see the .d interface file.  You'd just ship the .lib containing the .obj and .d files.  Just a thought.

A simpler way would be to allow a class to be redeclared in a different source file within the same compilation phase iff there are no conflicting definitions.

Then we could do

foo.d

    module foo;

    class Foo : FooBase {
        this();
        void do_things();
    }

foo.impl.d (or whatever you want to name it)

    module foo; // foo, not foo_impl!  Currently not legal.

    class Foo : FooBase {
        this() { ... } // implemented this time
        void do_things() { ... }
    }

All the compiler really needs to do is make sure that any conflicting definitions are identical, save for omitted function bodies.  The linker can already catch any duplicated or missing definitions.

With respect to the filename not matching the module name, there are two solutions that come to mind: silently ignore it, or make the ".impl.d" extension (or something like it) explicitly part of the language.

Silently ignoring it is probably much easier: code declared in foo.impl.d is compiled as though it was part of module foo. (name mangling and so forth) Modules importing foo will get the stub instead, as per existing rules, which should be okay in most situations.

Or we could just write a good stripping tool and stay free from manual duplication that way. :)

 -- andy

Thanks for the responses everyone! I already suspected that I had to provide some sort of stripped-down (let's not call them headers) versions of the source code.

Ok, this works well enough. Technically I'm against having /two/ sets of source files since they are bound to drift apart as time goes by.

How nightmarish C/C++ headers may be, they still work well enough since the compiler processes them too, hopefully emitting a warning if the interface and implementation differ too much. But if I'm keeping two sets of D source, I develop actively the other set and pretty much ignore the "header" (Ok, now I called it a header) set. Since the compiler doesn't check these "headers" while compiling the library, there's probably going to be some nasty surprises sooner or later.

The Java/.NET way of using only one set of source files is IMO definitely the way to go. But I guess what is done with Java/.NET (distribute only .jar or .dll files, no headers or source code) is impossible in D, since Bytecode/MSIL contains all the information the source code does. The binary code that C/C++/D compiler emits doesn't.

David Tiktin wrote:

> (Yes, Java and C# do the same thing, and have the same problem.
> They have spawned a code obfuscation industry so people can ship
> classes that can't be decompiled.  Yuck!)

OT:

The obfuscation industry is just exploiting people's paranoia. Decompiling Bytecode/MSIL IMO isn't such a big threat. A company can just put a "reverse engineering prohibited" discalimer in the EULA and sue the hell out of anyone who might be doing so. Individuals who can't afford lawyers develop open source anyway :)

Remember that you can disassemble any executable. But figuring out what the code does is harder. *Much* harder. But it's still /possible/ :)

Though about it for a longer moment and the best option now really seems to have a good tool that would generate the headers. That tool should, being open-source and crossplatform would be used in every IDE so that one would only click on an icon 'generate headers' or sth like that and immediately have them with no pain at all. I think this wouldnt hurt anybody

Ive gotten the DMD front-end to compile ( super cool design i might add!) , and am working out the details of the symbol table ( i dont have any experience with this sort of thing ) , but it actually shouldnt be too hard to write a stripper tool given the front end.  In fact its doable right now, I plan to work on this when I get back from vacation ( pop quiz, what state is the self proclaimed Sportsmans Paradise  :) ).

Charlie

In article <cebo1r$1p37$1@digitaldaemon.com>, Niko Korhonen says...
>
>Thanks for the responses everyone! I already suspected that I had to provide some sort of stripped-down (let's not call them headers) versions of the source code.
>
>Ok, this works well enough. Technically I'm against having /two/ sets of source files since they are bound to drift apart as time goes by.
>
>How nightmarish C/C++ headers may be, they still work well enough since the compiler processes them too, hopefully emitting a warning if the interface and implementation differ too much. But if I'm keeping two sets of D source, I develop actively the other set and pretty much ignore the "header" (Ok, now I called it a header) set. Since the compiler doesn't check these "headers" while compiling the library, there's probably going to be some nasty surprises sooner or later.
>
>The Java/.NET way of using only one set of source files is IMO definitely the way to go. But I guess what is done with Java/.NET (distribute only .jar or .dll files, no headers or source code) is impossible in D, since Bytecode/MSIL contains all the information the source code does. The binary code that C/C++/D compiler emits doesn't.

On 29 Jul 2004, Andy Friesen <andy@ikagames.com> wrote:

> Or we could just write a good stripping tool and stay free from manual duplication that way. :)

That could work as long as the stripping tool is a standard part of the D toolchain.  After all, you really want to use it only when the code is done (the interface is stable) and you're building the library for distribution.  It could be part of the release build process to *optionally* generate the "stripped" source files.

Dave

-- 
D.a.v.i.d  T.i.k.t.i.n
t.i.k.t.i.n [at] a.d.v.a.n.c.e.d.r.e.l.a.y [dot] c.o.m

In article <cebo1r$1p37$1@digitaldaemon.com>, Niko Korhonen says...
>...

>The Java/.NET way of using only one set of source files is IMO definitely the way to go. But I guess what is done with Java/.NET (distribute only .jar or .dll files, no headers or source code) is impossible in D, since Bytecode/MSIL contains all the information the source code does. The binary code that C/C++/D compiler emits doesn't.

Niko Korhonen : If you're wanting to place Free Functions with default parameters (I haven't figured out the exporting Classes to a DLL and then using them with a D app yet) into a DLL without the need of exposing your D code. I have a project called the "Financial Functions Package" on my site, that creates a Windows' DLL in D that's then explicitly loaded into a D Application. Please download and check out the source code in financial_dll.d and loadfindll.d (the loader / D App) from the project at the link below. It's always good to have more options. :))

http://spottedtiger.tripod.com/D_Language/D_Financial_Package_XP.html

Also I've written an article (1st part - the 2nd part will be about the loader) of how I created the D DLL and some of the pitfalls here: http://spottedtiger.tripod.com/D_Language/D_Demystifying_D_DLLs1_XP.html

Hope this helps a little.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

"Niko Korhonen" <niktheblak@hotmail.com> skrev i en meddelelse news:cebo1r$1p37$1@digitaldaemon.com...
> The Java/.NET way of using only one set of source files is IMO definitely the way to go.

I agree, wholeheartedly.

> But I guess what is done with Java/.NET
> (distribute only .jar or .dll files, no headers or source code) is
> impossible in D, since Bytecode/MSIL contains all the information the
> source code does. The binary code that C/C++/D compiler emits doesn't.

Because the binary code that the D compiler emits now, does not include all that information, it does not mean that it could not be made to do it. I cannot imagine that there is not a way to put that information into object files and/or libraries. It could be as simple a producing the stripped down version of the input source file and put it into the object files as some predefined symbol or stuff it into a comment field. No new file formats needs to be invented - only a built-in "stripper" in the compiler and the ability to parse a source embedded in an object file.

Regards,
Martin M. Pedersen

h3r3tic wrote:

> Though about it for a longer moment and the best option now really seems to have a good tool that would generate the headers. That tool should, being open-source and crossplatform would be used in every IDE so that one would only click on an icon 'generate headers' or sth like that and immediately have them with no pain at all. I think this wouldnt hurt anybody

It would be more universal (and ergo more helpful) if it were actually a compiler option...