Re: [omr-dev] TR_Method Type enum

[Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>]

Hi Mark,

On 1 June 2018 at 23:20, Mark Stoodley <mstoodle@xxxxxxxxxx> wrote:
>
> That's an unfortunate corner of our compiler code base, reflecting some of our efforts to create CRuby, CPython, etc. compilers using the code that ultimately became the Eclipse OMR project.
>
> The code in OMR that's conditional upon these checks should really move to the projects they're concerned with (isJ9 to OpenJ9, isRuby to the Ruby OMR port, etc.), but that hasn't happened yet so they live on. In some cases (from memory) the required refactoring isn't trivial.
>
> I think I can safely say we would prefer there to be no such enum, but we don't yet live in that particular universe. I would prefer not to add to this enum, if at all possible, and would be willing to help brainstorm any scenario where it seems like another isX() would be needed.
>

Okay understood.

I think the JVM legacy also shows in some of the virtual methods. I
was wondering if the Method classes should have default (non VM
specific - pure native) implementation values. Asking everyone to
answer JVM specific questions seems odd.

Regards
Dibyendu