Issue #19772 has been updated by Eregon (Benoit Daloze). @kddnewton
There are a couple of technical hurdles we will need to overcome if we introduce additional fields between versions, but I believe these will be easily overcome.
How? That seems near impossible to me, without having 2 versions of the C code (*.h and *.c and `api_node.c`) & Ruby code too. If there is a single `api_node.c` it would use the struct definitions in the gem for the result of `yp_parse` in interpreter, which would break as soon as there is any field change in any of the node structs. E.g. if there is a new field in the yarp gem then it would read out of bounds. And if we think about serialization I think it's more obvious it cannot work without duplicating all files related to serialization & deserialization and their dependencies (so basically every file of YARP), since it would be different YARP::VERSION and the check when deserializing would (correctly) fail. --- Here is how I see those 5 solutions: 1. not really a solution because the Ripper API is very inconvenient to use and longer-term Ripper might use YARP, and/or be deprecated. 2. this requires quite a lot of work and magic to adapt the namespace. It feels rather messy, but probably feasible. Obviously there is the overhead of defining every Ruby node class twice, etc. 3. this is the simplest solution. It might be the best because of that. 4. I think this cannot work. It would need to duplicate every file but also if you install an older YARP gem how would it find the {.c,.h,.rb} files for current Ruby? It seems impossible. 5. this is the most generic solution and would allow to fully replace the `parser` gem, and make adoption much easier for any tool using the `parser` gem currently. It means more `if` in the codebase but OTOH a single branch to maintain. ---------------------------------------- Misc #19772: API naming for YARP compiler https://bugs.ruby-lang.org/issues/19772#change-104335 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal ---------------------------------------- We are working on the YARP compiler, and have [the first PR ready](https://github.com/ruby/ruby/pull/8042) which introduces the YARP compile method. Our only outstanding question before merging it is about naming. How should we expose the public API for YARP's compile method? Potential suggestions: 1. YARP.compile 2. RubyVM::InstructionSequence.compile(yarp: true) 3. RubyVM::InstructionSequence.compile_yarp 4. Any of the above options, with a name other than yarp (please suggest an alternative) Regarding option 1, which would mirror `YARP.parse`, is the top level constant `YARP` acceptable? cc @matz @ko1 -- https://bugs.ruby-lang.org/