[bug #24751] Gorm should be able to update existing class files

[Sebastian Reitenbach]

URL:
<http://savannah.gnu.org/bugs/?24751>

Summary: Gorm should be able to update existing class files
Project: GNUstep
Submitted by: buzzdee
Submitted on: Wed 05 Nov 2008 07:32:37 AM GMT
Category: Gorm
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

Hi,

This is not really a bug, more an enhancement request.

It would be great if Gorm could update existing class files.

E.g:
- Create a project in PC, and open the Interface with Gorm.
- Create the interface in Gorm, instantiate classes and create the class
files there
- Add the created interface class files in PC to the project, and fill the
methods with some logic, and save these
- then recognize some outlets and actions are missing for the interface,
therefore open gorm again, and add the missing outlets and actions.
- then it would be nice if Gorm could just update the class files that it
instantiated before, e.g. checking which methods/variables are already there
in the file, and then adding/removing/renaming missing methods and variables,
update the dealloc method if neccessary.

Sebastian




_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?24751>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Richard Frith-Macdonald]

Follow-up Comment #1, bug #24751 (project gnustep):

This was something I considered when I first wrote Gorm, but the variety of
ways in which an ObjC source file can be written (when you add in the
complications of the use of the C preprocessor and conditional compilation
etc) mean that it's almost impossible to do reliably. The programmer would
need to be very careful about what they did, in order to avoid breaking the
parsing etc.

The only solution I could come up with was to have an option to scrap the
normal paradigm of allowing the programmer to use their favorite editor, and
store the code for each individual method in a separate file or database
record, and have an integrated editor allowing you to edit the contents of one
method per window. If Gorm controlled the editing environment that way, it
could just generate the source code on demand by pasting together the
individual method implementations together with some prefix code before the
method implementations I guess.

It would be a big job to do add the editing facilities you would want though
,,, so I just went the way NeXT went, though the idea of an integrated editor
of that sort still appeals to me.



_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?24751>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Gregory John Casamento]

Follow-up Comment #2, bug #24751 (project gnustep):

I agree with Richard. Adding this functionality to Gorm would mean that the
source code generator, which is currently very simple, would need to load your
code, parse it and figure out where the beginning and ending of each method
is, preserve the contents of each method, regenerate the skeleton and then put
everything back. It's not Gorm's function to do this and never should be.

One thing that I have been considering doing is implementing more integration
between Gorm and ProjectCenter. Currently there is none, but it would be
possible to have PC notify Gorm whenever a new outlet or action is added to a
class. PC already does some on the fly parsing of the code that is entered.
This would be no different except it could simply recognize an outlet or
action and notify Gorm that something has been added.

This is already something that Xcode 3 does on the Mac.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?24751>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Sebastian Reitenbach]

Follow-up Comment #3, bug #24751 (project gnustep):

Hi,

thanks for your replies to this request.

I don't know how the actual code generator works, but I think it is just
creating the class files, adding the outlets and actions to a template, and
writes them to the place specified by the user.

I thought it could work way like this:
gorm tracks for which classes and where it created initial class files. When
later e.g. adding outlets or actions to such a class,
where the class files meanwhile were potentially edited by the user, there
could be an update class files menu entry.
When choosing to update the class files, gorm would have to open the existing
files, scan it for the existence of each method or variable declaration, if
found, don't touch it, otherwise add it.
Maybe in the end open a window, informing the user, what was done.
Gorm just needed to open the .h file, and e.g. scan for the name of the
method or variable. If found, it can assume that it was there from the initial
creation of the class files via gorm, and go on with the next method or
variable. If it cannot find it, it will be added.
Renaming to rename or delete a method, gorm needs to track these actions
between creation and subsequent updates.
of course, before any update of existing files, gorm should create a backup
of the existing ones ;)

but I guess, you are probably right and that's not just easily implemented
implemented ;)

However, the other way around you suggested, let PC notify Gorm about added
outlets and actions, also sounds pretty attractive.



_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?24751>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Gregory John Casamento]

Update of bug #24751 (project gnustep):

Item Group: Bug => Change Request


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?24751>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Gregory John Casamento]

Update of bug #24751 (project gnustep):

Status: None => Wont Fix
Open/Closed: Open => Declined

_______________________________________________________

Follow-up Comment #4:

This is an interesting idea, but it will likely be done in either the
successor to Gorm and PC or in PC at some point. For now I am declining this.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?24751>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/