I’ve been using Silverstripe for over 6 years now and 1 thing that always bothered me is that it’s impossible to use
abstract classes in the Data Object hierarchy. This mostly boils down 2 “limitations” of the framework;
The framework constantly tries to instantiate object to read their properties such as configs, which by itself in my opinion is already a less than ideal practice. A lot of head way has been done in this area where configs are now almost completely decoupled from the classes themselves so in this regard it shouldn’t be too hard to overcome.
The way SS ORM builds the tables. It currently “simply” loops through objects parents until it hits “DataObject” so that it can merge fields and perform it’s magic. Basically relying on the idea that the classes extending from DataObject should have tables, rest of the classes it depends on the need and this is the major roadblock to using abstract classes. Obviously abstract classes cannot be instantiated and thus the whole ORM falls apart.
Suggestion: If the table schema and class hierarchy are pre-built during something like dev/build, the ORM would no longer need to perform any real-time checks to find “baseTable”, “baseClass” and so on, as these schemes would exist in some manifest and the ORM would simply need to read from it. Also this would decouple the whole DB management side of things from the normal execution of PHP thus allowing much better use of abstract classes, traits, interfaces, etc… and possibly improve performance as well.
Notes: I do plan to try to tackle this problem and suggest it as a PR, but in all honesty I’m not too familiar with the ClassManifest side of things so would need some help in that area.
What do you think?