Mutability, Linked Lists, and Enumerators (C# vs. Objective-C 2.0)

by Jon Davis 30. August 2008 22:22

A few job interviews ago, I was asked about the meaning and/or significance of the term "immutable". I knew that immutable means doesn't and cannot change, and that value types (numbers and strings) and structs in C# are immutable. I knew that structs being value types get stored on the stack, and, if small, tend to be more performant. But I didn't have the background to put two and two together, so I wasn't able to explain why it mattered.

I'm still trying to wrap my hands around how stack optimizations really work, actually. But meanwhile, another job interview asked me what I knew about data structures and, "if .NET had no arrays, how would you manage multiple objects"? I was shocked with myself. These were rediculously simple questions, going back to the basics of computer science. But, for that matter, these were among those rare questions that favor the value of college education, which I lack, over experience. But it takes neither college education nor much experience to suggest a "delimited list in a string" which I didn't even think about for some weird reason--although, technically, any such serialization requires an array of char or byte.

I could be wrong but I *think* the correct answer to "in the absence of .NET arrays, how could you manage a set of n objects" would be to create a linked list. Having been abstracted from how lists work for so long, I never even looked this simple thing up until now.

Glad that's over. I feel so dumb (and no, darn it, I did NOT ride the short bus to school!!), but refreshing myself on that is finally behind me.

Anyway, back to the mutable vs. immutable discussion, the Cocoa API in the Mac OS X world makes a strong emphasis on isolating certain objects, most notably collection objects (NSSet, NSArray, NSDictionary) as either mutable (NSMutableSet, NSMutableArray, NSMutableDictionary) or immutable. They're completely different classes, that perform the same function but with different optimizations, so the immutable (unchanging) version, which is the default (lacking the "Mutable" in the name), is extremely performant.

C#'s APIs and compiler abstract this stuff so significantly that most C# developers (like me) would likely find all this really odd.

Here's the blog post that motivated me to post this. 

Incidentally, I noticed something else about Cocoa. In C#, the syntactically-ideal iteration loop for a collection looks like this:

foreach (string s in myArray) {

The problem is that foreach typically has a performance hit versus using

for (int i=0; i<myArray.Length; i++) {
    string s = myArray[i];

.. which happens to be fuglier. And, to be honest, it shouldn't be faster when working with lists because an indexer has to iterate through the list from the top to find the i node, whereas an enumerator on a linked list should require no reiteration. So I don't get it.

Meanwhile, though, C# 2.0 introduced List<string>, which offers the delegate-driven ForEach( delegate ( string s) { .. } );, which is far more performant.

C# 2.0:
myList.ForEach ( delegate (string s) {
} );

C# 3.0:
myList.ForEach( s => Console.WriteLine(s); );

In C#, AFAIK, foreach internally just instantiates an IEnumerable object's IEnumerator object and then calls its MoveNext() method, but then so does List<T>.ForEach, so I don't know (haven't looked at the MSIL or Reflector) what it's doing different between the two.

But Objective-C 2.0 apparently went through a wholly different process of evolution, where its foreach equivalent is actually much faster than its enumerator MoveNext() equivalent.

Interesting stuff.

Objective-C ~ C# 3.0

by Jon Davis 26. August 2008 10:50

Just a quickie note, as a side interest (for fun) I'm trying to get back into Cocoa development (still in newbie stage) and I'm watching the iPhone introductory videos. There's a part of one of the videos related to Cocoa Touch that had me reminded of C# 3.0.

  1. Objective-C uses delegates as an alternative to method overrides. I don't recall, outside of callbacks / function pointers, whether C/C++ supported "delegates" in the first place. But the approach taken by Cocoa here really surprised me, how significantly it looked like my Evented Methods pattern [ 1, 2, .. ] I proposed a few days ago, since technically events are just anonymized delegate invocations. Kinda gave me goose bumps, seeing evidence that I was on the right track.
    • On a similar vein, @selector returns a SEL, which is the type name for a selector but the value is just a const char* that is the method name. Selectors are good for invoking methods you don't know the name of until runtime.
  2. Objective-C has something called "categories", which I feel is a terrible name, but given the description given by the presenter in the video it sounds like Objective-C's categories are functionally the same as C# 3.0's extension methods, although not in form. So, Objective-C supports extension methods, they're just called "Categories", which, again, is a really weird name.
  3. It's easy to take C# constructors for granted. In Objective-C, the equivalent functionality is the far less elegant invocation of an "init" method (an initializer).
  4. Properties, as being different from methods, functions, and fields, are assumed in Objective-C, as they are in C#. The C# 3.0 compiler supporting the syntax of myType myProp { get; set; } as an inferred implementation of myType _myProp = default(myType); myType myProp { get { return _myProp; } set { _myProp = value; } } is actually not new to C# 3.0, either. While the form is different, Objective-C has something similar. It has a @synthesize keyword that generates the implementation code for the getter and the setter.
Note: this blog entry might (or might not) grow.

Currently rated 1.0 by 1 people

  • Currently 1/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

Software Development | Mac OS X


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  May 2021  >>

View posts in large calendar