goog.isDateLike is triggered by others' sketchy practices

Open
#27 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
clojure, javascript
Domain
tooling

Research direction

Start by reviewing goog.isDateLike in closure/goog/base.js, especially its goog.isObject and getFullYear checks, and compare that behavior with cljs-oops' runtime checks. The work is complete when callers can disable the date-like check independently while leaving the other checks enabled; the payload does not name project files or tests to run.

Written by the indexing model from the issue text.

Description

I've had to stop using cljs-oops for a subset of my uses, specifically https://capacitorjs.com plugins[1], because their top-level plugin modules return a Proxy that behaves somewhat like this (not exactly, but this achieves a similar effect):

const p = new Proxy({}, {get: () => () => true})

That is to say, typeof p.anythingAtAll is 'function'.

Unfortunately, goog.isDateLike only looks for goog.isObject and typeof val.getFullYear == 'function'.

I fully appreciate that this style of duck-typed checking is common in JS, including for promises (as thenables) and similar -- and also that this is more of an upstream quirk than anything else.

That said, given that upstream libraries can't always be changed, I wanted to propose configuration to pick which of the safety checks are run, one at a time (maybe a set like #{:date-like :string-like ...}?)

I find that I rarely trigger the date-like check in ordinary use and disabling it for my own codebase would be helpful for this situation -- on the other hand, I find the other runtime checks valuable and do run into them, so I would love to leave them enabled.

I almost wrote the PR alongside the issue, but I wanted to get your thoughts before doing so, in case you have a preference for how such a thing would work.

Thanks so much for the library -- I like it enough to have wrapped it at https://github.com/tekacs/access in a different syntax, which is primarily how I use it. :)

[1]: such as @capacitor/filesystem, which returns the output of registerPlugin in @capacitor/core

Dominant language
Clojure
Stars
350
Forks
13
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from binaryage/cljs-oops

All issues in binaryage/cljs-oops

Similar issues

More Clojure issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.