22 Matching Annotations
  1. Last 7 days
  2. 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
  3. Dec 2020
    1. You can afford to make a proper PR to upstream.
    2. The change would be useful to other people as-is.
    3. The change is too consequential to be developed in situ.
    4. Patches can be reviewed as part of your normal review process, forks probably can't
    5. Get told in big red letters when the dependency changed and you need to check that your fix is still valid.
    6. Keep your patches colocated with the code that depends on them.
    7. Sometimes forks need extra build steps, e.g. with react-native for Android. Forget that noise.
  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. Sep 2020
  6. Jul 2020
  7. 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.)

  8. Oct 2019
  9. Jan 2019
    1. allowing common connections to be made wirelessly

      This sounds a bit like “send” and “receive” in some (visual) programming languages and modular synths. But the fact that it’s based on common connections sounds quite clever.