https://pantsbuild.org/ logo
#development
Title
# development
h

hundreds-father-404

03/13/2020, 3:37 PM
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:
Copy code
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