-
Notifications
You must be signed in to change notification settings - Fork 13
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
Fixup load api #141
Fixup load api #141
Conversation
This is mainly intended to clear up confusion around how to use load_ufo; the answer is "don't". I believe that the previous API of splitting up the creation of the font from the loading was unnecessary. I also suspect that having the Font object hold on to the DataRequest is unnecessary, although there are possible arguments in favor of this approach. In any case, the main confusion with the previous API is that loading with a data request took `&self` by reference but returned a new font object, which is confusing. I would expect it either to take a DataRequest as an argument to an associated function, or I would expect it to take `&mut self` and load the contents of the file into the current font?
I don't think we need to keep request around, except when we eventually (?) implement lazy loading? |
@cmyr How bout making this pub fn load(path: &dyn AsRef<Path>) -> Result<Font, Error> {
Self::load_requested_data(path, DataRequest::default())
}
pub fn load_requested_data(
path: &dyn AsRef<Path>,
request: DataRequest,
) -> Result<Font, Error> {
// ...
} Or something so we don't have to have an inner impl function to aoid monomorphization? |
Request was added in #53 because it was needed by @ctrlcctrlv, so I don't anticipate removing it. I'd be happy to look at various patches to remove that inner function and see how they look? |
I'm going to merge this as-is, and if fred has any comments we can always revise it later. |
This is mainly intended to clear up confusion around how to use
load_ufo; the answer is "don't".
I believe that the previous API of splitting up the creation of the font
from the loading was unnecessary. I also suspect that having the Font
object hold on to the DataRequest is unnecessary, although there are
possible arguments in favor of this approach.
In any case, the main confusion with the previous API is that loading
with a data request took
&self
by reference but returned a new fontobject, which is confusing. I would expect it either to take a
DataRequest as an argument to an associated function, or I would expect
it to take
&mut self
and load the contents of the file into thecurrent font?
@ctrlcctrlv Does this change work for you? Do you ever do anything where you create a
Font
and then do some other stuff before callingload_ufo
? My medium-term vision would be to maybe remove thedata_request
field onFont
; alternatively we could keep it, but only exposed immutably (via a getter?) my thinking is that mutating the request after the font is loaded doesn't do anything, but could confuse the user?closes #138