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?

Dawid Ciężarkiewicz wrote:
> What do you think?

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

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

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

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".

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

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

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

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

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