Re: Function calling
Re: Function calling
- Subject: Re: Function calling
- From: Erik Buck <email@hidden>
- Date: Thu, 26 May 2005 07:11:34 -0700 (PDT)
>> (a) either you forbid the possibility to change the set
>> of implemented messages at runtime (which would be quite bad and
>> limiting), or
>This is not the point Bob is making, the point in that it is not
>restrictive to impose the constraint.
>If you can give me an example (preferably likely to be used) where
>this is restrictive, please show me it.
Consider support for plug-ins. Consider frameworks. Consider support for sending any message along a responder chain. Consider support for a tool like interface builder that lets you add/specify messages in the tool that will not be sent until the nib file is loaded in an already running program. Consider the dynamic loading of frameworks. Consider the existence of collection classes that can store objects that did not exist when the collection class was compiled perhaps because the objects to be stored in collections were loaded via plugins or frameworks. Consider forwarding of messages which forms the basis of distributed messaging, automatic undo/redo, database "faulting", Higher Order Messaging (HOM), etc. Consider not needing to recompile your application just to use it with the latest frameworks release. For example, Apple updates frameworks to add features that all Coc!
oa
applications get even without being recompiled.
Finally, consider the utility of categories: My favorite use for categories is this. If a method in the framework you are using allocates and returns a Fubar instance and you don't have source code for the framework, there is no way to get the framework method to return Mysubclassoffubar instead. However, with a category, I probably do not need to subclass Fubar at all because I can add the methods I need to the Fubar class directly. Now it doesn't matter that I can't change the framework's implementation.
To paraphrase Dr. Brad Cox, the inventor of Objective-C, object reuse is all about packaging technology. The key to programmer productivity is re-use and the key to re-use is packaging that reduces or eliminates coupling between components. Strong compile time type systems seem to exacerbate coupling between components thus diminishing opportunities for reuse.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden