Why are classes final

[nick-zh]

Moving the discussion from #33 to here

I tend to implement my classes as final in the libraries i have, the question arose by @Hubbitus why that is, because it would be useful to extend the default behaviour.

[nick-zh]

I had some discussions with colleagues about this and checked how other maintainers handle this. There is not one guideline, but for me the advantages to using final are:

• i can shield my users from unwanted side effects when extending my classes, when i change internal logic without breaking the contract (interfaces)
• this again shields both parties maintainter / user from unnecessary headaches and frustration

My main goal is to provide an implementation that should cover 90% percent or more of the use-cases, but give the user an easy way to extend the default behaviour if needed.

In the mentioned case about property parsing, i did some thinking. One way that we could approach this, to make it a bit easier is:

• The class ClassParser could accept ClassPropertyParserInterface[] instead of a single instance
• index of that array could be a type (e.g. string) or fieldname (e.g. my specialClassField)
• the current ClassPropertyParserInterface could be the default fallback if none of the above have been implemented

[nick-zh]

I see your point regarding easy extension and your example. I will need some time to think it over also in terms of strictness of PropertyType you suggested, which i think could make things cleaner / easier as well

[nick-zh]

So after consideration and a good discussion with a friend, i think there is some rework needed on the genrator:

• the parser right now adds complexity, but i think we can cover everything with reflection, which would reduce code and complexity
• you are right, the class parser right now has too many responsibilities, it parsers and converts a class the same time
• the unfortunate naming doesn't really help, it would probably be more helpful to rename PhpClass and PhpClassProperty to AvroRecord and AvroField since i use those in the converter to create the schema anyway

So i think i need:

• one parser that can (should be easy with reflection)
  • return info about the class (name, namespace, doc comments, etc.)
  • return properties (with all their info and docs)
  • return info about functions (props, comments, name, etc)
• converters (class, property, maybe type), that will turn that information into an AvroRecord, AvroField and maybe even AvroType respectively
• then the generator we have right now (adjusted) that will turn that info into a schema

I will still keep the classes final, but since responsibilities are split more clearly, it gives you more control to replace or decorate an existing default implementation.

I am kind of busy right now with a new project, so it might take me some time to change all this ✌️

[Hubbitus]

@nick-zh, thank you very much!

Proper separate parsing into some abstract model and conversion it into another is also very important there, you are right.

[Hubbitus]

You could also look at https://github.com/flix-tech/avro-serde-php#schema-generator
That is annotation-based but looks well-designed at the first glance.

[nick-zh]

I haven't forgotten about this, my regular job is just keeping me very busy atm.
I hope i can tackle the next major in the coming weeks ✌️