Modpath error: Duplicate identifier

Monkey Forums/Monkey Bug Reports/Modpath error: Duplicate identifier

V. Lehtinen(Posted 2014) [#1]
Hey!

This "bug" is REALLY annoying...! What I have, are 2 files that are named the same, but are in different paths...

Example:
Import framework.component.collision
Import framework.system.collision


I would really appreciate it, if Monkey would be made a little bit smarter about this...... OR, if anyone has any workarounds, those are welcome too. Allowing this kind of paths would really keep my project clean....


Thanks!
~misthema


ziggy(Posted 2014) [#2]
As per Monkey design, filename IS the classes prefix (namespace-like) so this is causing a name clash. Maybe Monkey should treat this as a namespace and "merge" things... ?


V. Lehtinen(Posted 2014) [#3]
Yeah, I understand namespacing, but would be awesome to create packages with file paths. :/ It would keep things simple...


marksibly(Posted 2014) [#4]
Yes, unfortunately for now you'll have to rename one of the files.

Given another a chance, I would probably have added namespaces to monkey - but I didn't, and it would be a major mission to do so now.

A possible kludge around would be to add something like 'import as', eg:

Import framework.system.collision As collision2

I may have a look into this eventually, but for now, you're stuck with having to rename a file.


ImmutableOctet(SKNG)(Posted 2014) [#5]
I'm confused, can you not just use aliases? Those work exactly like what Mark was suggesting to add.

Just write something like:


That's it; works just fine for me. The only potential problem is that modules importing the module with the aliases get conflicts without using the aliases; which is already pretty normal. Just use the aliases from the module importing the conflicting elements. If you really want to, you could probably use private imports and aliases to ensure the types/classes/other aren't ever used without the aliases. You could even go a step further by using a separate module to import the private imports, just so basically no modules have access to the direct imports of those modules.

I even wrote a small example, here are the files (Directories are acting as names):

EDIT: Updated the example to be more specific to this situation.

"v" (Build file):


"x":


"y/y" (The 'y' module has its own folder in the 'v' module's directory):


"y/w" (The 'y' module's specific implementation):


"z/z" (The 'z' module has its own folder in the 'v' module's directory):


"z/w" (The 'z' module's specific implementation):


Sure, they're not as great as just having in-line aliases when importing, but unless we're talking about my previous problems with cross-module function overloads, you can just use aliases. Or, you know, exact module paths: "component.collision.INSERTHERE". It's as simple as that. The cross-module function overload thing is annoying, but it doesn't apply to anything else, really. Anything you'd have class/alias-wise from a conflicting module would be a local-only name, anyway. You shouldn't have two classes, from two different modules, with the exact same name, used in a module (Without resolving which is which properly). Of course you'll see a conflict if you have two classes from different modules which share the same name.

Functions would basically be the only time this kind of thing is acceptable without deeper resolution. Functions can have overloads, meaning that they can effectively do completely different things with the exact same name.

I'm surprised Mark didn't say anything about this. Just keep in mind that until the next experimental Monkey update, aliases are broken with the core types (Int, Float, String, Bool, etc). But, those aren't really relevant, anyway; this setup should work no matter the version. - As of V82(B), the bug with 'Alias' I mentioned has been resolved.

Overall, the 'Alias' keyword is fantastic, and I don't know why it wasn't recommended to you.