I know a big part of D's appeal is the whole "symbolic import" thing. The
problem I'm running into is that
you can't symbolically include a lib file. You have to write up a whole other D
file to declare the functions
in the library. This is kind of a pain in the ass, to put it bluntly, as if you
want to distribute a closed source
library programmed in D, then you have to basically maintain two complete sets
of function declarations.

Which totally kills the appeal of D's symbolic imports. Is there any way at all
around this? Or is the
symbolic import thing explicitly tied to files/paths, with no way around it?

daerid@gmail.com

daerid wrote:

> Which totally kills the appeal of D's symbolic imports. Is there any way at all
> around this? Or is the symbolic import thing explicitly tied to files/paths, with no way around it?

Sounds like D could use another tool (besides the one already needed for making D import modules from C headers), for converting D implementation modules to D import modules. So you'd only have to maintain the source ?

I think basically it would be something like "s/\{.*?\}/;/g", but it'd need some more finesse to separate between structs and functions, etc.
Don't think you ever can escape from having an import module, though ?


Then again there were some improvements with D demangling lately, so...
So in the future it *might* be possible to create this from the objects.

Totally with you on the pain part, both going "in" to D and going "out".
On really rainy days, I don't think the C preprocessor was all that bad.

--anders

PS. Terminology used ("import module", etc.) explained in posting:
    http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15626

Have you checked DMD 0.141?
It has a -H flag to generated socalled 'header' files from sources.
Maybe it can help you.

Tamás Nagy

In article <dob9sp$1b61$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>daerid wrote:
>
>> Which totally kills the appeal of D's symbolic imports. Is there any way at all
>> around this? Or is the
>> symbolic import thing explicitly tied to files/paths, with no way around it?
>
>Sounds like D could use another tool (besides the one already needed for making D import modules from C headers), for converting D implementation modules to D import modules. So you'd only have to maintain the source ?
>
>I think basically it would be something like "s/\{.*?\}/;/g", but it'd need some more finesse to separate between structs and functions, etc. Don't think you ever can escape from having an import module, though ?
>
>
>Then again there were some improvements with D demangling lately, so... So in the future it *might* be possible to create this from the objects.
>
>Totally with you on the pain part, both going "in" to D and going "out". On really rainy days, I don't think the C preprocessor was all that bad.
>
>--anders
>
>PS. Terminology used ("import module", etc.) explained in posting:
>     http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15626

MicroWizard wrote:

> Have you checked DMD 0.141?

Nope, still at DMD 0.140 here

> It has a -H flag to generated socalled 'header' files from sources.
> Maybe it can help you.

Will definitely check it out...

--anders


PS. I think the wording "header" is unfortunate, though,
and prefer the alternative term "import module" myself.

When Walter released dmd .141, he wrote

"3) This incorporates a new 'header' generator capability, written by Dave
Fladebo. I goofed it up merging it in, so it is disabled at the moment (just
the source for it is included). I hope to get it working by the next update."


MicroWizard wrote:
> Have you checked DMD 0.141?
> It has a -H flag to generated socalled 'header' files from sources.
> Maybe it can help you.
> 
> Tamás Nagy
> 
> In article <dob9sp$1b61$1@digitaldaemon.com>,
> =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
> 
>>daerid wrote:
>>
>>
>>>Which totally kills the appeal of D's symbolic imports. Is there any way at all
>>>around this? Or is the symbolic import thing explicitly tied to files/paths, with no way around it?
>>
>>Sounds like D could use another tool (besides the one already needed for making D import modules from C headers), for converting D implementation modules to D import modules. So you'd only have to maintain the source ?
>>
>>I think basically it would be something like "s/\{.*?\}/;/g", but it'd need some more finesse to separate between structs and functions, etc.
>>Don't think you ever can escape from having an import module, though ?
>>
>>
>>Then again there were some improvements with D demangling lately, so...
>>So in the future it *might* be possible to create this from the objects.
>>
>>Totally with you on the pain part, both going "in" to D and going "out".
>>On really rainy days, I don't think the C preprocessor was all that bad.
>>
>>--anders
>>
>>PS. Terminology used ("import module", etc.) explained in posting:
>>    http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15626
> 
> 
>