That sounds like a yes in disguise.

Maybe we add a

LazyField

vs.

EagerField

distinction? So long as the end API for users is the same, i.e. that they call

my_tgt.get(MyField).value

without having to know if its lazy or not, then I’m okay with it. For this specific

Address

problem, we would always pass the

Address

to the constructor. For

EagerField

, it throws away the

Address

after the constructor call. For

LazyField

, it stores the

Address

so that it can refer to it later when lazily hydrated. @average-vr-56795 this circumvents your concern about using

@memoized_property

when it really isn’t appropriate to. It is weird to

memoize

this:

class BoolField(PrimitiveField):
    default: ClassVar[bool]
    raw_value: Optional[bool]

    @memoized_property
    def value(self) -> bool:
        if self.raw_value is None:
            return self.default
        return self.raw_value

My only concern is that field authors have to decide when to use

LazyField

vs

EagerField

? Maybe that’s not that bad, that they should be thinking about the performance implications of hydrating their field? We’d default to suggesting

EagerField

. And, the majority of fields wouldn’t even have to make a decision because they would subclass some helper field like

BoolField

or

StringField

, which already made the correct decision