Summary
Evaluate alternative syntax proposals (memoize_method, block form, annotation approach) based on real-world usage feedback, introduce the preferred form, and provide a migration path from the current memoize :method_name API.
Motivation
The current memoize :method_name call-after-def style works well but has drawbacks: the DSL call is visually separated from the method definition, static analysis tools have difficulty understanding it, and some users prefer a decorator-style annotation. A v2 major bump is the right time to revisit this.
Proposed approaches to evaluate
- Annotation form —
memoize called immediately before the def, acting as a decorator
- Block form —
memoize { def expensive = ... }
- Explicit alias — keep current style but rename to
memoize_method for clarity
Acceptance criteria
Milestone
v2.0.0 — Next Generation
Summary
Evaluate alternative syntax proposals (
memoize_method, block form, annotation approach) based on real-world usage feedback, introduce the preferred form, and provide a migration path from the currentmemoize :method_nameAPI.Motivation
The current
memoize :method_namecall-after-def style works well but has drawbacks: the DSL call is visually separated from the method definition, static analysis tools have difficulty understanding it, and some users prefer a decorator-style annotation. A v2 major bump is the right time to revisit this.Proposed approaches to evaluate
memoizecalled immediately before thedef, acting as a decoratormemoize { def expensive = ... }memoize_methodfor clarityAcceptance criteria
ttl:,max_size:,shared:, etc.)Milestone
v2.0.0 — Next Generation