Closed kvark closed 9 years ago
Glob imports is not generally a bad practice. It should be used for traits, which methods need to be visible to be called, not for types. gfx::traits::*
is precisely this, except for your code tends to re-use types from there directly instead of typing the full path (e.g. gfx::Factory
).
I do agree that spawning a factory for each text renderer would look better.
It should be used for traits
What's the difference between function, struct and trait here? Glob imports are bad because:
gfx::traits
will be extended with trait with the same name as in gfx_text
In my opinion there is no excuse for glob imports except, maybe, reexporting or test code.
Looking at the guidelines:
Avoid use *, except in tests Prefer fully importing types/traits while module-qualifying functions.
It does seem to support your view, in general at least. However, use gfx::traits::*
is a case that might be a good exception from this general rule, since it's importing traits only.
I don't think this is a good link for the guidelines though, it seems WIP and rough. The final version may be more descriptive.
I just don't understand what's the profit of using glob here, given the arguments above. Just to type a few chars less?..
The profit is - we might be changing the exported traits under the hood in gfx-rs without breaking the API. Like, some of the methods from Canvas
were moved to Stream
, which Canvas
implemented, and no one needed to fix any breaks.
The profit is - we might be changing the exported traits under the hood in gfx-rs without breaking the API
Well, the problem is, it can break someone's code as well. This won't compile:
mod a {
pub trait Test {}
}
mod b {
use a::*;
trait Test {}
}
@Kagami should be good now
Thanks!
Cool, thanks!
Little nits:
gfx::traits
imports explicit? I believe glob imports is a bad practice.spawn_factory
will be used in every Text Render spawn and factory returned bygfx_window_glutin::init
just got ignored.