taskGNUstep - Tasks: task #5607, Change class instance variables...

Group
 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #5607: Change class instance variables for ease of extension in future

Submitter:  Richard Frith-Macdonald <CaS>
Submitted:  Sat 27 May 2006 07:16:46 AM UTC
   
 
Category:  Foundation Should Start On:  Sat 27 May 2006 12:00:00 AM UTC
Should be Finished on:  Wed 30 Aug 2006 12:00:00 AM UTC Priority:  5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  None Percent Complete:  40%
Open/Closed:  Closed Effort:  0.00

Wed 09 Mar 2016 10:05:46 AM UTC, comment #5: 

The non-fragile ivar changes are probably widespread enough that this is now obsolete.

Richard Frith-Macdonald <CaS>
Group Member
Mon 03 May 2010 09:03:50 AM UTC, comment #4: 

The base library is now completed.  The gui library remains to be done.

Richard Frith-Macdonald <CaS>
Group Member
Mon 09 Jun 2008 11:48:52 AM UTC, comment #3: 

This work item may become obsolete through David Chisnall's new non-fragile ivar changes.

Fred Kiefer <FredKiefer>
Group Member
Sun 28 May 2006 05:45:42 AM UTC, comment #2: 

This is not for subclasses to use themselves (though of course thay can use similar mechanisms if they want to).  The idea is that we essentially hide the instance variable layout so that wee can change it at any time without breaking any code which uses the classes in our librarties.  ie. it's so that subclasses don't have to be recompiled in order to work with newer versions of the libraries.
eg.
We might change the NSConnection class to have an additional ivar of type 'void*' perhaps called 'internalNSConnection'.

This ivar is a pointer to a structure containing instance variable information for an NSConnection object.  The structure for an instance is allocated when the instance is initialised (or the first time it is needed) and deallocated when the instance is deallocated.

This internal data structure could either contain new instance variables we find we need in later versions of the library, or we could move all existing instance variables (except ones deliberately made public of course) into it, so the the only remaining instance varibale is the pointer to the structure.

Now, if we are confident that the existing ivars will continue to be used, there is no point moving them into the internal structure, but if we have any doubt (eg the class may get competely re-implemented and use different internal data) then it makes sense to move existing ivars into the internal data structure at the point where we add the pointer ivar.

However ... the laest work solution is to simply add the pointer ivar to each class.  That is all that's needed for future-proofing, as the code to allocate/deallocate the data structure can be added later when needed, and in the event of a later rewrite of the class, obsolete ivars could be left there unused while the new implementation could use its own new information in the internal structure.

NB. this should not be done for every class ... some classes have tiny sets of ivars and are lightweight, created/destroyed frequently, so having to allocate/deallocate an internal data structure wiith each instance would be a stupid overhead, and evena dding the pointer ivar would be a significant memory overhead.  Mostly such classes are extremely unlikley to change implementation and don't need this sort of futureproofing.  NSDate and NSNumber are good examples ... they are only ever likely to need one ivar to store the datetime/number, they are stable, they are small, and we create/destroy lots of them so memory footprint and create/destroy efficieincy are important.  At the other end of the scale are large classes such as NSConnection and NSTextView, where an instance persists for a long time, has lots of ivars and has complex behavior which may need to be supplemented and/or rewritten in later versions of the library.

My suggestion is to  ...
1. leave very lightweight classes alone
2. just add the pointer as a futurproofing measure for most classes.
3. add the pointer and move ivars of a (very) few complex classes (likely to be reworked) into internal structurues


Richard Frith-Macdonald <CaS>
Group Member
Sat 27 May 2006 12:09:07 PM UTC, comment #1: 

We have discussed this before, still it would be great to have examples how this would be implemented to really understand the details.
Are we just going to provide the possibility for subclasses to use this mechanism or would we use it ourselves in the GNUstep libraries?
There are very few places, where I would advocate to move instance variables into this new private storage. Perhaps I am still missing the point here.

Fred Kiefer <FredKiefer>
Group Member
Sat 27 May 2006 07:16:46 AM UTC, original submission:  

We should modify classes so that they can be easily re-implemented in the future without the need for code that subclasses them to be recompiled.

This generally means adding an instance variable that can point to private data and perhaps moving existing instance variables into the private data area.  We may elect not to do this for a few cases where the memory footprint of a class instance is important and the class is highly unlikely to change implementation.

A whole library should be done at once, so we can bump the major version number and announce that everything built to run with that version of the library should also
run with later versions without a recompile.

This would be a major step to ensuring permenant backward compatibility.

Richard Frith-Macdonald <CaS>
Group Member

 

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

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 CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  •  

    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.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-09 CaS Open/ClosedOpen Closed
    2010-05-03 CaS StatusNone In Progress
        Percent Complete0% 40%

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code