bugGNUstep - Bugs: bug #24751, Gorm should be able to update...

Group
 
 

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

Submitter:  Sebastian Reitenbach <buzzdee>
Submitted:  Wed 05 Nov 2008 07:32:37 AM UTC
   
 
Category:  Gorm Severity:  3 - Normal
Item Group:  Change Request Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Declined
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 24 Jan 2018 03:09:06 PM UTC, 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.

Gregory John Casamento <gcasa>
Group administrator
Wed 05 Nov 2008 06:17:57 PM UTC, comment #3: 

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.


Sebastian Reitenbach <buzzdee>
Group Member
Wed 05 Nov 2008 02:37:08 PM UTC, comment #2: 

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.

Gregory John Casamento <gcasa>
Group administrator
Wed 05 Nov 2008 08:14:34 AM UTC, comment #1: 

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.


Richard Frith-Macdonald <CaS>
Group Member
Wed 05 Nov 2008 07:32:37 AM UTC, original submission:  

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

Sebastian Reitenbach <buzzdee>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by buzzdee (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-24 gcasa StatusNone Wont Fix
        Open/ClosedOpen Declined
    2008-12-02 gcasa Item GroupBug Change Request

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code