Re: ANN: Generator in DevKit

[stefan]

Hi,

Citát Adrian Robert <arobert@cogsci.ucsd.edu>:

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

Thanks! :)

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

Why not "exposed" and "hidden"? I have not thought about those, but i like
them.

Note that this is exactly one of things I wanted to know from other potential
users - more appropriate attributing. Point is to have something readable,
understandable and not confusing for others, not only for me.

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

I have thought about that. Here is one possible non-polished case and its
solution:

You have source files .h and .m in some project directory. Say you have MyClass
in MyClass.h. You use a tool that automaticaly generates sources. You end up
with:

- MyClass.h
- MyClass.m
- MyClass-generated.h /* category with method declarations */
- MyClass-generated.m
- makefile.generated  /* list of generated .[hm] files, so you can include them
in your makefile */

What you need to do is to #import <MyClass-generated.h> at the end of the
MyClass.h

Another solution should be that you use MyClass-source.h as original and
MyClass.h will be generated by appending @interface MyClass(GeneratedMethods)
to the end of the MyClass-source.h. This one is better for frameworks, as you
will have usualy only one .h file per class.

As I have said, it is not polished. Do you have any better suggestion for that?

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

Can you provide some concrete examples of usage?

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

Well, for that reason I would go with separate files: generated and
user-maintainable. What you want is more complex development and i am afraid
that this kind of automaticlay generated source would not fully satisfy you.

For more complex operations I would suggest to use more advanced IDE as
described at http://ide.roard.com (unfortunately it seems to be
down at this moment). There are design notes and screenshots for a class
oriented development environment, where you do not even know about source
files. You only know about classes, their instance variables and their
methods. In such IDE almost all source files are generated. It is a step forward
and the chain now contains one more step: classes -> sources -> ASM -> binary.

Personally I do not like any automaticaly generated sources where user needs to
insert his code. Either generate automaticaly full sources or let the user 
write it. Normal user should not be allowed to edit generated code. 

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

Well ... reason for (b) is that there is no fully functional development
environment for GNUstep. ProjectCenter is quite usable, but lacks lots of
features for easy development. And as I have mentioned before, there were some
suggestions for more advanced IDE that will let you focus on your application
design instead of source files. It should be not difficult to build such class
oriented IDE on top of the Development Kit. It will be just a graphical wrapper
for DevKit classes.

Note that some of features that developers use in advanced text editors will be
not needed in such IDE or they will change, because the philosphy changes from
file orientation to class/method orientation.

First working simple prototype of the IDE can be done in 3 days with average
knowledge of GNUstep. I can give pointers and notes if someone would be
interested.

What do you think?

Best regards,

Stefan Urbanek