Duplicated class member names in ROOT classes

[linev]

There is fLineStyle member in TStyle class:

TString       fLineStyle[30];     ///< String describing line style i (for postScript)

At the same time there is fLineStyle in TAttLine class, which also base class for TStyle.

It makes problem to create JSON for such object - see #8181.
But also can make troubles in the future while:

root [0] TClass::GetClass("TStyle")->GetDataMemberOffset("fLineStyle")
(long) 74

This is offset for member from TAttLine class, but not from TStyle class.
Any attempt to write conversion I/O rules for such member fails because of this.

[linev]

For completeness - here other ROOT classes with similar problem:

class: RooAbsOptTestStatistic member: _projDeps found also in class RooAbsTestStatistic
class: RooAbsPdf member: _selectComp found also in class RooAbsReal
class: TStyle member: fLineStyle found also in class TAttLine
class: TGeoOpticalSurface member: fName found also in class TNamed
class: RooUnblindOffset member: _value found also in class RooAbsHiddenReal
class: RooUnblindPrecision member: _value found also in class RooAbsHiddenReal
class: RooIntegralMorph::MorphCacheElem member: _nset found also in class RooAbsCachedPdf::PdfCacheElem
class: TMVA::DataLoader member: fOptions found also in class TMVA::Configurable
class: TGeoPatternHoneycomb member: fNdivisions found also in class TGeoPatternFinder
class: TGeoPatternHoneycomb member: fStart found also in class TGeoPatternFinder

[couet]

@linev I think you made a PR for that ? right ?

[linev]

@couet I just provide workaround in TBufferJSON for TStyle class only.
I would prefer to change TStyle, but then it makes impossible to change older ROOT files where TStyle objects are stored.

[couet]

so we can close this issue ?

[linev]

No, it is not only TStyle.
One should try to resolve it for all other classes

[AdvaitDhingra]

Can I give this a go?

[linev]

Can I give this a go?

That do you mean?

For TStyle the only solution - workaround in TBufferJSON.

For other classes one should check if class members can be changed - to avoid any possible confusion in the future.

[AdvaitDhingra]

Can I give this a go?

That do you mean?

For TStyle the only solution - workaround in TBufferJSON.

For other classes one should check if class members can be changed - to avoid any possible confusion in the future.

Ahh okay.