Description
A property cannot produce either a file of a specific type or a FILE: the two have no common ancestor, so the platform reports that the argument types do not match, or that the property is always NULL.
CLASS Doc;
scan 'Scan' = DATA IMAGEFILE (Doc);
uploaded 'Uploaded' = DATA FILE (Doc);
// currently an error: IMAGEFILE and FILE have no common ancestor
attachment 'Attachment' (Doc d) = OVERRIDE uploaded(d), scan(d);
The same holds for NAMEDFILE with FILE or with a file of a specific type, and for LINK with a link of a specific type. The developer has to convert every branch by hand.
What it takes to fix. Relating the classes is not enough on its own, and doing only that corrupts data silently. A file of a specific type, a FILE and a NAMEDFILE differ not only in what they are declared as but in how the value itself is laid out - a file of a specific type carries only content, a FILE carries content with an extension, a NAMEDFILE also carries a name - while all three occupy the same kind of column. So nothing fails loudly: the branches of a selection are put together untouched, and a value written by the narrower branch is later read as the wider class, producing a file whose extension and name are read out of its content.
The same gap shows up in three places, and all three have to be closed together:
- a selection or a union has to convert each branch to the resulting class, rather than assume the values are interchangeable;
- a value passed to an action, or written in a session without reaching the database, has to be converted as well;
- an existing stored property whose class becomes wider has to have its data converted during the upgrade, not merely retyped.
Links do not have this problem - a link of any type is a string either way - so LINK above a link of a specific type can be done separately and more cheaply than the file part.
Note that this also needs overloading on built-in classes to work first: once the classes of a family are related, the platform can no longer tell two overloads of the family apart, and declarations like open on FILE, NAMEDFILE and RAWFILE separately stop being accepted.
Reason
Storing a file whose type is not known in advance next to files of a known type is ordinary. The conversions between these classes already run when a file is imported or passed to an external system, so the classes look related everywhere except where it matters for writing a property - which is exactly why relating them looks cheaper than it is, and why the value conversion has to be part of the same change.
Description
A property cannot produce either a file of a specific type or a
FILE: the two have no common ancestor, so the platform reports that the argument types do not match, or that the property is alwaysNULL.The same holds for
NAMEDFILEwithFILEor with a file of a specific type, and forLINKwith a link of a specific type. The developer has to convert every branch by hand.What it takes to fix. Relating the classes is not enough on its own, and doing only that corrupts data silently. A file of a specific type, a
FILEand aNAMEDFILEdiffer not only in what they are declared as but in how the value itself is laid out - a file of a specific type carries only content, aFILEcarries content with an extension, aNAMEDFILEalso carries a name - while all three occupy the same kind of column. So nothing fails loudly: the branches of a selection are put together untouched, and a value written by the narrower branch is later read as the wider class, producing a file whose extension and name are read out of its content.The same gap shows up in three places, and all three have to be closed together:
Links do not have this problem - a link of any type is a string either way - so
LINKabove a link of a specific type can be done separately and more cheaply than the file part.Note that this also needs overloading on built-in classes to work first: once the classes of a family are related, the platform can no longer tell two overloads of the family apart, and declarations like
openonFILE,NAMEDFILEandRAWFILEseparately stop being accepted.Reason
Storing a file whose type is not known in advance next to files of a known type is ordinary. The conversions between these classes already run when a file is imported or passed to an external system, so the classes look related everywhere except where it matters for writing a property - which is exactly why relating them looks cheaper than it is, and why the value conversion has to be part of the same change.