• (cs) in reply to RFoxmich
    RFoxmich:
    QJo:
    Disgraceful. 8 character subroutine names was good enough for we engineers programming in FORTRAN 77 on the VAX, it's good enough for you pesky kids. Think yourselves lucky you doing have to program in FORTRAN 4 in which you're limited to 6 character identifiers, uppercase only and the arithmetic IF.

    Bah. You kids of today, don't understand the first thing about programming. GOML.

    Absolutely. The method basename updateCellWithLiveStreamId Should have been UCWLSID

    That's pretty clear right? And one character to spare in case you need to 'overload it' you can use e.g. UCWLSID1 etc.

    Yeah but that only works if the data is floats. Otherwise it'll have to be IUCWLSID :-)

  • gnasher729 (unregistered) in reply to Anon
    Anon:
    Looks pretty par for the course with objective-C. I just finished an app using Xamarin and C# but couldn't completely avoid a unpleasant dip into Objective-C for some third party libraries. And of course, the free third party libraries all worked fine and the one we actually paid for is a total fustercluck.

    Also annoying, Apples habit of having methods (or messages) with name like "ViewDidAppear" rather than the more terse but perfectly understandable "ViewAppeared". There's a whole bunch of "xDidy" and "yWillx"

    "viewWillAppear" absolutely clearly means that a view will appear. "viewDidAppear" equally clearly means that a view has appeared.

    "ViewAppeared" could mean anything. It could be a method returning the view that has appeared. And it cannot distinguish between a method being called before and a method being called after the event.

    But then some people are just bad at naming methods.

  • Anon (unregistered) in reply to gnasher729
    gnasher729:
    Anon:
    Looks pretty par for the course with objective-C. I just finished an app using Xamarin and C# but couldn't completely avoid a unpleasant dip into Objective-C for some third party libraries. And of course, the free third party libraries all worked fine and the one we actually paid for is a total fustercluck.

    Also annoying, Apples habit of having methods (or messages) with name like "ViewDidAppear" rather than the more terse but perfectly understandable "ViewAppeared". There's a whole bunch of "xDidy" and "yWillx"

    "viewWillAppear" absolutely clearly means that a view will appear. "viewDidAppear" equally clearly means that a view has appeared.

    "ViewAppeared" could mean anything. It could be a method returning the view that has appeared. And it cannot distinguish between a method being called before and a method being called after the event.

    But then some people are just bad at naming methods.

    Yes. And apparently those people work at Apple.

    If "ViewAppeared" is part of the "View" class, then there is no ambiguity.

    And most sane libraries include methods for before events which are, sanely, prefixed as BeforeX. This is much easier to read than trying to distinguish between XWillY and XDidY. Only a moron would think it's a good idea to bury the part that distinguishes between two methods in the middle of a long method name.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Bob Hope
    Bob Hope:
    I also disagree with the people claiming this is not a WTF. I read objective c, and this method signature hurts my soul. Imagine how much it would be improved with only a single "sponsor" structure or class to pass in.

    sponsor:(WTFSponsor *)sponsor1 sponsor:(WTFSponsor *)sponsor2

    Not just in Objective C, but in any (sane) language.

  • (cs)

    it was Facebook, wasn't it? sweet.delicious.irony.

  • (cs) in reply to Anon
    Anon:
    gnasher729:
    Anon:
    Looks pretty par for the course with objective-C. I just finished an app using Xamarin and C# but couldn't completely avoid a unpleasant dip into Objective-C for some third party libraries. And of course, the free third party libraries all worked fine and the one we actually paid for is a total fustercluck.

    Also annoying, Apples habit of having methods (or messages) with name like "ViewDidAppear" rather than the more terse but perfectly understandable "ViewAppeared". There's a whole bunch of "xDidy" and "yWillx"

    "viewWillAppear" absolutely clearly means that a view will appear. "viewDidAppear" equally clearly means that a view has appeared.

    "ViewAppeared" could mean anything. It could be a method returning the view that has appeared. And it cannot distinguish between a method being called before and a method being called after the event.

    But then some people are just bad at naming methods.

    Yes. And apparently those people work at Apple.

    If "ViewAppeared" is part of the "View" class, then there is no ambiguity.

    And most sane libraries include methods for before events which are, sanely, prefixed as BeforeX. This is much easier to read than trying to distinguish between XWillY and XDidY. Only a moron would think it's a good idea to bury the part that distinguishes between two methods in the middle of a long method name.

    View.Appeared
    View.Visible
    View.MakeAnAppearanceInTheSunAndSparkleSparkle
    
  • Andrew Au (unregistered) in reply to ZPedro

    Hashing is probably done in the compiler while building up the symbol table. The method is trying to update UI, so I am pretty sure it is going to be slower than computing hash.

  • Bob Hope (unregistered)

    Not going to get in an argument with the rabid anti-objc folks, but IMO it's a fine language. It gives you the ability to write some very understandable code. It also lets you write unreadable drivel, if that's your thing. I don't think it's the job of a language to stop you being deliberately obtuse.

    Quibbling over viewAppeared vs viewDidAppear seems silly to me, and not a strike against either the language itself or the frameworks that use that naming scheme. Neither name is ambiguous in that context, and the difference is a couple of characters. The only important thing is consistency, and the frameworks are pretty consistent about the xDidy approach, so it's hardly an impediment to getting anything done.

    One argument in favour of DidAppear is that autocomplete will help you out if you're not already aware that "appear" is the verb you wanted (crap, did they use appear, show, materialise...?). viewDid<autocomplete> will show you a nice list of the messages you might be looking for.

  • Worf (unregistered) in reply to Andrew Au
    Andrew Au:
    Hashing is probably done in the compiler while building up the symbol table. The method is trying to update UI, so I am pretty sure it is going to be slower than computing hash.

    Actually, it's computed at runtime. Obj-C is a message-passing language - you don't call Obj-C functions, you send out a message.

    Somewhere in the Obj-C runtime, it looks at the type of the message and figures out who it should route the message to. That function can handle the message, or transform it and pass the message onwards to another object to handle.

    This is how stuff like inline spellchecking and other things can be implemented without the application being aware of it. It also allows for interesting behaviors like injecting classes into a running application and have those new classes be integrated in the message chain. So instead of modifying library calls, a completely different library can handle the message (a few firewall applications use this method - they inject their own message handlers into running Obj-C programs that intercept network connections and handle it in userspace without kernel assistance).

    You can do a lot of replacement without having access to the original source code.

  • bambam (unregistered) in reply to Worf
    Worf:
    You can do a lot of replacement without having access to the original source code.
    Sounds like a virus writers dream.
  • g (unregistered)

    +shapeEffectSingleBlurFrom:withInteriorFill:offset:blurSize: innerGlowRed:innerGlowGreen:innerGlowBlue:innerGlowOpacity: innerShadowRed:innerShadowGreen:innerShadowBlue:innerShadowOpacity: outerGlowRed:outerGlowGreen:outerGlowBlue:outerGlowOpacity: outerShadowRed:outerShadowGreen:outerShadowBlue:outerShadowOpacity: hasInsideShadowBlur:hasOutsideShadowBlur:

  • gnasher729 (unregistered) in reply to bambam
    bambam:
    Worf:
    You can do a lot of replacement without having access to the original source code.
    Sounds like a virus writers dream.
    Absolutely. That's why there are about 100,000 times more viruses on MacOS X than on Windows. Oh wait, it's the other way round!

    Something seems wrong with your theory.

  • gnasher729 (unregistered) in reply to Anon
    Anon:
    If "ViewAppeared" is part of the "View" class, then there is no ambiguity.

    And most sane libraries include methods for before events which are, sanely, prefixed as BeforeX. This is much easier to read than trying to distinguish between XWillY and XDidY. Only a moron would think it's a good idea to bury the part that distinguishes between two methods in the middle of a long method name.

    Let's just agree that there is a difference of about 30 between our IQs.

  • Norman Diamond (unregistered) in reply to QJo
    QJo:
    Think yourselves lucky you doing have to program in FORTRAN 4 in which you're limited to 6 character identifiers, uppercase only and the arithmetic IF.
    Fortran 4 had logical IF.

    The real pain came when converting a Fortran 4 subroutine to Fortran 77. It was easier than converting a VB6 program to VB.Net, but it was still painful.

  • (cs)

    Let's hope the submitter, being Anonymous, does not forgive and does not forget this atrocious code.

  • JimTheJam (unregistered) in reply to gnasher729
    gnasher729:
    bambam:
    Worf:
    You can do a lot of replacement without having access to the original source code.
    Sounds like a virus writers dream.
    Absolutely. That's why there are about 100,000 times more viruses on MacOS X than on Windows. Oh wait, it's the other way round!

    Something seems wrong with your theory.

    Couldn't be because the number of machines that Windows runs on swamps the number of MacOS X? Naw, it has to be some other reason. Linux is programed (mostly) it C, that's why it has so few viruses -- right?

    MacOS has 5 characters while Windows has 7, so of course Windows has more viruses, since 7 > 5.

    Windows first came out in a later year than Mac, and the number of viruses are related to the larger year number.

    ...

  • foxyshadis (unregistered) in reply to Worf
    Worf:
    Andrew Au:
    Hashing is probably done in the compiler while building up the symbol table. The method is trying to update UI, so I am pretty sure it is going to be slower than computing hash.

    Actually, it's computed at runtime. Obj-C is a message-passing language - you don't call Obj-C functions, you send out a message.

    Somewhere in the Obj-C runtime, it looks at the type of the message and figures out who it should route the message to. That function can handle the message, or transform it and pass the message onwards to another object to handle.

    This is how stuff like inline spellchecking and other things can be implemented without the application being aware of it. It also allows for interesting behaviors like injecting classes into a running application and have those new classes be integrated in the message chain. So instead of modifying library calls, a completely different library can handle the message (a few firewall applications use this method - they inject their own message handlers into running Obj-C programs that intercept network connections and handle it in userspace without kernel assistance).

    You can do a lot of replacement without having access to the original source code.

    Windows devs will understand better if you just say, "Everything is a COM method." Not coincidentally, COM has more than its share of brain-busting quirks, too.

    While roll-your-own plugin architectures aren't hard to do, pretty much everything on Linux prefers tightly coupled and controlled, and if the ABI breaks and you don't have time to recompile the OS and every related package, well, you obviously didn't need it that bad anyway.

  • (cs) in reply to gnasher729
    gnasher729:
    "viewWillAppear" absolutely clearly means that a view will appear. "viewDidAppear" equally clearly means that a view has appeared.

    "ViewAppeared" could mean anything.

    Is German your mother tongue?

  • polanski (unregistered)

    Oh, let me guess, it's Facebook. Their Android app is a disaster, and with this sort of WTF coding, I believe that iOS version can't be much better.

  • Anon (unregistered) in reply to gnasher729
    gnasher729:
    Anon:
    If "ViewAppeared" is part of the "View" class, then there is no ambiguity.

    And most sane libraries include methods for before events which are, sanely, prefixed as BeforeX. This is much easier to read than trying to distinguish between XWillY and XDidY. Only a moron would think it's a good idea to bury the part that distinguishes between two methods in the middle of a long method name.

    Let's just agree that there is a difference of about 30 between our IQs.

    I agree, but I think you flatter yourself to suggest you are only 30 points behind.

  • (cs) in reply to polanski
    polanski:
    Oh, let me guess, it's Facebook. Their Android app is a disaster, and with this sort of WTF coding, I believe that iOS version can't be much better.

    I forgot that it's still 2012

  • bob nelson (unregistered) in reply to RFoxmich

    you're being far too descriptive, just call it method1.

  • anonymous (unregistered) in reply to bob nelson
    bob nelson:
    you're being far too descriptive, just call it method1.
    Why, are method and method0 already taken?
  • gnasher729 (unregistered) in reply to Anon
    Anon:
    gnasher729:
    Anon:
    If "ViewAppeared" is part of the "View" class, then there is no ambiguity.

    And most sane libraries include methods for before events which are, sanely, prefixed as BeforeX. This is much easier to read than trying to distinguish between XWillY and XDidY. Only a moron would think it's a good idea to bury the part that distinguishes between two methods in the middle of a long method name.

    Let's just agree that there is a difference of about 30 between our IQs.

    I agree, but I think you flatter yourself to suggest you are only 30 points behind.

    If you had an IQ of 170, you would have come up with some clever remark.

  • anonymous (unregistered) in reply to gnasher729
    gnasher729:
    Anon:
    gnasher729:
    Anon:
    If "ViewAppeared" is part of the "View" class, then there is no ambiguity.

    And most sane libraries include methods for before events which are, sanely, prefixed as BeforeX. This is much easier to read than trying to distinguish between XWillY and XDidY. Only a moron would think it's a good idea to bury the part that distinguishes between two methods in the middle of a long method name.

    Let's just agree that there is a difference of about 30 between our IQs.

    I agree, but I think you flatter yourself to suggest you are only 30 points behind.

    If you had an IQ of 170, you would have come up with some clever remark.

    Your IQ is 140? That's nothing to brag about.
  • (cs) in reply to anonymous
    anonymous:
    gnasher729:
    Anon:
    gnasher729:
    Anon:
    If "ViewAppeared" is part of the "View" class, then there is no ambiguity.

    And most sane libraries include methods for before events which are, sanely, prefixed as BeforeX. This is much easier to read than trying to distinguish between XWillY and XDidY. Only a moron would think it's a good idea to bury the part that distinguishes between two methods in the middle of a long method name.

    Let's just agree that there is a difference of about 30 between our IQs.

    I agree, but I think you flatter yourself to suggest you are only 30 points behind.

    If you had an IQ of 170, you would have come up with some clever remark.

    Your IQ is 140? That's nothing to brag about.

    this argument right here.....

    genius!

  • Balu (unregistered) in reply to gnasher729
    gnasher729:
    Something seems wrong with your theory.
    No, it just shows that even virus writers have some dignity...
  • (cs) in reply to ZPedro
    ZPedro:
    If you allow me to be pedantic (thank you), the method signature is not 402 characters long: parameter variable names are not part of the method signature, so it is "only" 158 characters long.

    Yeah, that's definitely a WTF, for one it's clearly the sign of a screwed-up model to be needing that many parameters. More than 8 is a sure sign for me that it's time to refactor.

    One of the most confusing things in the world is the API for Windows. Some of the functions have lots of parameters, many of which could have been inferred from the context. However, the parameters themselves are almost all ints* - whether a HANDLE for... whatever you want to have a HANDLE to (unless it's a HWND), a color (ok, it's an index, but still...), any number of flag sets; so good luck knowing what they are without a reference. I guess that makes it easy to pass them on the stack, though.

    Based on the code snippet here, I'm guessing that MacOS suffers from some of the same design problems.

    (however, I don't know where the "hash" thing comes from: the full ASCII string is not used when passing the message, but what is passed is a pointer to the signature string that was uniqued at process startup, not a hash).

    Forgive me for being dense, but wouldn't you only need to know the hash for a function if you wanted to have an injection call to it from another library?

    Oh, or is this a hash for a string parameter?

    Addendum (2013-11-21 07:53): Oh, and let's not forget passing URLs as NSStrings and not, you know, as NSURLs, as they should, and other such assorted stupidity. Using longs? Have fun when they become 64-bit when iOS starts supporting 64-bit with LP64 model which will happen… two months ago with the iPhone 5S.

    Why would expanding the size of a long in an update break things? Shouldn't the new code just upconvert the smaller values to larger ones? The value would be the same...?

    I think I understand the history, when early languages had only the most rudiment idea of objects, so in that context, it makes more sense than if the code were rewritten today... hey, wait a minute!*

    **Yes, I know, "backwards compatibility." Backwards compatibility, schmackwards compatibility. They eventually break compatibility anyways. Why not just leave in the old stuff as deprecated functions and do things better with new code?

  • anonymous (unregistered) in reply to chubertdev
    chubertdev:
    anonymous:
    gnasher729:
    Anon:
    gnasher729:
    Anon:
    If "ViewAppeared" is part of the "View" class, then there is no ambiguity.

    And most sane libraries include methods for before events which are, sanely, prefixed as BeforeX. This is much easier to read than trying to distinguish between XWillY and XDidY. Only a moron would think it's a good idea to bury the part that distinguishes between two methods in the middle of a long method name.

    Let's just agree that there is a difference of about 30 between our IQs.

    I agree, but I think you flatter yourself to suggest you are only 30 points behind.

    If you had an IQ of 170, you would have come up with some clever remark.

    Your IQ is 140? That's nothing to brag about.

    this argument right here.....

    genius!

    shrug half of the population is above average and by average I obviously mean the median, although for a normal distribution that's the same as the mean and the mode, and IQ is a normal distribution.. In a room full of 200 people there's likely to be someone with an IQ over 140 and nearly as good a chance that there are two people if I'm one of them... don't you just love conditional probabilities?...

Leave a comment on “A Method Gone Too Far”

Log In or post as a guest

Replying to comment #:

« Return to Article