Then you need to declare the object as deprecated. How it is done in delphi. The apparent appearance of new features (which as it turns out are a bug) misleads people
No, deprecated means that no further work is done and that even bugs aren't fixed. However we do fix bugs (as seldom as they are for
object) and here and then a feature implemented for classes falls off for objects as well simply because they share a lot of code in the compiler.
We are repeatedly told that he core developers don't like object. We are also repeatedly told that TP and Delphi compatibility are extremely important.
Please don't put words in our mouths. We don't say that we “don't like object”. It's simply that we see no real use to invest in extending it.
object has its uses (it's even used inside the compiler in some locations, though nowadays they could be replaced with advanced records) like the one mentioned by
kuperstecher on embedded platforms, but that's it. It's simply that the type is not going to grow beyond its original aspirations.
In my opinion class and object should be rectified to go hand in hand with each other. On syntax level nothing would change only the internals like the VMT could change. That would mean full backward compatibility on code level. Internally object and class could be managed in the same way, for the class type this would mean that there should be a more lightweight base class other than TObject and VMT being optional. If there is a very lightweight object and class type, having no overhead, i.e. internally behaving like a record, then even the record type could be seen as deprecated.
They are too different and there is code out there that depends on these differences (yes, even the VMT, because the class vmt is available as
System.TVMT and the
object one is also
documented). So not going to happen.