-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ucd/bidi] BidiClass should use the long names #37
Comments
Good point and great idea! Having a mod that only aliases the names sounds like the best alternate to allow access to the same enum variant under different names, while supporting For the mod name, I like the term Then, it's a matter of the mod path. Do we want to have I don't know if there are any similar cases in the current Rust code to see what's the common practice. So, we can try whatever that's more intuitive and practical to use, and clear to implement. I think the first path is the best in these perspectives. What do you think? |
If the first is valid, it makes the most sense. Even if it's not actually that way, it feels like the I just tested that, and I couldn't get it to work. Because it's exposed currently as pub enum Enum {
LongName1,
LongName2,
}
pub mod EnumAbbr {
pub use super::Enum::LongName1 as L1;
pub use super::Enum::LongName2 as L2;
} The only place where this would break down is if you try to use |
Generally, the reason I usually prefer to keep things as children of a main type (struct/trait) is to make them easier to use having the main type imported ( Looks like having About using a sudo-type IMO, we want the basics of this aliasing to be crystal clear for the users. We don't want anyone to think of the aliasing mod as a type, but just a namespace to import some shorthands easily—instead of creating the aliases themselves. That said, I think we can change One thing to remember here is that every component can have more than one property type which may require aliasing, so, we need the hierarchy. PS. Another option, for the future, would be using |
The Bidi_Class_Values enum should use the long names of the bidi classes, for clarity and to fit in better with the rest of the ucd api and the Rust ecosystem.
This can probably be bikeshedded ad nauseum, but defaulting to the descriptive names seems the better idea and §5.8.1 Property Aliases tells us that the long symbolic names are the preferred aliases. (Cases like
Age
where we can provide a more meaningful struct rather than a enum excepted, of course.)We could offer a
alias
mod or such which providespub use
bindings to the abbreviated symbolic name. PropertyValueAliases.txt could (in theory) be used to generate and/or test the aliases.The text was updated successfully, but these errors were encountered: