Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Objective-C isn't what you think it is

news.rapgenius.com

Post reply on HN
Print view View original

91–100 of 101 posts

Re: Objective-C isn't what you think it is

#91

Post by bennyg »

mikeash wrote: post #77
bennyg wrote: post #19

Earlier 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.

Except that with a proper namespacing solution, you just declare that you want Foundation's Array in one spot, and in the rest of the file you just write Array. With NSArray, it's NSThis and NSThat and NSBlah and NSFoo and NSBar and NSNSNSNSNSNSNS everywhere.

That's an interesting point. I've never done that (only an amateur at ruby) with a class before besides #defines, which just feels like bad juju.

Another good thing about the Obj-C de facto way is that you can immediately tell what a class is vs seeing String string

Re: Objective-C isn't what you think it is

#92

Post by klibertp »

bennyg wrote: post #67
pjmlp wrote: post #64

Earlier quoted context omitted.

How do you refactor third party libraries delivered as binary?

How would you refactor a third party library delivered as a binary in a language with namespaces?

By importing names from that namespace and aliasing them. Or by creating another namespace and importing them there.

You can't seriously argue that "NSArray" as a single string is the same thing as (hypothetical) "NS.Array", where both "NS" and "Array" and the thing at "NS.Array" are semantically different things. Don't get me wrong, I love Smalltalk and Erlang - both languages suffering from the same problem - but I can recognize a shortcoming when it bites my arm off.

Re: Objective-C isn't what you think it is

#93

Post by bennyg »

klibertp wrote: post #92
bennyg wrote: post #67

Earlier quoted context omitted.

How would you refactor a third party library delivered as a binary in a language with namespaces?

By importing names from that namespace and aliasing them. Or by creating another namespace and importing them there. You can't seriously argue that "NSArray" as a single string is the same thing as (hypothetical) "NS.Array", where both "NS" and "Array" and the thing at "NS.Array" are semantically different things. Don't get me wrong, I love Smalltalk and Erlang - both languages suffering from the same problem - but I…

I was genuinely asking in my question above. I'm all for it as long as it makes sense. I've never messed with aliasing or anything like that - I'm decently fluent in Objective-C but have only really dabbled in ruby/js.

After looking around halfway through writing this, this looks pretty nice:

http://stackoverflow.com/questions/11091740/is-it-possible-t...

I see what you're saying. Maybe it's Stockholm Syndrome, but I do like knowing associated files in 3rd party libraries easily too. I don't know, I'll experiment with this more in ruby and see how it feels.

Re: Objective-C isn't what you think it is

#94

Post by eropple »

Touche wrote: post #53
yulaow wrote: post #47

Earlier quoted context omitted.

It is called vendor lock-in. And yeah, it is not only Microsoft with their tecnologies that try/tried to do it.

It has nothing to do with lock-in. There's nothing stopping people from using Objective C to serve web apps, it's just that no one does it because Objective C is not a pleasant language to work in. People do choose to use Microsoft languages for things other than Windows apps.

Objective-C really is pleasant to use for GUIs. As I noted elsewhere in this thread, I offload everything I can into C++, but between Objective-C and IB, I really enjoy building GUIs in OS X.

Anything else, not so much, but, yeah.

Re: Objective-C isn't what you think it is

#95

Post by tambourine_man »

dhugiaskmak wrote: post #56
tambourine_man wrote: post #48

Dynamic method resolution isn’t the only superpower of *sick* mutable languages like Ruby and Objective-C I think he means slick , or the author has a funny sense of humor.

No, he means sick. http://www.urbandictionary.com/define.php?term=sick (First definition.)

Thanks, never heard it that way.

Re: Objective-C isn't what you think it is

#96

Post by pjmlp »

swift wrote: post #68
pjmlp wrote: post #63

Earlier quoted context omitted.

#include namespace betterns = std;

The whole problem is that namespaces are open, and you can add to them from anywhere. This means a namespace alias is useless in this situation. There's no distinction between things put in namespace std by library A and things put there by library B - they are all equally valid members of namespace std. All that has been accomplished by the namespace alias is that before, both libraries were accessible through "std"…

I just gave a C++ example, because you asked for one.

There are lots of module systems to choose from, and Objective-C offers none.

Re: Objective-C isn't what you think it is

#98

Post by boon »

pikachu_is_cool wrote: post #25
MrGando wrote: post #10

AFAIK Objective-C does indeed have dynamic features. It's also static & weak. So I already have a problem with the first line of the article: > Ruby and Objective-C look like opposites: one is dynamic, the other's static; EDIT: Just read that the author basically denies those claims in the next paragraph.

Nice.

Like this comment, right? :)

Re: Objective-C isn't what you think it is

#100

Post by prutschman »

swift wrote: post #65
prutschman wrote: post #14

Earlier quoted context omitted.

You can even do it in POSIX C with dlsym.

Heh, true, though it requires that the function you want to call be in a dynamic library.

I thought so too, but the man pages suggest that may not be a requirement.

Under Mac OS X, it looks like dlsym(RTLD_DEFAULT, "symbol") will look for the symbol anywhere.

Under Linux it looks like dlopen(NULL, flags) will open a handle to the main program which can be passed to dyslm's first argument.

Post reply on HN