• Home
  • Assertions
  • Poetry
  • Programming

Record and Reverie

General things I find interesting

Feed on
Posts
Comments
« What Objective-C can learn from Java, Part 2 (Abstract Classes)
What Objective-C can learn from Java, Part 4 (Namespace) »

What Objective-C can learn from Java, Part 3 (Single Source File)

Dec 30th, 2010 by Graham Booker

This is the third is a series of blog posts I’m writing on things that Objective-C can learn from Java. The other parts can be found here:
Part 1 (Generics)
Part 2 (Abstract Classes)
Part 3 (Single Source File)
Part 4 (Namespace)
Part 5 (Exceptions)

Objective-C still retains a lot of its heritage from it’s C beginnings. This includes using two files, a header and a source file, for each class. In a strictly object oriented environment, the header file contains the class definition (super-class and instance variables), public property definitions, and any public function declarations. The source file contains all of the function implementations, including synthesize statements. In contrast, Java contains all the functions of both files in a single file. To one who knows better, as in one who has used the single file environment, the two files for each class becomes a pain.

As to why this is a pain, one needs only to visit the following scenario: Add a property called name to the Person object. In Objective-C, one needs to add the instance variable to the class definition and the property declaration to the header file. Then, add a @synthesize statement to the implementation and add [name release]; in the dealloc (I’m neglecting Objective-C’s ability to create the instance variable in modern runtimes since it denies direct access to it in the code). In contrast, Java needs the instance variable added to the class, and in the same file add the setters and getters (which if using Eclipse, can be auto-generated). Java is able to accomplish this because it uses a two-pass compiler. One pass parses the class definition and function declarations, and the second generates the actual code. Any import statements only need the first pass of each file.

In Objective-C, some of this pain can be eliminated using my fork of ObjectiveCAnnotate, but this is only part of the way to what should be done. What Objective-C really needs is to use a single source file, and auto-generate the equivalent header file when the source file is saved (and save it only if it is different to reduce unnecessary re-compiles). This serves as the equivalent of Java’s first complier pass. Then, the actually compile step executes the second pass, using the generated header and the code within the source file. Using the paradigm, several changes should be made to the source file. The obvious is adding a public (or maybe @public) to functions that should be included in the header file. Additionally, the property syntax can be combined with the instance variable declaration and possibly with synthesize to create something like @property (nonatomic, retain, synthesize) NSString *name to take the place of the instance variable declaration, the property declaration, and the synthesize statement. Since this is by far the most common use case, why not simplify it to make things easier for the developer? The instance variable still needs to be in dealloc, but now changes in instance variables has been reduced to two places.

This change doesn’t completely eliminate the need for header files. The old C-style declarations, such as C-functions, structs, enums, externs, typedefs, and defines, would still need to be in a header file on their own. Since most classes do not make these declarations, most classes wouldn’t need a distinct header file. In the cases where such a definition is made, it is often better style to include all of the definitions in a single types header file for the framework/project.

This does necessitate a change to the import statements for a class. In the two file environment, one can separate the import statements between the header and source files, but in a single file, this separation no longer exists. However, the compiler could be made smart enough to track the locations of types it inserts in the generated header file, and include those location in the header file’s import statements. This would mean the header file would contain the import statements for the super-class, and any C-style declarations only. There is no need at all to include the import statements for other classes, as the existing @class declaration tells the compiler all it needs to know at this stage. This would also eliminate the bad coding practice of including unnecessary import statements in the header file, a practice which I’ve seen too often by new programmers who were never taught of its dangers.

Impact on Runtime:
None, this is pre-processor only

Impact on Code:
Reduction in code complexity, ease in modification. Reduction in need to reference two files to understand a single class.

Tags: Java, Objective-C

Posted in Programming

5 Responses to “What Objective-C can learn from Java, Part 3 (Single Source File)”

  1. on 08 Mar 2011 at 7:12 am1ingconti

    I agree obj can be better, but in my opinion dividing declaration from imlelmentation is a BIG strength of c++ / obj. I do not need to read all java file to know the methods.

  2. on 08 Mar 2011 at 3:43 pm2Graham Booker

    ingconti, I guess you missed where I stated the IDE could “auto-generate the equivalent header file when the source file is saved.” Java actually employs a two-pass compiler, one that scans it and creates the equivalent of header file information, and another that does the actual compilation. I’m advocating that Obj-C adopt the same principle, which actually would result in the similar compile times. As per human reading, almost all of that would be eliminated if Obj-C would adopt Javadoc and Xcode had code completion that actually worked properly.

  3. on 09 Aug 2012 at 2:52 pm3Erik

    This bugged me a lot in C++, but I am totally fine with it in Objective-C since there is much less that needs to be copied each place. You do not have to write private methods or methods that are overridden in header. Properties only have to be written in header now. Copy paste from header is easier than in C++ because you do not need to prefix with classname.

    As others have mentioned I prefer looking at my interface in the header file. I prefer that over java do or IDE. I get one big screen that I can access very quickly to get an overview over the public API and I can jump quickly between methods. In the IDE I often jump to the header file first and then jump to implementation from there.

    I guess an auto generated header file would be nice, but it is not on top of my list of things to change with Objective-C. I think ObjC is almost where it needs to be and that improvements would better be done with another language built on top of the Objective-C runtime which does not need to maintain backwards compatibility with C.

  4. on 09 Aug 2012 at 4:26 pm4Graham Booker

    “Properties only have to be written in header now.”
    So, you’ve never used private instance variables or public methods which are not setter/getters for properties? There’s plenty that goes in the header file.

    You mentioned jumping between files, but that brings to light a critical question. Say you are viewing code that makes a function call and you want to see that function. Should the IDE jump to the implementation or the declaration? Heaven forbid you want to go to an implementation in a subclass in Xcode, but I digress.

    I mentioned ObjAnnotate in my post, and I never do an Obj-C project without it. I strongly believe that this needs to be integrated into the IDE because it saves a lot of busywork that the language requires. Don’t forget that even when using the property declaration without the instance variable, there’s still the @synthesize declaration and renaming or removing a property requires the same to be done in the other file. Why make a human do busywork that a compiler or IDE can do for you?

    Interesting that you should mention building a language on top of the Obj-C runtime when the first four of these posts have little to no impact on the runtime.

  5. on 09 Nov 2013 at 10:06 am5T. Benjamin Larsen

    I think the setup in Objective-C 2.0 is generally sound. The headers should now solely be used for public properties and methods. This makes the header (in most cases) a nice piece of documentation of the class with as little cruft as possible.

    Technically you don’t HAVE to use header classes, but it’s a nice way to separate a class’ interface from its innards.

  • Recent Posts

    • What Objective-C can learn from Java, Part 3 (Single Source File)
    • What Objective-C can learn from Java, Part 2 (Abstract Classes)
    • What Objective-C can learn from Java, Part 1 (Generics)
    • Trac.fcgi Memory Usage
    • Google Link Redirection (cont.)
    • Why you shouldn’t buy A Flip Camera
  • Archives

    2022
    April 2022 (1)
    2021
    May 2021 (1)August 2021 (1)
    2020
    March 2020 (1)
    2019
    November 2019 (1)
    2018
    June 2018 (1)July 2018 (1)December 2018 (1)
    2017
    January 2017 (2)June 2017 (1)August 2017 (1)
    2016
    June 2016 (1)August 2016 (1)
    2015
    January 2015 (1)February 2015 (1)December 2015 (1)
    2014
    June 2014 (1)July 2014 (1)August 2014 (2)
    2013
    February 2013 (2)March 2013 (1)April 2013 (1)June 2013 (1)November 2013 (1)
    2012
    April 2012 (2)May 2012 (1)June 2012 (1)November 2012 (1)
    2011
    January 2011 (1)October 2011 (1)November 2011 (1)December 2011 (1)
    2010
    February 2010 (2)April 2010 (1)June 2010 (1)July 2010 (1)August 2010 (1)September 2010 (1)October 2010 (2)December 2010 (3)
    2009
    January 2009 (1)February 2009 (1)March 2009 (2)May 2009 (1)July 2009 (3)September 2009 (1)
    2008
    January 2008 (1)February 2008 (4)March 2008 (1)April 2008 (6)May 2008 (1)June 2008 (3)August 2008 (1)September 2008 (2)October 2008 (2)December 2008 (1)
    2007
    January 2007 (1)February 2007 (4)March 2007 (5)April 2007 (4)May 2007 (1)June 2007 (6)August 2007 (3)September 2007 (3)November 2007 (3)December 2007 (4)
    2006
    January 2006 (4)February 2006 (10)March 2006 (4)April 2006 (6)May 2006 (2)June 2006 (4)July 2006 (1)August 2006 (1)September 2006 (4)October 2006 (6)November 2006 (3)December 2006 (3)
    2005
    October 2005 (6)November 2005 (13)December 2005 (1)
    2004
    February 2004 (2)March 2004 (1)April 2004 (1)May 2004 (6)June 2004 (6)July 2004 (3)August 2004 (2)September 2004 (1)November 2004 (5)
    2003
    September 2003 (1)October 2003 (3)November 2003 (1)December 2003 (1)
  • Categories

    • Breakaway (5)
    • Family (4)
    • Friends (2)
    • General (151)
    • Nature Pictures (8)
    • Politics (2)
    • Programming (41)
    • School (11)
    • SysAdmin (8)
    • Teaching (2)
  • Tags

    AC3 Ads Code Frontrow Java Objective-C Open Source Perian Perl permissions plex plugin RSS Sapphire School Servers ZFS

  • Pages

    • Assertions
      • Female Friends Who Won’t Date You
      • Not Dating Friends
    • Poetry
      • Curtis Staying Over
      • Girl Questions
      • Scaring Girls Off
      • Summer’s End
    • Programming
      • Fire Development
      • Kyocera Ringtone Converter for the Mac
      • Perian
      • Text Compression

Record and Reverie © 2022 All Rights Reserved.

WordPress Themes | Web Hosting Bluebook