4 ms·

Redefining or extending methods or classes at runtime isn't reflection; that's monkeypatching and/or rebinding new definitions to existing names. I would agree

Redefining or extending methods or classes at runtime isn't reflection; that's monkeypatching and/or rebinding new definitions to existing names. I would agree that Java, C#, and PHP lack the ability to do this without a lot of overcomplications, but at the same time, I've never really found myself in a situation where rebinding or extending classes at runtime was really the best solution. I would actually be quite interested in seeing a usage of that sort of magic that actually makes the solution easier and simpler than other options.

bad_user 15y ago
@nuclear_eclipse, look up this thread and you'll see that the discussion started from a mention of meta-programming. Also, IMHO, reflection (per se) is basically useless in a dynamically-typed language, unless you also have the ability to redefine stuff. I've never really found myself in a situation where rebinding or extending classes at runtime was really the best solution. That's only because you aren't used to it, and you're dismissing it based only on a limited experience with what is possible; although the libraries you're using may be doing it without you even noticing it. If you're a Java developer, what do you think frameworks like Spring, Hibernate, Guice are doing? And why in the world would you be using dynamic-typing if everything was set in stone from compile-time? Structural-typing (like in Scala) works a lot better ; although I can see why there's a misconception about what dynamic-typing really enables. That's the thing with half-baked features -- of course they are hard to use and error prone when the language itself isn't really built around it. But in a language like Ruby, where the "class" block's main purpose is to open a scope where "self" (the implicit) parameter points to that class, and inside the definition you can put anything, like real code that does stuff, and where creating new classes (in case they don't exist) is just a side-effect -- modifying classes and objects at runtime is everything you're doing (whether you like it or not). But it does give you the tools to deal with it. Same thing happens with Python, but more with functions and class methods, rather than classes, because that's what Python was optimized for -- decorating functions with extra behavior, since functions are first-class citizens. In Python it doesn't work so well for classes, since inside the definition itself you don't have access to "self", but you can also patch classes with great effect, just not with so much syntactic-sugar as in Ruby -- that's why people shy away from it and choose to deal with functions/methods instead, although there is some cool meta-programming stuff done with classes in Django. That's what decorators do btw (which look similar to Java annotations, but have a lot more bang for the buck :)) -- http://www.python.org/dev/peps/pep-0318/ http://www.python.org/dev/peps/pep-0318/ I would actually be quite interested in seeing a usage of that sort of magic http://rubyonrails.org/ http://rubyonrails.org/ -- and really, don't be fooled by all the clones available. I worked with Symfony and CakePHP -- every Rails-clone sucks compared to Rails. You have to try it for real in order to see what it does differently. If you're a fan of Java: http://aspectwerkz.codehaus.org/ http://aspectwerkz.codehaus.org/ See that link above? -- that's so easy to do in Python/Ruby that it doesn't deserve a library ;-) This is a good read on Ruby's meta-programming facilities, while not being so hard to read btw: http://pragprog.com/titles/ppmetr/metaprogramming-ruby http://pragprog.com/titles/ppmetr/metaprogramming-ruby Also, terms like "monkey-patching" and "magic" are derogatory terms for good engineering practices people have been using since the 70-ties when generating assembly at runtime was the only reasonable way to make complicated algorithms to work, while maintaining some sanity, like those in the field of artificial-intelligence. In the meantime people got so obsessed with preventing employees from shooting themselves in the foot, that aberrations like C++ and Java happened. Unfortunately for everybody, bad developers write bad code regardless of the programming language.
- nuclear_eclipse 15y ago
  Thanks for the links. I'll check that out.

bad_user 15y ago

@nuclear_eclipse, look up this thread and you'll see that the discussion started from a mention of meta-programming. Also, IMHO, reflection (per se) is basically useless in a dynamically-typed language, unless you also have the ability to redefine stuff. I've never really found myself in a situation where rebinding or extending classes at runtime was really the best solution. That's only because you aren't used to it, and you're dismissing it based only on a limited experience with what is possible; although the libraries you're using may be doing it without you even noticing it. If you're a Java developer, what do you think frameworks like Spring, Hibernate, Guice are doing? And why in the world would you be using dynamic-typing if everything was set in stone from compile-time? Structural-typing (like in Scala) works a lot better ; although I can see why there's a misconception about what dynamic-typing really enables. That's the thing with half-baked features -- of course they are hard to use and error prone when the language itself isn't really built around it. But in a language like Ruby, where the "class" block's main purpose is to open a scope where "self" (the implicit) parameter points to that class, and inside the definition you can put anything, like real code that does stuff, and where creating new classes (in case they don't exist) is just a side-effect -- modifying classes and objects at runtime is everything you're doing (whether you like it or not). But it does give you the tools to deal with it. Same thing happens with Python, but more with functions and class methods, rather than classes, because that's what Python was optimized for -- decorating functions with extra behavior, since functions are first-class citizens. In Python it doesn't work so well for classes, since inside the definition itself you don't have access to "self", but you can also patch classes with great effect, just not with so much syntactic-sugar as in Ruby -- that's why people shy away from it and choose to deal with functions/methods instead, although there is some cool meta-programming stuff done with classes in Django. That's what decorators do btw (which look similar to Java annotations, but have a lot more bang for the buck :)) -- http://www.python.org/dev/peps/pep-0318/ http://www.python.org/dev/peps/pep-0318/ I would actually be quite interested in seeing a usage of that sort of magic http://rubyonrails.org/ http://rubyonrails.org/ -- and really, don't be fooled by all the clones available. I worked with Symfony and CakePHP -- every Rails-clone sucks compared to Rails. You have to try it for real in order to see what it does differently. If you're a fan of Java: http://aspectwerkz.codehaus.org/ http://aspectwerkz.codehaus.org/ See that link above? -- that's so easy to do in Python/Ruby that it doesn't deserve a library ;-) This is a good read on Ruby's meta-programming facilities, while not being so hard to read btw: http://pragprog.com/titles/ppmetr/metaprogramming-ruby http://pragprog.com/titles/ppmetr/metaprogramming-ruby Also, terms like "monkey-patching" and "magic" are derogatory terms for good engineering practices people have been using since the 70-ties when generating assembly at runtime was the only reasonable way to make complicated algorithms to work, while maintaining some sanity, like those in the field of artificial-intelligence. In the meantime people got so obsessed with preventing employees from shooting themselves in the foot, that aberrations like C++ and Java happened. Unfortunately for everybody, bad developers write bad code regardless of the programming language.

nuclear_eclipse 15y ago
Thanks for the links. I'll check that out.