Import status

Jeremy Jeremy_member at pathlink.com
Wed Jul 12 07:26:08 PDT 2006


In article <e9303p$qdr$1 at digitaldaemon.com>, Lucas Goss says...
>
>There seems to be some overlap of issues, so maybe a collection of 
>issues and resolutions would help focus the discussion? I'm just listing 
>what appears to be suggested (and what I remember), so feel free to add 
>or correct where necessary. And maybe the wiki could even help 
>facilitate this?
>
>problems:
>   -Name collisions local (owned by programmer)
>   -Name collisions external (caused by outside libraries)
>   -Too wordy (causing inconsistency and maintainability problems)
>   -Default gotchas (cause problems or make maintainability harder)
>
>solutions:
>
>-static import:
>   -tries to solve problem of name collisions, requiring FQN's
>

I'm new in this discussion :) What are "static imports" and FQN's?

>-alias currently:
>   -tries to solve problem of being too wordy, allowing a shorter name
>
>-selective-importing:
>   -tries to solve problem of name collisions
>
>-prefix-importing proposed (import std.string alias str)
>   -tries to solve problem of name collisions
>
>-private invisible (not visible to importing modules)
>   -tries to solve problem of name collisions by hiding modules
>   -tries to make private more intuitive
>
>-private by default
>   -tries to solve the problem of name collisions
>   -tries to solve the problem of default gotchas
>
>Lucas

In my FreeUniverse game, 90% of my imports are "private", just because things
seem to conflict less that way (However, I had a ton of "std" name conflicts, so
I had to make those modules public at some base module). So if I had to vote for
something, I think I would go for "private by default", and maybe that "import
<module> alias <name>" syntax too :)

- jeremy





More information about the Digitalmars-d mailing list