www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Header file generation.

reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
digitalmars.D.announce
I see lot of discussion about making "header files". I haven't read all
posts about it, but I'm very interested in this topic. Pleas correct me if
I say something untrue.

The problem is to automaticaly generate header files for libraries etc. . D
is cool because whe have one .d file and not pair .h + .cpp , but ...
sometimes this diversion would be useful.

Because of this the -H parameter was add to help generate "striped" d
sources, but this in this "mode" parser does not know what to do export and
what to leave so it just write out almost everything (after striping of
course).


If above is true, why not to help this switch. Maybe there should be a way
to show what part of source is "interface" and what is just
"implementation".

Looking for an easy way to do that I see two ways:

-- keyword
(this may be new or other keyword, but I propose "out" keyword). It's never
used in scope that I'd like to propose, so maybe this would not break
parsing rules.

out export C {
  out void willBeInInterfaceTo();
}

out const MAGIC_CONSTANT = 5;

class L {
 public:
   out Enum TYPE {
     ONE, TWO
   }
   out this() {
     ...
   }
   void publicButNotInInterface() {
      ..
   }
   out void CallMeFromExternalSources(Type i) {
      ...
   }
}

This way, generated .di files could always have what is realy needed. All
"things" from global namespace can be prefixed with "out" without
interfering with current language standards.

-- DDoc
If the keyword solution isn't good enough, there could be DDoc section, like
"Interface: yes", that would act same as "out" from previous paragraph.

What do you think?
Jan 03 2006
next sibling parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Dawid Ciężarkiewicz wrote:

 What do you think?


I see this idea didn't get any attention. Can somebody point me why?
Jan 05 2006
parent John Reimer <terminal.node gmail.com> writes:
Dawid Ciężarkiewicz wrote:

 Dawid Ciężarkiewicz wrote:

 What do you think?


 
 I see this idea didn't get any attention. Can somebody point me why?
 


Not sure.  But maybe the community is still exhausted from the previous 
wrangling session. :)

-JJR
Jan 05 2006
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Dawid Ciężarkiewicz wrote:


 If above is true, why not to help this switch. Maybe there should be a way
 to show what part of source is "interface" and what is just
 "implementation".


Other C-based languages do this, as part of the specification proper:

 interface MyClass : NSObject
{
   int aVariable;
   id  subObject;
}

+ alloc;
+ defaultObject;

- init;
- (int) doSomethingWith: (id)anotherObject;

 end

 implementation MyClass

- (int) doSomethingWith: anotherObject
{
  return [anotherObject multiply: 3 by: 4];
}

 end

This was Objective-C. The  interface part usually goes in a header.

See http://www.gnustep.org/resources/ObjCFun.html (and NeXT/Apple)



 Looking for an easy way to do that I see two ways:
 
 -- keyword
 (this may be new or other keyword, but I propose "out" keyword).
 -- DDoc
 If the keyword solution isn't good enough, there could be DDoc section, like
 "Interface: yes", that would act same as "out" from previous paragraph.


Maybe I misunderstood, would you have to prefix all regular functions ?

(doesn't sound like a good idea)

--anders
Jan 05 2006
parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Anders F Björklund wrote:


 Dawid Ciężarkiewicz wrote:
 

 If above is true, why not to help this switch. Maybe there should be a
 way to show what part of source is "interface" and what is just
 "implementation".


 
 Other C-based languages do this, as part of the specification proper:
 
  interface MyClass : NSObject
 {
    int aVariable;
    id  subObject;
 }
 
 + alloc;
 + defaultObject;
 
 - init;
 - (int) doSomethingWith: (id)anotherObject;
 
  end
 
  implementation MyClass
 
 - (int) doSomethingWith: anotherObject
 {
   return [anotherObject multiply: 3 by: 4];
 }
 
  end
 
 This was Objective-C. The  interface part usually goes in a header.


I don't know why language with standalone header files have to deal with
that. *.h is interface, *.c is implementation. After little while, reading
link you droped I get the feeling in objectvie-C this is all used for other
purpose. Still, I can see some similarity.


 Looking for an easy way to do that I see two ways:
 
 -- keyword
 (this may be new or other keyword, but I propose "out" keyword).
 -- DDoc
 If the keyword solution isn't good enough, there could be DDoc section,
 like "Interface: yes", that would act same as "out" from previous
 paragraph.


 
 Maybe I misunderstood, would you have to prefix all regular functions ?
 
 (doesn't sound like a good idea)


If someone does not care about automatic generation of *.di headers - he
would not have to change anything in existing code. But in library headers,
when you want to have "striped from code *.di header - interface to your
library" there would be a need to mark things that are "interfaces".
Despite fact that "out" is realy short and nonintrusive, prefixing all
functions may seems little to boring. But I can see some concepts to make
this more convinient, for example:

class Bla {
out:
   /+ interface functions +/
in:
   /+ function that will not be inserted in .di file +/
}

I'm not saing that "out" and "in" keywords are the best way. The main idea
is: "let developer mark things that should be put in *.di files so they
always be correct and in sync". The way it should be done is next step. The
first one is saying "hmmm, yeah - this is what D needs".
Jan 05 2006
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Dawid Ciężarkiewicz wrote:


 I don't know why language with standalone header files have to deal with
 that. *.h is interface, *.c is implementation. After little while, reading
 link you droped I get the feeling in objectvie-C this is all used for other
 purpose. Still, I can see some similarity.


For closed-source libraries, you only ship the headers ? (as with C/C++)

It's actually .m for Objective-C, but that doesn't matter much at all...


 But I can see some concepts to make
 this more convinient, for example:
 
 class Bla {
 out:
    /+ interface functions +/
 in:
    /+ function that will not be inserted in .di file +/
 }
 
 I'm not saing that "out" and "in" keywords are the best way. The main idea
 is: "let developer mark things that should be put in *.di files so they
 always be correct and in sync". The way it should be done is next step. The
 first one is saying "hmmm, yeah - this is what D needs".


Ah, OK. Now I see what you mean...
(similar to interface/implementation above, or header/source in plain C)

--anders
Jan 05 2006
parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Anders F Björklund wrote:


 Dawid Ciężarkiewicz wrote:
 

 I don't know why language with standalone header files have to deal with
 that. *.h is interface, *.c is implementation. After little while,
 reading link you droped I get the feeling in objectvie-C this is all used
 for other purpose. Still, I can see some similarity.


 
 For closed-source libraries, you only ship the headers ? (as with C/C++)
 
 It's actually .m for Objective-C, but that doesn't matter much at all...


Oh! In Objective-C there are no header files just as in D, right? Now I get
it. I thought that sources are divided in two files as in C or C++. Now
everything is clear.

So this model is very similar to what I'm proposing in D. There is a strong
need to have one, good and standard way to divide sources into
implementation and interface. In C/C++ there are always two corresponding
files and programers are used to manage them both manualy. One-file model
is so convinient and nobody would want to manage .di files manualy. So D
community have to find a way to have both: single file modules and
automatic interface generating.


 But I can see some concepts to make
 this more convinient, for example:
 
 class Bla {
 out:
    /+ interface functions +/
 in:
    /+ function that will not be inserted in .di file +/
 }
 
 I'm not saing that "out" and "in" keywords are the best way. The main
 idea is: "let developer mark things that should be put in *.di files so
 they always be correct and in sync". The way it should be done is next
 step. The first one is saying "hmmm, yeah - this is what D needs".


 
 Ah, OK. Now I see what you mean...
 (similar to interface/implementation above, or header/source in plain C)
 
 --anders
Jan 05 2006
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Dawid Ciężarkiewicz wrote:


For closed-source libraries, you only ship the headers ? (as with C/C++)

It's actually .m for Objective-C, but that doesn't matter much at all...


 
 Oh! In Objective-C there are no header files just as in D, right? Now I get
 it. I thought that sources are divided in two files as in C or C++. Now
 everything is clear.


Don't want to mess with your head, but Obj-C *has* two files: .m and .h
(it has the C pre-processor, just with some extra keywords like #import)

But I thought that .di and .d would be two different files, as well ?

--anders

PS.
If you want more on that other language, check out http://www.objc.info/
I'm not really a huge fan myself, Apple even considered Java instead...

And here's a introductory text: http://www.otierney.net/objective-c.html
Jan 05 2006
parent reply Sean Kelly <sean f4.ca> writes:
Anders F Björklund wrote:>


 If you want more on that other language, check out http://www.objc.info/
 I'm not really a huge fan myself, Apple even considered Java instead...


Conceptually, it's pretty neat, but I've had a hard time warming up to 
the syntax.  And it doesn't much help that it's not really available for 
other OSes...


Sean
Jan 05 2006
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Sean Kelly wrote:


 Conceptually, it's pretty neat, but I've had a hard time warming up to 
 the syntax.  And it doesn't much help that it's not really available for 
 other OSes...


Same here, but I've heard it's basically just C and SmallTalk "blended"

And you're right, for practical purposes Obj-C means Cocoa or GNUstep...

--anders
Jan 05 2006