5 ms·

"Objective-C sucks" is just silly. If you know and like C#, of course you'll like developing for WP7 more. Weird that he talks about null references in Objectiv

• S_A_P 16y ago
  I actually was just wishing c# had as terse of a null check syntax as ObjC. I love the fact that I can type if(!object) [[Do something]about it] vs if(object == null) DoSomething.Aboutit I know its a small thing, but my typenames are usually lengthy so in practice C# statements can get character heavy.
  • nlogn 16y ago
    This is actually really easy to do in c#: public static bool operator true(Class c) { return c != null; } public static bool operator false(Class c) { return c == null; } To avoid redoing this for each class you can just derive from a base class that implements these.
    • S_A_P 16y ago
      well I know that it is possible, I was thinking of trying to write a similar type function with an extension method, but I just like how its included out of the box in ObjC. Really I think for a general purpose language C# is more flexible and while leveraging .NET you have more tools available to develop rapidly. Part of me feels that Im not "really programming" when I write managed code though. I like writing C and ObjC because I feel like Im actually flipping switches on the CPU. It is silly I know(and all in my head), but being lower level seems to excite me more. In reality I think its all about the right tool for the job, and choice is good.
• ektimo 16y ago
  I meant it doesn't complain when sending a message to a nil object though this is probably not what you intended and makes tracking down bugs harder... or maybe I just have C++ mindset.
  • alextgordon 16y ago
    I think when many people hear about ObjC's nil semantics, they use it as a pretext for dropping all their null checks. This is a mistake, and you're right, it will make debugging exceptionally difficult when nils start falling through five levels of functions and propagated through ivars. The trick is to use null checks almost like you're writing C++, but drop them when they are unnecessary and inelegant. Convince yourself that a null check is unnecessary before removing it. This way you're reducing the chance of bugs and making them easier to pinpoint. For example, you can do: if ([someArray count]) rather than if (someArray && [someArray count]) On the other hand, you may be asking for trouble if you do [[someArray lastObject] dance]; without checking [someArray lastObject] for nil, since if someArray is empty, then nothing will dance and you won't know about it. tl;dr: Messaging nil is not idiot-proof but it makes code read better.
    • ryanpetrich 16y ago
      The worst offender is the comparison methods: NSString *myString = nil; if ([myString compare:@"something"] == NSOrderedSame) { ... }