You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
our default names conflict with function, e.g. we have a special arg for length, that does not map directly to the length function
anyDuplicated = 0L would work but anyDuplicated = 0 wouldn't
feeding unnamed args to the ... is awkward, skipping args is weird, ... = is weirder
the formula syntax for custom errors is weird.
All these flows make the package awkward to use. I think I tried too hard to make the syntax compact so we could define types inline, but with #35 we can provide guidelines to make it easy.
It would be great if we could define a type inheriting from another type, without using as_assertion, and still define arguments named as we want, and errors as we want. It doesn't matter if the DEFINITION of the type is verbose, but it should not be confusing, only the USAGE of the type should be pretty and compact.
The text was updated successfully, but these errors were encountered:
I prototyped this (not pushed), using a .extend arg.
It's not a lot of code to make this work but I wonder if I should do a full pass on the package to improve consistency, use rlang errors and try_fetch, and use .extend to define everything.
On the way we keep backward compat with the weird idioms we had but we convert them to the new stuff and we don't document them anymore.
I think a general issue this package has is that I wanted to inline code too much, so we could print functions and understand the logic and checks more easily. I think it worked out poorly and created these environment issues.
I think a better design would be to have all assertions factories with a same code, but a different proper enclosure, no inlining of values, and we can have a helper to fetch assertions. inheritance is just adding assertions to the list.
We have several issues :
fun = output
args can't be used withpkg::fun
length
, that does not map directly to thelength
functionanyDuplicated = 0L
would work butanyDuplicated = 0
wouldn't...
is awkward, skipping args is weird,... =
is weirderAll these flows make the package awkward to use. I think I tried too hard to make the syntax compact so we could define types inline, but with #35 we can provide guidelines to make it easy.
It would be great if we could define a type inheriting from another type, without using as_assertion, and still define arguments named as we want, and errors as we want. It doesn't matter if the DEFINITION of the type is verbose, but it should not be confusing, only the USAGE of the type should be pretty and compact.
The text was updated successfully, but these errors were encountered: