5 ms·

Calling "reflection" an ugly pattern is like calling onions a bad recipe. It's up to you how you intend to use it, but please, let's not be ridiculous and call

Calling "reflection" an ugly pattern is like calling onions a bad recipe. It's up to you how you intend to use it, but please, let's not be ridiculous and call it an "ugly pattern of other ecosystems." Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) and "ease of optimization" and "performance" is just BS. Ya, sure, sometimes reflection slows things down but web devs who use ruby for 90% of projects don't care about that. I'd love to hear you try and explain how reflection tarnishes "ease of optimization" and why it's so "ugly"

netheril96 11y ago
> Web devs who use ruby ... Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.
- joslin01 11y ago
  Good way to take a few words completely out of context. I said "web devs who use ruby for 90% of projects" as in "they obviously don't care much about performance in the first place" If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?
  - netheril96 11y ago
    I was wondering if you had more experience with Ruby than with a statically typed language like Java, and thus did not see the problem with reflection. Now, to answer your previous question, about how reflection is bad: * Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime. * That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower. * It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly. A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.
- fleitz 11y ago
  It may not be statically typed, but it is strongly typed which is usually more useful than static typing. For instance the type system in C is static but weak, creating entire classes of issues that are hard to debug that don't exist in ruby.
  - netheril96 11y ago
    > but it is strongly typed which is usually more useful than static typing. Strong typing is orthogonal to static typing and I do not believe one is more useful to another. The benefit of static typing is that you can catch many mistakes at compile time. Static typing also makes analysis and navigation of the code base easier.
bjz_ 11y ago
> Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) Perhaps my terminology was incorrect there. It's more that it gets in the way of static verification, and makes it much harder to refactor code with confidence. For example, I am working on a Java project at the moment, for which many constructors and methods are apparently (to the IDE's static analysis) unused. I could quite merrily delete them or change their signatures, only to have the program it break unexpectedly at runtime due to reflection expecting them to exist at the opposite end of the codebase. That is the power of static types - and reflection breaks those guarantees.

netheril96 11y ago

> Web devs who use ruby ... Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.

joslin01 11y ago
Good way to take a few words completely out of context. I said "web devs who use ruby for 90% of projects" as in "they obviously don't care much about performance in the first place" If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?
- netheril96 11y ago
  I was wondering if you had more experience with Ruby than with a statically typed language like Java, and thus did not see the problem with reflection. Now, to answer your previous question, about how reflection is bad: * Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime. * That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower. * It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly. A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.
fleitz 11y ago
It may not be statically typed, but it is strongly typed which is usually more useful than static typing. For instance the type system in C is static but weak, creating entire classes of issues that are hard to debug that don't exist in ruby.
- netheril96 11y ago
  > but it is strongly typed which is usually more useful than static typing. Strong typing is orthogonal to static typing and I do not believe one is more useful to another. The benefit of static typing is that you can catch many mistakes at compile time. Static typing also makes analysis and navigation of the code base easier.

bjz_ 11y ago

> Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) Perhaps my terminology was incorrect there. It's more that it gets in the way of static verification, and makes it much harder to refactor code with confidence. For example, I am working on a Java project at the moment, for which many constructors and methods are apparently (to the IDE's static analysis) unused. I could quite merrily delete them or change their signatures, only to have the program it break unexpectedly at runtime due to reflection expecting them to exist at the opposite end of the codebase. That is the power of static types - and reflection breaks those guarantees.