discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automatic method generator - prototype (Was: Re: Interface parser)


From: stefan
Subject: Re: Automatic method generator - prototype (Was: Re: Interface parser)
Date: Tue, 27 Jul 2004 08:52:14 +0200
User-agent: Internet Messaging Program (IMP) 3.2.2

Mikko,

Citát Mikko Värri <mikko.varri@iglu.net>:

> On Mon, 26 Jul 2004 20:58:28 +0200, Stefan Urbanek wrote
> > Feel fry to modify the code. Any feedback and especially patches is more
> > than welcome.
> > 
> > Enjoy,
> > 
> > Stefan Urbanek
> > 
> > p.s.: It would be great if it was somehow incorporated in the
> DevelopmentKit
> > framework....
> > 
> 
> Stefan,
> 
> I know this was a quick hack, but you asked for comments :) So here's my
> thoughts.
> 
> Using the word 'public' is imho misleading. Typically the 'public' keyword
> means that the variable is accessible directly, not through accessor
> methods.
>

I have moved meaning of that word a bit forward. Nowdays large majority of
developers does not use direct access to instance variables of ObjectiveC
objects, they use accessor methods. Therefore saying that some instance
variable is 'public' means, that developer can change it - sense remained. What
was shifted was the "implementation" of accessing. From direct access to access
through methods.

> Using '/**' and '*/' as delimiters may conflict with those used for
> documentation.
>

I reused the AGSParser, which is GNUstep documentation tool. I have made no
modifications to it, just used comments for getting additional information
about ivars, as there is no other way to add it.

Btw. the keywords can stay in comments and they can be changed to @something
and
be ignored by the documentation tool. Or the documentation tool can additionaly
automatically generate accessor methods documentation.

> Given that developers are lazy to document their source and often headers
> are
> a good place to start studying undocumented software, missing method
> declarations and misleading keyword choices do not help this situation.
>

I do not understand what do you mean by this. If you mean that in the .h file
that was posted as an example were no method declarations, that was
intentional, because they were not needed to show the ability generator :-)

Concerning "misleading keyword choices" I am open for any better suggestions.
Later yesterday I changed the keywords to: public, noarchive, readonly and
object.

> All in all, personally I would prefer people used a macro-based solution
> (discussed before on the list) which would at least be obvious to a casual
> reader.

Excuse me but I do not agree with this. Maco-based solution solves nothing, as
there is no way how to work with lists in C macros. For example, you change a
variable name and you have to change it in 1 dealloc + 2 accessors + 2
encodings + 1 interface = 6 places. Same for addition/removal of the variable.
With plain attributing of an instance variable, you just change the name once.

I'll stay with attributing ivars somewhere in @interface - i think that it
belongs there and moreover it is more comfortable ;-)

Best regards,

Stefan Urbanek




reply via email to

[Prev in Thread] Current Thread [Next in Thread]