Metaprogramming in RubyMotion

clayallsopp.com

32 points10char3 comments

This sort of hack is easy enough with ObjC and blocks, but is generally avoided due to introducing significant issues with clarity.

But, if trying to eliminate cruft, why include define_singleton_method? Why not just set the proper scope and define_method? Same with instance_eval, class_eval (and module_eval maybe?)- why not just set the scope to define whether you are in instance, class, eigenclass, etc. and use instance_eval? Not a criticism, but a serious question if the goal is to pare it down.

By cruft I more literally meant the fact that MRI being interpreted means a hit on performance, not necessarily syntactical cruft. Perhaps I should have chosen my words differently :)

RubyMotion is aiming to be a more complete implementation of Ruby, and one of the core ideas of Ruby is "there's more than one way to do it." Whether you agree or disagree is outside the bounds of RubyMotion and maybe even Ruby IMO; ultimately, whether or not more techniques than scoping define_method are allowed is something that can and should be done a per-project basis.

Food for thought, I found this article detailing all the ways to add singleton methods, in varying levels of grokability: http://wowkhmer.com/2011/01/15/different-ways-to-define-sing...

Reply on news.ycombinator.com