[fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Wayne Sherman]

On Tue, Jan 17, 2023 at 1:23 AM Michael Van Canneyt wrote:
> Yes. The reason is the code generator:
>
> Ideally, every property simply has a unique index specifier.
>
> But when generating classes, the code generator has no way of knowing how
> many properties exist in parent classes, so it must start at 0.
>
>(
>one could imagine helping the code generator by specifying a start point
>per class:
>1000
>2000
>3000
>etc.
>)

If non-REST properties are always not published the codegen could
generate unique index specifiers.  Also, if 0 is not used as an index
specifier, then any non-zero index specifier could be used to indicate
a REST property. (* but I have more to say about this below)

Wayne wrote:
> > function TBaseObject.IsPropertyModified(Info: PPropInfo): Boolean;
> > begin
> >  Result:=Not Assigned(FBits) or FBits.Bits[Info^.NameIndex]
> > end;
> >
> > The name list (from which NameIndex gets its value) includes the
> > published property names of all the parents plus the names in the
> > current class, so for a REST property in a descendant class with Index
> > specifiers starting at 0:
> >  GetParentPropCount+(IndexSpecifier shr IndexShift) = NameIndex

Michael wrote:
> Yes.
> This was long ago, but I seem to remember that I changed that code in production,
> so it would use the same mechanism as MarkPropertyChanged, because there were
> published properties not part of the REST scheme, and in that case, the equation does
> not hold true (becasue nameindex includes non-REST properties).
> That change does not seem to have made it in FPC.

A REST class should know how to generate a complete and correct JSON
representation, so there must be a way to distinguish REST properties
from non-REST.  Which properties have been modified is not sufficient.
I thought any property with an index specifier could be considered
REST, but the first property has an index specifier of 0 which matches
other properties with no index specifier.  One of the extra bit flags
in the index specifier could be used to indicate a REST property since
bits 0-2 seem to be reserved for future use.  But since the mechanism
for persisting objects is based on typeinfo and published properties,
I think the rule should be that ALL REST properties are published and
ALL non-REST properties are NOT published.  Why would you need to
publish any non-REST properties?