Open 0xdaryl opened 6 years ago
It looks like using
statements importing the Compiler sub-namespace into the top-level OMR namespace may allow this to not be a change causing breaking pre-requisites in downstream projects:
#include <iostream>
namespace OMR {
namespace Compiler {
class Base {
public:
Base() { std::cout << "Base default construction" << std::endl; }
~Base() { std::cout << "Base destruction" << std::endl; }
};
typedef Base BaseConnector;
}
using namespace Compiler;
}
namespace J9 {
class Extension : public OMR::BaseConnector {
public:
Extension() { std::cout << "Extension default construction" << std::endl; }
~Extension() { std::cout << "Extension destruction" << std::endl; }
};
}
int main() {
J9::Extension ext;
return 0;
}
Thanks for the suggestion @lmaisons! That will be useful to stage the rollout of this.
Per the discussion in #1706, the compiler technology should be isolated in its own nested namespace in OMR. i.e.,
OMR::Compiler::
.This is the umbrella task to track all the work.
There will be implications in downstream projects that extend OMR compiler classes, so some care will be needed to stage PRs appropriately.