Open staticfloat opened 1 year ago
Thanks @staticfloat ! Would be nice to have such functionality. I thing it should however not be a method of Base.hasproperty
. One reason is that it can be generalized to handle other lenses like IndexLens
and then the name makes less sense. The other reason is that overloads like Base.hasproperty(x, o::ComposedFunction)
are type piracy.
This function is now available as hasoptic(obj, optic)::Bool
in AccessorsExtra.
Also, see maybe(optic)
there: it's often more convenient than manually handling has/hasn't cases.
I think more real-world usage and testing of the interface is needed before inclusion in Accessors proper (or it shouldn't be included here at all).
I've been using maybe
-optics for some time already, and quite like them. They are based on hasoptic
check, through I didn't really find myself using this check explicitly.
Would be nice to include into Accessors proper at some point, but there are a few questions on the semantics of hasoptic
and of maybe
. Here's a list of concerns about the "get" part alone:
maybe(o)(x)
returns nothing
when !hasoptic(x, o)
. So, composability requires hasoptic(::Nothing, _) = false
to be able to combine multiple maybe
optics. Presumably it's fine to use nothing
in this role of sentinel, and I didn't experience any issues with that - but technically it is a limitation for when someone wants to actually operate on nothing
. I don't see other alternatives, but may be missing something.hasoptic
should do on specific optics like PropertyLens, IndexLens and similar. But what to do in the general case?
hasoptic(_, _)
fallback? Then any optic without a specific hasoptic
method wouldn't work with hasoptic
/maybe
, and the majority of optics won't have it.hasoptic(_, _) = true
? That's how it's done in AccessorsExtra for now. One can put arbitrary optics into maybe
, like maybe(@optic _.a + 1)
. However, there are cases when hasoptic(x, o) == true
but o(x)
fails - so maybe(o)(x)
does as well. The majority of optics, both in Accessors and user-defined, presumably work on all instances of corresponding types, so true
is a reasonable fallback imo.hasoptic
/maybe
treat multivalued optics like Elements()
and Properties()
? Currently, it just errors.
Sometimes I'd like to check beforehand whether an optic is truly applicable to a type; especially when dealing with deeply-nested optics. It would be quite useful if there existed a
hasproperty()
analogue for optics on a type. I've made a simple version forPropertyLens
andComposedFunction
, but I'm not sure about the rest of the optic types. I'm opening this issue so that if someone else is interested, they can carry this to completion.This allows tests such as the following: