www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is the use of .di depreceated ?

reply =?UTF-8?B?IkVyw6hiZSI=?= <erebe erebe.eu> writes:
Hi,

I recently discovered that D support file interface .di, but 
through my past reads I never seen someone using it. The std 
don't do usage of it (compile time issue maybe ?) and most of D 
project are in the same case.

Is this feature depreceated ?

I'm from a C++ background, I agree on the fact that keeping 
declarations and implementaions sync across two files is tedious, 
but when I have to read code, I like a clean interface to 
summarize the thing.

Dmd doc is there to replace the need of an clean interface ?
Apr 18 2012
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 18/04/2012 09:18, "Erèbe" wrote:
 Hi,

 I recently discovered that D support file interface .di, but through my
 past reads I never seen someone using it. The std don't do usage of it
 (compile time issue maybe ?) and most of D project are in the same case.

 Is this feature depreceated ?

 I'm from a C++ background, I agree on the fact that keeping declarations
 and implementaions sync across two files is tedious, but when I have to
 read code, I like a clean interface to summarize the thing.

 Dmd doc is there to replace the need of an clean interface ?

You can find a list of deprecated features here: http://dlang.org/deprecate .di files are not deprecated, just rarely used. This is for a few reasons: * There is no requirement to use them * They severely limit the capabilities of CTFE (http://dlang.org/function#interpretation) * DMD is really fast - the speed gain from using .di files isn't noticeable for a lot of projects * If you want them, they're very easy to generate yourself (use the -Dd and -Df compiler switches) * For the purposes of reading APIs, DDoc is normally used - alternatively, all good editors and IDEs provide code folding to hide implementations -- Robert http://octarineparrot.com/
Apr 18 2012
prev sibling next sibling parent =?UTF-8?B?IkVyw6hiZSI=?= <erebe erebe.eu> writes:
On Wednesday, 18 April 2012 at 10:02:49 UTC, Robert Clipsham 
wrote:
 On 18/04/2012 09:18, "Erèbe" wrote:
 Hi,

 I recently discovered that D support file interface .di, but 
 through my
 past reads I never seen someone using it. The std don't do 
 usage of it
 (compile time issue maybe ?) and most of D project are in the 
 same case.

 Is this feature depreceated ?

 I'm from a C++ background, I agree on the fact that keeping 
 declarations
 and implementaions sync across two files is tedious, but when 
 I have to
 read code, I like a clean interface to summarize the thing.

 Dmd doc is there to replace the need of an clean interface ?

You can find a list of deprecated features here: http://dlang.org/deprecate .di files are not deprecated, just rarely used. This is for a few reasons: * There is no requirement to use them * They severely limit the capabilities of CTFE (http://dlang.org/function#interpretation) * DMD is really fast - the speed gain from using .di files isn't noticeable for a lot of projects * If you want them, they're very easy to generate yourself (use the -Dd and -Df compiler switches) * For the purposes of reading APIs, DDoc is normally used - alternatively, all good editors and IDEs provide code folding to hide implementations

Thanks, CTFE is a good argument for me
Apr 18 2012
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Wed, 18 Apr 2012 03:02:49 -0700, Robert Clipsham  =

<robert octarineparrot.com> wrote:

 On 18/04/2012 09:18, "Er=E8be" wrote:
 Hi,

 I recently discovered that D support file interface .di, but through =


 past reads I never seen someone using it. The std don't do usage of i=


 (compile time issue maybe ?) and most of D project are in the same ca=


 Is this feature depreceated ?

 I'm from a C++ background, I agree on the fact that keeping declarati=


 and implementaions sync across two files is tedious, but when I have =


 read code, I like a clean interface to summarize the thing.

 Dmd doc is there to replace the need of an clean interface ?

You can find a list of deprecated features here: http://dlang.org/deprecate .di files are not deprecated, just rarely used. This is for a few =

 reasons:
   * There is no requirement to use them
   * They severely limit the capabilities of CTFE  =

 (http://dlang.org/function#interpretation)
   * DMD is really fast - the speed gain from using .di files isn't  =

 noticeable for a lot of projects
   * If you want them, they're very easy to generate yourself (use the =

 -Dd and -Df compiler switches)
   * For the purposes of reading APIs, DDoc is normally used -  =

 alternatively, all good editors and IDEs provide code folding to hide =

 implementations

Where DI files come in handy is for commercial libraries that don't want= = to hand out their source, without DI's that's impossible, therefore for = D = to be a commercially acceptable language, DI's must work, unfortunately,= = DI's do not auto-generate to the this requirement right now, I have a = patch to fix that. But if you are OSS, you don't really care, just deliv= er = the source as the "library". -- = Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Apr 23 2012
prev sibling next sibling parent "James Miller" <james aatch.net> writes:
On Tuesday, 24 April 2012 at 01:51:54 UTC, Adam Wilson wrote:
 Where DI files come in handy is for commercial libraries that 
 don't want to hand out their source, without DI's that's 
 impossible, therefore for D to be a commercially acceptable 
 language, DI's must work, unfortunately, DI's do not 
 auto-generate to the this requirement right now, I have a patch 
 to fix that. But if you are OSS, you don't really care, just 
 deliver the source as the "library".

DI files are sufficiently auto generated now. Templated functions have to be part of the source code because, well, *they're templates* the compiler needs the source code. Otherwise .di files are just .d files with a different name, you can do forward declarations for defining the interface with a library, I've used it several times. There is a build tool that will generate the interface files and use those when actually compiling in order to speed up compilation times when doing incremental compilation (don't have to parse as much code). -- James Miller
Apr 23 2012
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 24 April 2012 at 01:51:54 UTC, Adam Wilson wrote:
 On Wed, 18 Apr 2012 03:02:49 -0700, Robert Clipsham 
 <robert octarineparrot.com> wrote:

 On 18/04/2012 09:18, "Erèbe" wrote:
 Hi,

 I recently discovered that D support file interface .di, but 
 through my
 past reads I never seen someone using it. The std don't do 
 usage of it
 (compile time issue maybe ?) and most of D project are in the 
 same case.

 Is this feature depreceated ?

 I'm from a C++ background, I agree on the fact that keeping 
 declarations
 and implementaions sync across two files is tedious, but when 
 I have to
 read code, I like a clean interface to summarize the thing.

 Dmd doc is there to replace the need of an clean interface ?

You can find a list of deprecated features here: http://dlang.org/deprecate .di files are not deprecated, just rarely used. This is for a few reasons: * There is no requirement to use them * They severely limit the capabilities of CTFE (http://dlang.org/function#interpretation) * DMD is really fast - the speed gain from using .di files isn't noticeable for a lot of projects * If you want them, they're very easy to generate yourself (use the -Dd and -Df compiler switches) * For the purposes of reading APIs, DDoc is normally used - alternatively, all good editors and IDEs provide code folding to hide implementations

Where DI files come in handy is for commercial libraries that don't want to hand out their source, without DI's that's impossible, therefore for D to be a commercially acceptable language, DI's must work, unfortunately, DI's do not auto-generate to the this requirement right now, I have a patch to fix that. But if you are OSS, you don't really care, just deliver the source as the "library".

D could see use an approach similar to what Delphi does, where the tooling is able to extract the information from the .tpu files (delphi libraries), as far as I can remember. Go has a similar approach where the package information is stored in a special section in the library/object files. But I guess di files are anyway easier to maintain.
Apr 23 2012