- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Yeah but that only works if the data is floats. Otherwise it'll have to be IUCWLSID :-)
Admin
"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.
Admin
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.
Admin
Admin
it was Facebook, wasn't it? sweet.delicious.irony.
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
Admin
+shapeEffectSingleBlurFrom:withInteriorFill:offset:blurSize: innerGlowRed:innerGlowGreen:innerGlowBlue:innerGlowOpacity: innerShadowRed:innerShadowGreen:innerShadowBlue:innerShadowOpacity: outerGlowRed:outerGlowGreen:outerGlowBlue:outerGlowOpacity: outerShadowRed:outerShadowGreen:outerShadowBlue:outerShadowOpacity: hasInsideShadowBlur:hasOutsideShadowBlur:
Admin
Something seems wrong with your theory.
Admin
Admin
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.
Admin
Let's hope the submitter, being Anonymous, does not forgive and does not forget this atrocious code.
Admin
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.
...
Admin
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.
Admin
Admin
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.
Admin
I agree, but I think you flatter yourself to suggest you are only 30 points behind.
Admin
I forgot that it's still 2012
Admin
you're being far too descriptive, just call it method1.
Admin
Admin
If you had an IQ of 170, you would have come up with some clever remark.
Admin
Admin
this argument right here.....
genius!
Admin
Admin
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.
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?
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?
Admin