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