[json] provide workaround for TStyle::fLineStyle member

[linev]

it has similar name as field in TAttLine and produces duplicated members
in JSON. This makes impossible to correctly read it back

Solves https://root-forum.cern.ch/t/error-restoring-tstyle-from-json/44879/

[phsft-bot]

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos8-multicore/default, ROOT-fedora30/cxx14, ROOT-fedora31/noimt, ROOT-ubuntu16/nortcxxmod, mac1014/python3, mac11.0/cxx17, windows10/cxx14
How to customize builds

[Axel-Naumann]

Doesn't this need a bump of the ClassDef version number, @pcanal ?

[linev]

I also have same question
From one side, on binary level it remains absolutely the same.
And if we change class version, how ROOT will get idea that old fLineStyle should be converted into new fLineStyles?

[pcanal]

You need to also add a I/O customization rule to actually fill the new data member with the date from the old member.

[linev]

@pcanal Are there such examples?

[pcanal]

I also this is not forward compatible. (Unless we patch all the old release to know about the new version, they will lose the line style information.

I may be more beneficial to solve the underlying JSON I/O problem (not supporting base/derived class aliasing)

[linev]

It may be more beneficial to solve the underlying JSON I/O problem (not supporting base/derived class aliasing)

That do you mean?
Provide different layout for created JSON structures?
It will have huge side effect on JSROOT - one have to rewrite it from scratch complete JavaScript code.

[linev]

Doesn't this need a bump of the ClassDef version number

This does not work.

[linev]

I convert into draft, while simple member name change does not work.
Also increase of class version does not help.

[Axel-Naumann]

It will have huge side effect on JSROOT - one have to rewrite it from scratch complete JavaScript code.

Depends on how you do it. If you use the name as before, but Derived::fMember in case the derived re-uses a member name from a base, then it should be strictly an improvement, and backwards compatible?

[linev]

If you use the name as before, but Derived::fMember in case the derived re-uses a member name from a base, then it should be strictly an improvement, and backwards compatible?

It will require search for member names in all base classes for each write operation - huge performance degradation.

[Axel-Naumann]

That depends on the implementation. If during the serialization you create a map member-name => value-as-string then it's easy to find dupe member names.

[phsft-bot]

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos8-multicore/default, ROOT-fedora30/cxx14, ROOT-fedora31/noimt, ROOT-ubuntu16/nortcxxmod, mac1014/python3, mac11.0/cxx17, windows10/cxx14
How to customize builds

[phsft-bot]

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos8-multicore/default, ROOT-fedora30/cxx14, ROOT-fedora31/noimt, ROOT-ubuntu16/nortcxxmod, mac1014/python3, mac11.0/cxx17, windows10/cxx14
How to customize builds

[pcanal]

This needs a more compete solution but get around the immediate problem.