• Home
  • Programming

Record and Reverie

General things I find interesting

Feed on
Posts
Comments
« What Objective-C can learn from Java, Part 3 (Single Source File)
FreeBSD with ZFS root »

What Objective-C can learn from Java, Part 4 (Namespace)

Jan 8th, 2011 by Graham Booker

This is the last 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)

For one who has programmed in other object oriented languages, Objective-C stands out with its complete lack of namespace. As a result, classes have a prefix, such as Apple’s common NS and UI prefixes. On the mac side of things, every class under the sun seemed to start with NS, such as NSString, and confusion is added when on the iOS side, several classes start with UI, such as UIView. This is due to the fact that without a concept of namespace, Objective-C cannot have two classes with the same name, regardless of whether the classes are public or not.

If I were designing an application which communicated on a network as well as talked to a database, I would split the two pieces into separate segments, or in Java, packages. Inside each package, I would likely have a Connection class, which has completely different meanings within the network and database packages. Inside those packages, especially if the Connection class was internal to the package only, I could name both classes Connection without any concern and the code inside the package would immediately understand what Connection actually meant. This is possible in Java because the actual class names are com.cod3r.app.network.Connection and com.cod3r.app.database.Connection. Since Objective-C does not have namespaces, I would have to name these NetworkConnection and DatabaseConnection.

Now, take the above scenario, and add another type of network connection. Then take that new network connection and add new specific case to it, making a new class. In Java, the package name gets longer where as in Objective-C the class name gets longer. I have run into cases where this borders on ridiculous if one wants the class name to define what it actually does without ambiguity. The class is within the Sapphire plugin. In the project, all classes had the prefix Sapphire since it was a bundle included in another application and had to make sure there was never a class conflict. The project has the concept of a Directory and a VirtualDirectory was a directory which wasn’t associated with a directory in the file system. There is a type of VirtualDirectory that was Custom meaning it was defined by the user instead of already in the code. Finally, this particular class is responsible for importing these CustomVirtualDirectory objects, making the final class titled SapphireCustomVirtualDirectoryImporter. In Java, this class would have been Importer within the net.nanopi.sapphire.directory.virtual.custom package. The difference is the fully qualified classname would only be used in the import statement, and the short class name would be used in the code, instead of the really long classname used in every location as seen in Objective-C. This becomes particularly relevant when it comes to code completion that produces a terribly long list until nearly the entire class name is typed.

The lack of namespace becomes problematic when one uses third party libraries. Take the above Sapphire example and another plugin developer finds a completely unrelated library titled Sapphire. If that library happened to have a directory titled SapphireDirectory, then both plugins cannot be loaded at the same time. Java goes even further with a two-level namespace such that two jars (bundles) with the same fully-qualified classname still don’t interfere since they are in separate jars.

Adding namespace is necessary for adding inner-classes, which Objective-C outright doesn’t use, but could in proper circumstances. Inner classes are useful for implementing delegate methods. When setting a delegate, one typically passed in the instance of an inner class rather than the current instance. Not adopting this model has the issue when a single class is set to be the delegate to multiple objects, such as being the delegate to two table views. Apple works around this design by making each delegate method have the first parameter be that of the object calling it’s delegate, such as the table view. This means if the code is different between the two, every single delegate method needs have an if statement to determine which table view is being processed, and eliminates the ability of one to skip implementing an optional method for one table but not the other. Both of these problems are eliminated with inner-classes. Finally, the lack of inner-classes severely cripples the ability of a super-class to use the Key Value Observing within Objective-C since the delegate and unregister methods were written in a way that really require an inner-class to work properly (I can see how to easily break some code in a sub-class or super-class since this was designed so badly).

Impact on Runtime:
Small. I don’t know the specifics of the runtime, so I can’t judge the exact impact, but this will result in longer effective class names, which may increase lookup times. Inner-classes would need an instance variable for their outer-class to access it’s instance variables, resulting in additional pointer deference for accessing outer-class variables.

Impact on Code:
No longer need to create necessarily long class names; programmer can use short class name without concern. Frameworks need not have a class prefix. More flexibility in object design.

Tags: Java, Objective-C

Posted in Programming

2 Responses to “What Objective-C can learn from Java, Part 4 (Namespace)”

  1. on 28 Sep 2011 at 11:26 am1Fredrik Olsson

    I am among the first to admit that prefixes is a poor mans solution to lack of namespaces. But that do not mean it is confusing or even without use. With the exception of old frameworks like AppKit and Core Data the use of prefixes is very predictable; its a marker for which framework that defines the symbol.

    Take for example UIColor, NSColor and CIColor (From UIKit, AppKit and Core Image respectively). If all three of them had been named Color as in Java it would not be obvious which type it is without scrolling to the top of the source code and look at the imports.

    Not knowing the framework of origin is generally not an every day problem. But knowing if a type is your own (or a colleges), or from a framework is.

  2. on 28 Sep 2011 at 1:02 pm2Graham Booker

    Fredrick, I’m afraid your opinion is tainted by the lousy IDE that is Xcode. First of all, the confusion comes into play when one is writing code and has to stop and think, “what framework is this class in again? Is it a CG or UI object?” In a real IDE, one would simply type the name, minus any prefix, and the code completion would show the options, with the framework path to which it belongs. Additionally, knowing the type of an object is quite simple in a proper IDE; the mouse-over text reveals the fully qualified class name.

    I say that Xcode is not a proper IDE because I have had to use it. It’s code completion often doesn’t work at all (just last week it never displayed anything for 2 hours straight despite hitting ctrl-space and F5 numerous times), and when it does work, it tends to show hundreds of completely irrelevant choices. Some of this is due to the language, which by its nature is not strongly typed, but that issue can be mitigated to a far greater extent that is currently.

  • Recent Posts

    • Goodbye Roku, Hello GoogleTV
    • The Case for Ripping Media
    • FreeBSD with ZFS root
    • What Objective-C can learn from Java, Part 4 (Namespace)
  • 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

    • Programming
      • Fire Development
      • Kyocera Ringtone Converter for the Mac
      • Perian
      • Text Compression

Record and Reverie © 2022 All Rights Reserved.

WordPress Themes | Web Hosting Bluebook