Re: ANN: Generator in DevKit

[Adrian Robert]

Hi,

> I have put the ObjectiveC generator into the DevelopmentKit framework. 
> It is slightly modified version and still it is a prototype. It reads 
> attributes from instance variable comments.

This looks like an excellent start on a useful tool.

I am wondering whether you couldn't use the terms "exposed" and 
"hidden" in place of "public" and "private" for specifying 
getter/setter generation?  This would prevent the confusion mentioned 
earlier, which is a real issue since 'public', 'private', etc. have 
very well-established meanings in Objective-C and other OO languages, 
while the question of whether to expose something using accessors is a 
separate one altogether (despite your point about the meanings being 
somewhat conflated in modern practice).

A second issue that raises its head is that the accessors created are 
in essence "private" since they are not in the header file and 
therefore unknown unless someone has the source.  This is useful in 
certain contexts, but it might be nice to also have an option where you 
write the accessor declarations yourself in the header file but the 
generator then still generates the source.  Even this is a big win 
since writing accessors can be tedious, especially if you want to do 
the proper retain/release rituals needed in the setter.  (This should 
be another keyword option BTW...)

Also, it could generate stubs for any other methods that are declared 
in the header (like "implement interface" operations in Java IDEs and 
Emacs JDE).

Finally, it would be nice to be able to have an incremental update 
facility, if you later add instance variables (or take them away) from 
a class, to be able to update the generated code (but leave any 
manually added code untouched).  I guess this starts to get tricky, but 
it would be useful.

This brings me to a larger question, which is do you and/or Serg Stoyan 
have any plans to (eventually) integrate the DevKit framework's 
capabilities into Project Center?  I realize that (a) they are 
independent projects and (b) many people prefer to stick with a command 
line + emacs/vi operating mode in development -- but at the same time 
it is exactly the capabilities you are building in DevKit that often 
make IDEs a compelling proposition even when their editors can't hold a 
candle to emacs.

thanks,
Adrian