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.isDateLikeonly 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
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):
That is to say,
typeof p.anythingAtAllis 'function'.Unfortunately,
goog.isDateLikeonly looks forgoog.isObjectandtypeof 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-likecheck 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 ofregisterPluginin@capacitor/core