Recommend use of require_relative

[cnjmike]

In Ruby.stg, recommend you use require_relative instead of require for the generated listeners, etc.

[slaught]

I agree that makes more sense. given how the parser is coded.

I am not sure if it should be included at all by default. In Java and Python the class hierarchy determines the interface to a class. But in Ruby we have the respond_to? method.

I would appreciate your thoughts on whether to keep mimicing the other implementations and checking the class or perhaps leverage more Ruby more and use respond_to?

[cnjmike]

I would recommend against relying on the presence of the class, which looks like what is happening now (if listener.is_a? Listener). I usually expect libraries to cleave to the duck-typing approach in Ruby and would expect the caller to be verifying existence of a supporting method, not a supporting class. I’d use respond_to?.

Of course, I’m assuming people using this gem are going to be more familiar with Ruby than with other implementations of the Antler generator, and I may be wrong. =)

If you do lean the Ruby way, one other thing I noticed that may seem minimal is the use of camel case in method names. Ruby convention is camel cased class names, but delimited (enter_this_rule) method names. Whichever way you go, it’ll be very hard to change in the future without messing with backward compatibility. But I appreciate what a hassle that would be for what amounts to a cosmetic change.

No substantial issues to report yet, by the way! Good job. Using an explicit lexer with lexical modes and a tree listener model. Haven’t been able to evaluate performance but for my application it’s not a big deal anyway

M

On Dec 8, 2014, at 1:40 PM, Chad notifications@github.com wrote:

I agree that makes more sense. given how the parser is coded.

I am not sure if it should be included at all by default. In Java and Python the class hierarchy determines the interface to a class. But in Ruby we have the respond_to? method.

I would appreciate your thoughts on whether to keep mimicing the other implementations and checking the class or perhaps leverage more Ruby more and use respond_to?

—
Reply to this email directly or view it on GitHub #2 (comment).

[slaught]

I agree with the use of respond_to?. I actually got burned by the code when I attempted to write a partial listener without inheriting from the generated class. I will make this change and remove the require for the listener. I will still generator the listener and the visitor which is currently not implemented.

The method names are another issue all together. First I have not figured out how to change the generated method names. I agree camel case is not ruby but I don't know how to change them yet.

The API of the runtime is also a concern. The documented API uses getText. But the Ruby way would be text. In some limited cases I have implemented both methods. For the long term, I am still not sure the best route. There needs to be a way to get from the Antlr documentation or Java API to the Ruby methods and vice versa. This may mean writing a bunch of API docs and cross references or just using the Java API. I have been inconsistent so far as I didn't think about the issue until almost complete. But it is a concern I have for Ruby developers using the gem.