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
Enhancement: Add support for "lazy val" semantics #15505
Comments
Not sure where this should go, so passing the buck to Gilad. Set owner to @gbracha. |
I think you're asking for a sugar for class X { that would be class X { Removed Type-Defect label. |
This comment was originally written by @Andersmholmgren Exactly what I'm after. |
This comment was originally written by olivier.chafik@gmail.com 2-cents suggestion to avoid adding a class X { Also, null could be a valid value (and computing null could be very expensive :-D), so maybe an extra bool is needed? |
Such a great idea! What is the status of this suggestion? |
This issue was originally filed by @Andersmholmgren
When writing immutable classes you often have to trade off between what you calculate in getters vs what you precalculate in ctrs.
If something is somewhat expensive to create, then if you know it is likely to be retrieved more than once in typical usage then you are better off pre calculating (although this leads to uglier code). Otherwise you are better off calculating it on the fly in a getter.
Problem is that you can't always predict how your classes will be used in the future (particularly for reusable libraries) so this choice is difficult to make well.
Languages like Scala have "lazy val" that creates object when first accessed. I'd like to see this kind of thing in Dart.
Note it may not need that kind of syntax, but may instead be a VM optimisation, if the VM can detect that the same value will always be returned and the getter is being called enough to warrant caching the value. I imagine https://code.google.com/p/dart/issues/detail?id=501 would make detecting this easier.
If it is a VM optimisation though it may be good to have an annotation so that the developer can express their expectations about whether the return value should be idempotent as this would allow tooling to warn if it detects it isn't
The text was updated successfully, but these errors were encountered: