Re: Function definitions
Re: Function definitions
- Subject: Re: Function definitions
- From: j o a r <email@hidden>
- Date: Wed, 12 Apr 2006 19:03:14 +0200
On 12 apr 2006, at 16.55, Ondra Cada wrote:
It could be put there manually of course (e.g., in a form of
specific tags in comments or whatever alike), but it is easier and
infinitely more convenient to put this information manually where
it belongs to, i.e., into the interface (separated willingly,
intentionally, and by the very basic idea of the object-oriented
approach from the implementation!), i.e., into the header.
Hm... I don't much appreciate having to manually duplicate
information to keep a header file up to date. Duplication is always
bad! I would much rather see that the main purpose (?) of header
files, the separation of the public from the private, were encoded in
the function / method definitions themselves (as is done in some
languages, for example C#, IIRC):
- public (void) foo { // implementation }
- protected (void) foo { // implementation }
- private (void) foo { // implementation }
(Dummy syntax!)
Sort of related, but perhaps not quite: I actually don't like having
to think in terms of files at all. I think that files are unnatural
entities when you design code, and I don't think that the separation
of code into different files should affect the meaning of the code.
For example, files can define the scope of static variables. I think
that's weird. I don't think that files should have any meaning at
all, only code should have meaning.
j o a r
Ps. OK, there is (at least) one thing I would miss if there were no
header files: The ability to change the implementation of something
without having to re-compile all dependent code! Win some, loose
some... ;-)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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