This repository was archived by the owner on Nov 28, 2017. It is now read-only.
This repository was archived by the owner on Nov 28, 2017. It is now read-only.
Concrete classes vs. abstract classes / trait #19
Open
Description
It may have been discussed before (I skimmed through the gitter archive but didn't find anything) but I wonder if an abstract class / trait based approach would be feasible as well.
I've tried to come up some advantages / disadvantages (without giving them any priority or evaluation at this point):
Concrete AST
Advantages
- there's only one AST and the AST is only somewhat usable without any library
- speed, if there's only one concrete implementation available, all call-sites should be fast and inlinable
Disadvantages
- if the AST doesn't provide enough useful functions, an implementation needs to wrap the AST or just adapt to it which defeats its purpose (though wrapping is free if it can be provided as a value class)
- if an implementation wants to add additional fields it needs a wrapper, e.g. if an implementation wants to only support one kind of number for optimization purposes, adding a field wouldn't be possible
- the current split between "fast" and "safe" already introduces a second kind of AST, which means there is no canonical implementation anyway
Abstract AST - Implementations provide concrete implementation
Advantages
- Implementations could provide whatever implementations they like without wrapping
- The AST could be minimal set of interfaces / abstract classes.
Disadvantages
- as concrete implementations are missing, the AST itself would not be useful
- if pattern matching / extraction should be a feature of the AST, its implementation will be more complicated if no case classes can be used
- a slight method invocation cost if several json libraries are used that provide implementations at the same time (multimorphic dispatch)
Metadata
Metadata
Assignees
Labels
No labels