On 30 Sep 2010, at 16:21, Martin Pilkington wrote:
> Hi Ellie,
> 
> I think you're misunderstanding the power of Objective-C. It is essentially C + Smalltalk. It is heavily runtime based and various patterns rely upon proxy objects that forward or intercept messages, on querying objects for method implementations at runtime, on the ability to dynamically add methods at runtime or to exchange the implementations of two methods. You can't do something like module_eval with a string as it is a compiled and not interpreted language (theoretically it could be possible but isn't today) but you could add a new method by using a block as the implementation (not part of an official API but with a few methods it is possible).
> 
> I'm fully aware of the power of dynamic languages, as with Objective-C I use one every day. After all, it's no fluke that Ruby has been able to be re-implemented on top of the Objective-C runtime in the form of MacRuby. However, I'm also aware of the benefit of having type information without having to execute the full code.

Hi Martin,

Objective-C is a fundamentally different beast to Ruby: yes it's dynamically typed, but it's not runtime mutable in the way that Ruby, Lisp and Forth are. That's not to say you can't battle against the flow of either language - after all, once you have function and void pointers you can play tricks with assembler injection and type reinterpretation to do pretty much anything you fancy, and that's certainly an option with Objective-C thanks to its C heritage and Ruby thanks to the DL or FFI extensions.

The question is whether trying to fit code in either language to the design criteria of the other is such a great idea - let alone insisting that either conform to the particular prejudices of a given style of development tool.


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason