• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Future Objective-C changes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future Objective-C changes


  • Subject: Re: Future Objective-C changes
  • From: Chris Hanson <email@hidden>
  • Date: Fri, 16 May 2003 09:17:02 -0500

On Friday, May 16, 2003, at 08:22 AM, David Cittadini wrote:
Templates are an implementation of a concept. Generics, as a concept can be quite useful. Interestingly, Java 1.5 will introduce generics without some of the pain of C++ templates.

Generics can be useful in type-paranoid languages like C++. In dynamic languages like Objective-C, Smalltalk, and Lisp, there's no point to them. It's a shame they were added to Java for 1.5; they're not needed in that language. I see their addition as a failure of the community process, C++ developers clamoring loudly enough for something familiar over something more powerful that they finally got their way. This is something that I'd really, *really* like not to happen in Objective-C.

If I override alloc and allocWithZone the developer will only know it cannot be used when the program is run.

The developer will know when their unit tests fail. You do write pervasive unit tests, don't you?

http://c2.com/cgi/wiki?UnitTest
http://www.sente.ch/software/ocunit/

It's a much better way to build solid "public" code than relying on documentation, relying on extensive QA testing, or relying on a paranoid type system.

Option 2 looks more simple and elegant to me. It seems overly complex that the selector name has to have all this extra information in order to make sure that the right selector gets called just because the parameter type may be of a different type. I just want to "draw" and the runtime can determine what to call depending on the parameter type. Surely option 2 feels more dynamic, which Objective-C is supposed to be.

Selectors don't get called! Selectors get *sent*.

The receiver decides what to do with a message selector it receives. This is a very important concept in object-oriented programming, something utterly lost in object-like languages like C++. This means that draw: is draw: is draw: whether it's sent to an instance or a class. If you want to do something special based on the class of an argument to a selector, you can do that now - at runtime.

-- Chris

--
Chris Hanson, bDistributed.com, Inc. | Email: email@hidden
Custom Application Development | Phone: +1-847-372-3955
http://bdistributed.com/ | Fax: +1-847-589-3738
http://bdistributed.com/Articles/ | Personal Email: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Future Objective-C changes (From: David Cittadini <email@hidden>)

  • Prev by Date: Re: Future Objective-C changes
  • Next by Date: NSImage method problem
  • Previous by thread: Re: Future Objective-C changes
  • Next by thread: Re: Future Objective-C changes
  • Index(es):
    • Date
    • Thread