Omr: Discuss: Rename "glue code" to "application code"

[rwy0717]

I think people are unsatisfied with the phrasing "glue code" (citation needed 😀). I'd like to suggest we start using the phase application-specific code, or app code.

In source code, I would also like to suggest we move app code to the ::OMRApp top-level namespace. This would keep it absolutely clear what is app-specific, and what is in ::OMR.

Some potential renames:

| old | new |
|----|----|
|MM_MarkingDelegate | OMRApp::GC::MarkingDelegate |
|MM_CollectorLanguageInterface | OMRApp::GC::CollectorDelegate |

Alternatively, we could use the OMR::App namespace. However, if we use component sub-namespaces, I think there is the potential for ambiguity between the OMR::App::GC and OMR::GC namespaces.

In cmake, we can rename any usage of glue to app, E.G OMR_GC_GLUE_TARGET => OMR_GC_APP_TARGET. I don't think we need to update the old autotools build system.

[samolisov]

I think it would be good if the application library extension points (as I understand these libraries is a way for application developers to extend OMR capabilities or in other words to inject some dependencies into the OMR code) will be documented. I tried to build FVTEST without EXAMPLES and have got it is possible but a custom glue library must provide almost all classes and functions by the same way as examples/glue does but for a new OMR customer it could be tricky to understand what exactly the custom glue library should do and what the power it provides for OMR.

If the glue libraries will be renamed, the methods of the library interfaces should be renamed too (VM_application_xxx vs VM_glue_xxx and even VM_example_xxx).

[charliegracie]

I like the idea. The main question is OMR::App::GC or OMRApp::GC? I think I prefer OMRApp::GC

[rwy0717]

The benefit of OMRApp::* is that it forks the namespace at the root, which will make writing ambiguous code a lot harder, and keeps user code completely out of OMR::*.

[samolisov]

@charliegracie @rwy0717 What do you think about the other application libraries; will OMRApp::Core, OMRApp::Util, OMRApp::RAS be OK?

Some functions and structures are global-defined, i.e. declared in omrExampleVM.hpp. By the way, the file looks like should be a part of the GC glue library, not the core one since it is used only in fvtest/gctest/... and the GC glue library itself.

[mstoodle]

Isn't "Application" still confusing, but for a different reason? we're still talking about code that's part of the runtime for a particular language implementation, not what I would normally envision as "application" code.

[rwy0717]

It's true that "application" only makes sense from the OMR perspective. In my mind, the OMRApp namespace is for interfacing OMR->OMRApp, and not a true home for application code. The application might define OMRApp as an alias to their "real" namespace.

namespace OMRApp = JS;

Or do more finely grained aliasing, on a type-by-type basis.

namespace OMRApp {
  using SlotHandle = ::Om::TaggedSlotHandle;
}

FWIW I don't think the word "glue" is confusing, my complaint is that it makes OMR sound like it is hacked together.

[dnakamura]

I don't want to be that guy, but using aliases (ie using SlotHandle = ::Om::TaggedSlotHandle;) requires c++ 11. Not sure if we are allowed to use that yet

[rwy0717]

but using aliases (ie using SlotHandle = ::Om::TaggedSlotHandle;) requires c++ 11.

You can still use typedefs and namespace aliases. That one example came from Om, which does use some c++0x.

I took a look at a thesaurus, so I have some more name suggestions:

• Interface code, OMRInterface::* or OMRI::*
• Connection or connector code, OMRConnect::*
• Integration code, OMRIntegrate::*
• Mesh code, OMRMesh::*
• Stick with glue code, but start using OMRGlue::*
• Distribution-specific code, OMRDist::*

[rwy0717]

What about using the OMRClient namespace?