immutables icon indicating copy to clipboard operation
immutables copied to clipboard

Derived attributes not implicitly Auxiliary

Open xtaixe opened this issue 4 years ago • 2 comments

Hi.

Unless I'm missing something, Derived attributes are not implicitly Auxiliary.

  1. Is that intended? Is there any case where making them Auxiliary wouldn't make sense or would be wrong?
  2. Shouldn't the only difference between Derived and Lazy be eagerness/laziness?
  3. If it's not possible to change behavior, could this be explicitly documented?

Thanks!

xtaixe avatar Jun 03 '21 09:06 xtaixe

It is by design that @Default and @Derived attributes are part of the value and are fully defined and finalized during construction. Oftentimes derived attributes used to output additional computed fields (including toString and JSON), and also derived attributes sometimes used for auto-generated fields, which constitute value (so in this case it would not be derived only from other fields, but also from some environment (like ID generator) during construction, but then would remain immutable/unchanged and will be part of the value). I believe you can put Auxiliary annotation on derived attribute to exclude it or turn it into @Lazy. There is no need to make @Derived auxiliary because you can easily turn them into auxiliary and that (auto aux for deriveds) would break other people's code which rely on current behavior. We might have some terrible mistakes in the design/semantics of some features, but IMHO that is not one of those.

With lazy attributes there's no way to make them non-auxiliary, it would compromise equals/hashCode/toString integrity depending if fields was or was not computed.

It is mentioned in documentation about lazy fields ("Things to be aware of"). You probably know how hard it can be to provide exhaustive cross-references of all features and their combinations in the documentation, especially as those was added and documented over time. While we definitely can and should improve documentation, we cannot cover 100%, so documentation PRs welcome too. I might add some notes when will be revising documentation, but not sure when, I'll label this "docbug" just to return to this some day.

elucash avatar Jun 04 '21 02:06 elucash

I understand. What do you think about providing a new annotation (@Eager?) that would equivalent to @Derived + @Auxiliary (so also i.e. like @Lazy but eager). We use @Derived a lot (and prefer it to @Lazy cause we know the property will be used) but I don't think there's any case where @Auxiliary wouldn't make sense and it would be nice to avoid having to put both annotations everywhere... I guess it should be quite a common case?

xtaixe avatar Jun 04 '21 08:06 xtaixe