Name conflicts - 0.8

[michaelaird]

I have classes with the same name but in different folders/namespaces. The new compiler doesn't seem to like it:

The type 'BigBrainScript.Registration.ViewModels.SessionOptionViewModel' conflicts with with 'BigBrainScript.CampBuilder.ViewModels.SessionOptionViewModel' as they have the same name.

I think the cause is this: https://github.com/nikhilk/scriptsharp/commit/74b3b8e1a1101f2793001e8d612d3d6b66cd8458#commitcomment-1968924

[nikhilk]

With the module pattern, there aren't any "namespaces" ... other than the module name itself. All public types in the assembly get added to the module representing that assembly. This simplification greatly simplifies the type system implementation, lends to more efficient runtime lookups, and results in much better minimization.

Workaround obviously is to make things uniquely named. But before resorting to that as a workaround, it might be interesting to think whether it is actually goodness to name them uniquely (if both types might be referenced by the same code) or it would be even better to think of them as belonging to separate modules (eg. different view models for different pages as the names above seem to suggest) so the required script can get loaded into a page.

Actually I didn't think this would be a big change. The previously existing [ScriptNamespace] feature had a similar effect - it collapsed all c# namespaces into a single script namespace. I think the error message should have occurred before too... or are you saying the code used to compile, but doesn't anymore? Now the script namespace is automatically based on the assembly name specified with [ScriptAssembly], so the change only impacts projects that didn't use a [ScriptNamespace].

There might be an argument to make names unique in the compiler... I thought of that, and then opt'd out, since I think a developer would want to control names that constitute the public API surface exposed by a module.

[michaelaird]

Hmmm. I wasn't using the [ScriptNamespace] attribute before and everything compiled (and worked) properly with no complaints.

In the new module paradigm, it might make more sense to split things up but I don't love the idea of having to maintain a separate assembly/project per module.

[nikhilk]

Agree on the pain induced by separate project per module. I am all up for suggestions and solving this problem.

There was an odd feature called "web app partitioning" (still exists in master branch). When you turned that on, a script got generated per folder within the project. And there was a "shared" folder which could contain code that would get included into every script.

However that feature was violating one of the fundamental assumptions in the compiler - that the code being compiled is valid code that compiles successfully by the c# compiler. In this partitioned mode, the c# compiler was validating at the project level, and not at the folder level. In the future, when moving to support new language features with either roslyn or nrefactory, I think that partitioned mode can be implemented more soundly by actually compiling and validating code at per-folder at the c# level. Question is whether something can be done reasonably before then.

By the way this was done purely within the msbuild task ... the compiler didn't know about this. The msbuild task would invoke the compiler multiple times with different set of source files each time. So in that sense its certainly possible to experiment with this much more readily.

Thoughts?

---

Since you weren't using script namespace, none of the collapsing was happening. Hence no problems with similar named types at compile time or runtime. However [ScriptNamespace] was about producing more compact script, with patterns that resemble how many other hand-written scripts are written ... everything hanging off of single root object.