On 30 Sep 2010, at 16:21, Martin Pilkington wrote:
> Hi Ellie,
>=20
> 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).
>=20
> 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