Skip to content
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

Open
DartBot opened this issue Dec 7, 2013 · 5 comments
Open

Enhancement: Add support for "lazy val" semantics #15505

DartBot opened this issue Dec 7, 2013 · 5 comments
Labels
area-language New language issues should be filed at https://github.com/dart-lang/language type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Dec 7, 2013

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

@kwalrath
Copy link
Contributor

Not sure where this should go, so passing the buck to Gilad.


Set owner to @gbracha.
Removed Area-Documentation label.
Added Area-Language label.

@gbracha
Copy link
Contributor

gbracha commented Aug 26, 2014

I think you're asking for a sugar for

class X {
   var _y;
   get y => null == _y ? _setY : _y;
   setY => _y = someComputation;
}

that would be

class X {
  lazy y => someComputation;
}


Removed Type-Defect label.
Added Type-Enhancement, Accepted labels.

@DartBot
Copy link
Author

DartBot commented Aug 26, 2014

This comment was originally written by @Andersmholmgren


Exactly what I'm after.

@DartBot
Copy link
Author

DartBot commented Aug 27, 2014

This comment was originally written by olivier.chafik@gmail.com


2-cents suggestion to avoid adding a lazy keyword:

class X {
  @­cached get y => someComputation;
}

Also, null could be a valid value (and computing null could be very expensive :-D), so maybe an extra bool is needed?
Would be nice if the naming was guaranteed

@DartBot DartBot added area-language New language issues should be filed at https://github.com/dart-lang/language Type-Enhancement labels Aug 27, 2014
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed accepted labels Feb 29, 2016
@rodion-m
Copy link

rodion-m commented Dec 15, 2020

This comment was originally written by olivier.chafik@gmail.com

2-cents suggestion to avoid adding a lazy keyword:

class X {
  @­cached get y => someComputation;
}

Also, null could be a valid value (and computing null could be very expensive :-D), so maybe an extra bool is needed?
Would be nice if the naming was guaranteed

Such a great idea! What is the status of this suggestion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language New language issues should be filed at https://github.com/dart-lang/language type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

5 participants