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

 
 

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

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

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

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by FredKiefer (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 03 May 2010 09:03:50 AM UTCCaSStatusNone=>In Progress
      Percent Complete0%=>40%

    Back to the top


    Powered by Savane 3.1-cleanup