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? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel