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
{{ message }}
This repository has been archived by the owner on Jun 5, 2023. It is now read-only.
When I first learned of the new export feature, I imagined a more disciplined version of Groovy's @delegate feature. The use case that jumped to mind is having a class which is functionally similar to a particular data structure, but with some domain specific enhancements. So you want to extend a collection interface and delegate it to a field but not be bound to the specific implementation, nor do you want to reimplement anything.
so in this case Collection[Book] has some subset of the List API?
Yes. I'm more familiar with Java where List and Set both implement Collection. I assumed that was so in Scala also. Maybe a slightly better example is you start using a Set and then later realize you need to allow duplicates, so you migrate to a List. But since you declared Collection, your API consumers haven't assumed set or list behavior for handling duplicates.
And does this impose an error if not all definitions can be satisfied?
When I first learned of the new export feature, I imagined a more disciplined version of Groovy's
@delegate
feature. The use case that jumped to mind is having a class which is functionally similar to a particular data structure, but with some domain specific enhancements. So you want to extend a collection interface and delegate it to a field but not be bound to the specific implementation, nor do you want to reimplement anything.I'd think this could be implemented as sugar on what currently exists. Picking a syntax might be harder at this point.
The text was updated successfully, but these errors were encountered: