Re: Function definitions
Re: Function definitions
- Subject: Re: Function definitions
- From: ObjM2 <email@hidden>
- Date: Wed, 12 Apr 2006 14:12:07 +0900
On Apr 12, 2006, at 7:34 AM, Scott Ribe wrote:
No they could not. Far as function/message prototypes go you are of
course right, even the global variable references could be sucked out
from the implementation, but with macros and typedefs you are out of
luck.
And why exactly could one not extract macros & typedefs from a
single type
of implementation file and maintain them in a database? There are
languages
that support these features and don't require redundant header files.
I think you will find that this is more an issue of documentation
than anything else.
An interesting example from which to get an idea how header and
implementation files can be merged into a single file would be
Oberon, a language designed as a simplified successor to Modula-2.
Whilst Modula-2 is rather similar to C in this respect as it uses
definition modules which roughly correspond to C header files and
implementation modules which roughly correspond to C implementation
files, Oberon merged them together into a single file where all
entities that are to be exported are marked with a special symbol (an
Asterisk).
This works just fine and Oberon programmers seem to be very fond of
this particular aspect of the language. It would be fairly
straightforward to do a similar thing with C, merging header and
implementation files into a single compilation unit.
But ask a Modula-2 programmer about Oberon and one of the main
criticisms will be that they don't want to miss their definition
modules as a form of concise documentation.
Most C programmers would almost certainly have the very same
reservations, were they to be offered an alternative version of C
where headers and implementation files are merged.
The headers may not be necessary for the compiler to do its job, but
it serves as an important documentation aid to programmers to do
theirs. Consequently there isn't much incentive to change the status
quo.
I would say that this aspect is even more important with ObjC and
Cocoa than with vanilla C and vanilla C libraries because ObjC and
Cocoa are all about data encapsulation and information hiding, and
the separation of headers and implementation files is just a natural
way of representing that.
This is not to say that it has to be this way, but it makes a lot of
sense from an abstraction point of view. And lets be honest, it is
still far less effort to maintain separate header files as a means of
basic documentation than it is to write actual documentation.
Of course there are such things as Doxygen and HeaderDoc, but
documentation generated by such tools has the disadvantage that it
doesn't necessarily reflect the true state of the code because the
compiler doesn't verify the embedded documentation tags and they
aren't mandatory to make the code compile.
Further, between the "let's not type any redundant text" and the
"let's type a little more to make it human readable" camps, Cocoa is
most definitely in the latter, which is one of its appeals.
rgds
objm2
___________________________________________________________
Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden