On Mon, May 19, 2008 at 6:10 PM, Peter Duniho <[EMAIL PROTECTED]> wrote:
> It should be clear from the volume of push-back that
> not all is well in Cocoa-Land, even if the complaints are sometimes vague.
This is absurd. Every programming system I have ever encountered that
rises above the level of masochistic hobbyists experiences complaints
like this, and in similar volume. There are *always* people who have
trouble with the learning curve. Now, I certainly think things could
be improved on this front, but the existence or even the volume of
these complains is not evidence of anything other than that this
platform actually attracts programmers who aren't using it just
because it's hard.
> I don't understand these comments. C++ works fine for a great many OOP
> tasks, and it certainly addresses the basic lack of inherent support for OOP
> that C has (so surely it "fixes" that "problem").
I think, and I have spoken to a lot of people over the years who agree
with me, that C++'s "fix" is vastly worse than the disease. C++ is not
OOP in any real sense of the word (see Alan Kay's famous remark on
this if you don't know what I mean) and any similarity to real OO
languages such as Objective-C is only superficial.
> In Obj-C, if the object doesn't respond to the selector, doesn't it just
> fail silently?
No, you are thinking of messaging nil. If you send a message to an
object that it doesn't respond to, it throws an exception.
> Oh, and as an added benefit: because interfaces are treated like types and
> you're not dealing with method signatures directly, there's none of this
> "oops, you forgot to include the trailing colon in the selector name"
> business (you can probably guess, I've run into that at least once :) ).
> The compiler prevents that from happening.
If this bothers you that much in ObjC then merely add
-Wundeclared-selector to your compiler warning flags.
> Which is all a long way of saying, the message-sending paradigm in Obj-C
> isn't required for the example you give. This is my point. With a
> strongly-typed language that includes run-time type information (something
> that's even available in some C++ implementations for that matter), you
> don't need to have a whole message-dispatching system for your
> function-calling.
This makes no sense. If you support this kind of dispatch then you
*have* a whole message-dispatching system, no matter what you call it.
Java and C# ultimately support the same messaging semantics as ObjC,
albeit vastly more verbosely in the more complicated cases, and has
similar machinery underneath it making it all happen.
> So this message-dispatching thing in Obj-C must have some other benefit.
> Granted, it's never really been explained to my satisfaction to me, so I
> can't necessarily represent the argument correctly. But the gist as I
> understand it is that because the language is so flexible, you can swap in
> whole new classes at run-time to override existing library behaviors.
>
> That's just not something I've ever felt a need to do, and frankly it sounds
> like a code-maintenance nightmare. But at the very least, if this _is_ the
> argument in favor of Obj-C, I'd love for someone to give me a real-world,
> mainstream example where the same end result can't be accomplished in a
> reasonable manner using a more conventional language.
Write the following method in Java or C#:
- (void)setColor: (NSColor *)color {
[[[self undoManager] prepareWithInvocationTarget: self] setColor: mColor];
[mColor release];
mColor = [color retain];
}
If you can't guess, [self undoManager] returns an instance of NSUndoManager.
For added fun, think about how you would implement NSUndoManager
itself. I'm sure it's possible in these languages, but the language is
going to get in your way a lot, both in the writing and the using.
Or even implement something as simple as the Cocoa responder chain,
trivial in ObjC, in one of these more "mainstream" languages.
> Likewise, interfaces aren't something you use _everywhere_ in Java and C#.
> You use them only when you need them. The difference is that in Java and
> C#, the compiler "always" (*) knows whether what you're doing is reasonable
> or not.
Even with your caveat, this is insane. No compiler can stop you from
writing unreasonable code. It may be able to stop you from writing
code that treats an object as something it's not, but that is only one
tiny corner in an enormous universe of unreasonableness. This is, of
course, the fundamental point of contention between statically and
dynamically typed languages. Us dynamic advocates know that the
compiler can detect these things, we just don't care. You treat these
bugs like any other bugs, and you catch them in testing. Sure, it's
convenient to catch them when you compile instead, but is it worth the
enormous loss of flexibility? The people on this side say no. If you
disagree, that's fine, but realize that it's a fundamental matter of
opinion, not simply that your compilers are able to catch all your
errors and ours are not.
> It's just that today, in the 21st century, when there are languages like
> Java and C# (and I gather Delphi, and maybe some others that I haven't used)
> that rather than expecting you to learn and know these conventions, simply
> impose them on your code for you so that you can get on with worrying about
> the parts of code that the compiler _can't_ deal with, I feel like I'm
> stepping backwards in time when I'm writing Obj-C code.
Funny, that's how I feel every time I see Java code. The universe of
OO languages has tilted strongly toward dynamic duck-typing of late.
This is something that Smalltalk started and ObjC lead by a long way,
but most OO languages you run into these days are this way. Java and
C# are an odd anachronism from that point of view.
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
