support edge compilers in non-global namespaces

[tjanczuk]

Currently edge expects to find the EdgeCompiler class in the global namespace of an assembly. To support multiple edge compilers per assembly as well as disambiguate compilers in C# apps (e.g. tests) it would be useful to support edge compilers in a non-global namespace.

Two solutions that come to mind:

1. Edge can enumerate all types across all namespaces in an assembly and use the first EdgeCompiler class it finds.
2. Edge can rely on a naming convention whereby EdgeCompiler class for technology 'foo' is expected in Edge.foo.EdgeCompiler class. In case of C# that could be Edge.cs.EdgeComiler. In case of Python it would be Edge.py.EdgeCompiler.

I like 2 better.

[7sharp9]

I like the second better as well, if fits a pattern that I saw elsewhere in the JavaScript code too.

The original namespace that I had in my F# POC was Edge.fs.EdgeCompiler before I switched to global.

[dfinke]

Pattern #2 works.

Date: Sun, 28 Apr 2013 09:36:35 -0700
From: [email protected]
To: [email protected]
Subject: [edge] support edge compilers in non-global namespaces (#45)

Currently edge expects to find the EdgeCompiler class in the global namespace of an assembly. To support multiple edge compilers per assembly as well as disambiguate compilers in C# apps (e.g. tests) it would be useful to support edge compilers in a non-global namespace.

Two solutions that come to mind:

1. Edge can enumerate all types across all namespaces in an assembly and use the first EdgeCompiler class it finds.
2. Edge can rely on a naming convention whereby EdgeCompiler class for technology 'foo' is expected in Edge.foo.EdgeCompiler class. In case of C# that could be Edge.cs.EdgeComiler. In case of Python it would be Edge.py.EdgeCompiler.

I like 2 better.

—
Reply to this email directly or view it on GitHub.

[glennblock]

@tjanczuk why not just consolidate to language + compiler, i.e. CsCompiler, ScsCompiler, FsCompiler etc? Seems like Edge is redundant here.

[glennblock]

Why keep repeating edge in the compiler name? You could male the convention Edge.lang+compiler ie

Edge.CsCompiler

Also you could drop the namespace requirement even and just look for lang+compiler.

-----Original Message-----
From: "Doug Finke" [email protected]
Sent: ‎4/‎28/‎2013 5:04 PM
To: "tjanczuk/edge" [email protected]
Subject: Re: [edge] support edge compilers in non-global namespaces (#45)

Pattern #2 works.

Date: Sun, 28 Apr 2013 09:36:35 -0700
From: [email protected]
To: [email protected]
Subject: [edge] support edge compilers in non-global namespaces (#45)

Currently edge expects to find the EdgeCompiler class in the global namespace of an assembly. To support multiple edge compilers per assembly as well as disambiguate compilers in C# apps (e.g. tests) it would be useful to support edge compilers in a non-global namespace.

Two solutions that come to mind:

1. Edge can enumerate all types across all namespaces in an assembly and use the first EdgeCompiler class it finds.
2. Edge can rely on a naming convention whereby EdgeCompiler class for technology 'foo' is expected in Edge.foo.EdgeCompiler class. In case of C# that could be Edge.cs.EdgeComiler. In case of Python it would be Edge.py.EdgeCompiler.

I like 2 better.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[tjanczuk]

I don't want to be in the business of capitalizing the first letter of the technology name to construct a name (either namespace or class name). Beyond that I don't care too much what convention we use.

So let me do `Edge.py|cs|ps|fsharp|scs|whatever.EdgeCompiler. I will also fall back to looking for the EdgeCompiler in the global namespace such that existing compilers continue to work.