14 Matching Annotations
  1. Apr 2021
    1. Yes, you are right. That was a very bad workaround. Stubbing methods on NilClass can be compared to switching to dark side of force. Powerful but comes with a huge price. I highly don't recommend using my workaround from 1 year ago.
  2. Mar 2021
  3. Feb 2021
    1. According to this comment you might want to override the structurally_incompatible_values_for_or to overcome the issue: def structurally_incompatible_values_for_or(other) Relation::SINGLE_VALUE_METHODS.reject { |m| send("#{m}_value") == other.send("#{m}_value") } + (Relation::MULTI_VALUE_METHODS - [:eager_load, :references, :extending]).reject { |m| send("#{m}_values") == other.send("#{m}_values") } + (Relation::CLAUSE_METHODS - [:having, :where]).reject { |m| send("#{m}_clause") == other.send("#{m}_clause") } end
  4. Oct 2020
    1. There are other features you *could* actually polyfill, such as Array.of, Number.isNaN or Object.assign, because those don’t introduce syntax changes to the language – except that you shouldn’t.
    1. Polyfills are naughty as they patch native APIs, while ponyfills are pure and don't affect the environment.
    2. How are ponyfills better than polyfills? A polyfill is code that adds missing functionality by monkey patching an API. Unfortunately, it usually globally patches built-ins, which affects all code running in the environment. This is especially problematic when a polyfill is not fully spec compliant (which in some cases is impossible), as it could cause very hard to debug bugs and inconsistencies. Or when the spec for a new feature changes and your code depends on behavior that a module somewhere else in the dependency tree polyfills differently. In general, you should not modify API's you don't own.
  5. Jul 2020
  6. Mar 2020
    1. Instead of re-opening Ruby classes like that (I get involuntary twitches), for our little exercise we are going to invent another name

      IMHO, re-opening classes is okay. Certainly better than duplicating an entire core Ruby class and giving it a silly, less-meaningful name. (Though I'm not sure he actually intended people to use Lax instead of Lazy. I think he was just showing how easy it is to implement Lazy from scratch in Ruby.)

  7. Oct 2019