Earlier quoted context omitted.
http://stackoverflow.com/questions/5272451/overriding-method...
http://nshipster.com/method-swizzling/
Isn't that just monkey patching?
Objective-C isn't what you think it is
41–50 of 101 posts
Re: Objective-C isn't what you think it is
#42> Objective-C isn't what you think it is A language without namespaces, that's used almost exclusively for iOS apps and nothing else. Nope, that's exactly what I think it is.
And, um, Mac OS X applications. I know that may not seem like a big deal but many major applications people care about seem to have first appeared on Mac OS / Mac OS X (yes, these are two very different things). BTW: namespaces?! Not exactly my go to checklist feature for languages.
Fine, they're different things. My point is that seemingly no one uses Objective C except to make proprietary Apple things. Which is fine, but I always find it annoying when people sing the praises of Objective C but avoid using it for web servers, cli applications... or anywhere else Objective C doesn't have an institutional advantage.
I think what people really like about Objective C is not Objective C but Cocoa.
Re: Objective-C isn't what you think it is
#43Earlier quoted context omitted.
The namespaces are inherent in the class name. It's actually a very nice solution. Instead of this Foundation::Array we get NSArray. Way easier to type out, and looks a million times cleaner to me.
Until some other cool library you really want to use happens to also have a NSArray. With proper namespaces/modules, such conflicts can be usually sorted out by renaming on import. With C and Objective-C, good luck.
If a cool library you want also has a class named NSArray, then you just refactor it by renaming on import like you just mentioned.
It's literally the exact same thing as what you're saying. Say I have one library in my project already - we'll call it BGAddressBook. And then I find another library that I really want to add that also happens to be named the exact same - BGAddressBook. So, I would refactor one of them (probably the one already in there to be BG1AddressBook or whatever). This is no different than having a library named BGAddressBook in ruby and wanting to use another library with the same namespace. You're going to have to change one or the other's namespace to work with both.
Properties don't matter and can collide with no problem. I can have a BGAddressBook with a name property and a BGSomethingElse with a name property. Doesn't matter. It'd be the same as BGAddressBook::Name and BGSomethingElse::Name.
Re: Objective-C isn't what you think it is
#44> Objective-C isn't what you think it is A language without namespaces, that's used almost exclusively for iOS apps and nothing else. Nope, that's exactly what I think it is.
And, um, Mac OS X applications. I know that may not seem like a big deal but many major applications people care about seem to have first appeared on Mac OS / Mac OS X (yes, these are two very different things). BTW: namespaces?! Not exactly my go to checklist feature for languages.
> And, um, Mac OS X applications.
As little of it as possible. I dump everything I can into C++ both for portability and for sanity-of-code reasons.
Re: Objective-C isn't what you think it is
#45Earlier quoted context omitted.
The namespaces are inherent in the class name. It's actually a very nice solution. Instead of this Foundation::Array we get NSArray. Way easier to type out, and looks a million times cleaner to me.
Until some other cool library you really want to use happens to also have a NSArray. With proper namespaces/modules, such conflicts can be usually sorted out by renaming on import. With C and Objective-C, good luck.
Then there must be some other cool library you really want to use happens to also have the namespace "std" and a "vector" class inside...
Re: Objective-C isn't what you think it is
#46Earlier quoted context omitted.
http://nshipster.com/method-swizzling/
Isn't that just monkey patching?
http://en.wikipedia.org/wiki/Monkey_patch
By that link's definition, then yeah, it's basically monkey patching.
Re: Objective-C isn't what you think it is
#47Earlier quoted context omitted.
And, um, Mac OS X applications. I know that may not seem like a big deal but many major applications people care about seem to have first appeared on Mac OS / Mac OS X (yes, these are two very different things). BTW: namespaces?! Not exactly my go to checklist feature for languages.
Fine, they're different things. My point is that seemingly no one uses Objective C except to make proprietary Apple things. Which is fine, but I always find it annoying when people sing the praises of Objective C but avoid using it for web servers, cli applications... or anywhere else Objective C doesn't have an institutional advantage. I think what people really like about Objective C is not Objective C but Cocoa.
It is called vendor lock-in.
And yeah, it is not only Microsoft with their tecnologies that try/tried to do it.
Re: Objective-C isn't what you think it is
#48 Dynamic method resolution isn’t the only superpower of *sick* mutable languages like Ruby and Objective-C
Re: Objective-C isn't what you think it is
#49Personally I think it's an awful idea to use meta-programming without an exceptionally good reason in production code. Like excessive use of function pointers in C. Just because you can doesn't mean you should. Programming in this style causes more code complexity and will accelerate the rate at a which a codebase becomes a mess, not to mention it's really slow.
This has always been my view. New developers (less than 10 years professional experience) seem to become fascinated by "cool" language features that let them do unintuitive things and then approach problem solving with a mindset of "What cool tricks can I do to solve this?" Instead, the experienced developer will always approach a problem with "What is the simplest way to solve this problem?"
Well. Objective-C isn't that simple to begin with, but when you are used to it, it really provides elegant and very simple solutions to medium complex stuff like key-value observing and coding. Meditated together they are called bindings, where your ui is key value coded, and your model is key value observed. Yes, Objective-C (and Cocoa) are very strong on design patterns, which gives you a whole lot of leverage. It works and is debugable too! :) I love it, and find it to be the most hot-dirty-sexy language I have ever used.
Re: Objective-C isn't what you think it is
#50These features are extremely difficult to use when C types are involved. @encode() mitigates this to some extent, but there are some C types that you can't fully express using @encode(), and it can't properly handle all types (namely out-pointers).