DATEX-II-EU / DatexII

Main repository for issues and bugs for the DATEXII standard
0 stars 0 forks source link

Extension guide should clarify extending abstract classes (Bugzilla Bug 486) #486

Open datexii opened 1 month ago

datexii commented 1 month ago

This issue was created automatically with bugzilla2github.py

Bugzilla Bug 486

Date: 2024-05-31T10:42:30+02:00 From: @iancornwellmottmac To: bugzilla admin <webmaster@datex2.eu>

Last updated: 2024-05-31T10:42:30+02:00

datexii commented 1 month ago

Comment 1960

Date: 2024-05-31 10:42:30 +0200 From: @iancornwellmottmac

The extension guide on the docs site says:

"It’s not possible to sensibly extend abstract classes from Level A, due to the fact that the D2LevelBExtension mechanism does not provide real polymorphism. Hence, the extension could not be instantiated."

The first sentence seems overstated, since extensions of abstract classes from Level A have been made in the past. (The following sentence identifies the very mechanism that can make extensions of abstract classes feasible.)

This sentence, and how we have sometimes spoken about the topic, influenced me to carelessly make an even more overstated remark in other material that has also been used in the extension guide: " Abstract classes cannot be the subject of DATEX II Level B extension..." [wrong!]

I understand the remark about polymorphism, since the XML mapping for extension results in the base class getting extra properties and there is no concrete type that can be instantiated for the extended class as a substitution for the base type. (Level B extension does not follow the Liskov Substitution Principal)

I propose that we improve the extension guide in those 2 places. 1) Expand the point (number 2 under "Known Limitations") that currently starts "It's not possible to sensibly extend abstract classes from Level A", to say something like:

"Level B extension works in the schema by adding an additional optional structure to the base class - unlike regular specialisation it doesn't provide a new type to use as a substitution for the base class. When you instantiate an object, there must be a concrete non-extension class to instantiate. If the base class is concrete, there is no problem. If the base class is abstract then neither it nor the level B specialisation can be instantiated - so there would need to be another concrete specialisation of the base class available." Then we can keep the current 3rd sentence about the two "Generic" classes.

2) Simply delete my whole sentence starting "Abstract classes cannot ". The point still works without saying that.