-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Focus operator naming #26
Comments
Based on a suggestion from @julien-truffaut, I suggest the following semantics in Focus:
To do this, it would be useful for the DSL keywords:
|
If we really like |
IMO, we should aim for one name so that users don't have to argue, shall we use But we definitely need to consider name collision. Maybe we should define test cases, e.g. case class Foo(bar: String, index: String, elems: List[String]) {
def index(key: Int): String = elems(key)
}
object Foo {
implicit val indexEv: Index[Foo, Int, String] = ...
}
// Generate a lens to the field bar
Focus[Foo](_.bar)
// generate a lens to the field index OR
// fail because there is ambiguity? e.g. use Focus[Foo](_.field(_.index))
Focus[Foo](_.index)
// Fail no field fizz in Foo
Focus[Foo](_.fizz)
// generate an Optional using Foo.indexEv OR
// Fail index is a method of Foo, if it fails how do we force the use of Index instance? __index__(3)?
Focus[Foo](_.index(3)) |
Given that we already have (or plan to have) named methods like
some
andeach
that compose those respective optics onto an optic, shouldn't we keep that naming inside the Focus macro rather than having novel synonyms like?
or*
?Point:
Consistency is important. The same concept should not have any more than one name.
Counterpoint:
It will be hard to distinguish operators from regular fields, looking at the expression, leading to confusion in users. We are effectively asking them to memorise all the operators in order to use or understand Focus.
Counter-counterpoint:
"at" and "index" are already common words, and the same as our methods on the optics classes. Why have some the same and not others? We can make the Focus API discoverable by liberally printing usage instructions in compile error messages.
Counter-counter-counterpoint:
What do we do with naming collisions? At least special operators are less likely to collide with case class field names.
Counter-counter-counter-counterpoint:
Yes, but it's not impossible. We need a name collision policy anyway. Would compiler warnings be too annoying? Perhaps we could offer alternative names like
__some__
or__index__
so that users don't get stuck. Or perhaps we could offer another operatorfield(_.some)
to make a field access irrefutable.The text was updated successfully, but these errors were encountered: