[rfc][icedtea-web] refactored properties loader to be reusable
Jiri Vanek
jvanek at redhat.com
Fri Nov 30 11:40:39 UTC 2018
On 11/29/18 7:14 PM, Alex Kashchenko wrote:
> Hi,
>
> On 11/29/2018 11:35 AM, Jiri Vanek wrote:
>>
>> [...]
>>
>> Hello!
>>
>> All should be fixed, unless it leadked to much form refactroing.
>
> I assume verify_jdk_string should take &str, not &String? Any particular reason it uses &String?
Nope. fixed.
>
> In try_key_from_properties_files, can you explain why file is cloned multiple times there?
This is not related to the refacroting. And the fix is not clear to me. Will elaborate as next
changeset.
>
> Its input is an a list of strings (you are wrapping them twice, but they are still strings
> underneath), some of which may be empty, and ownership of the string is not required to print or
> format that string. I suggest to unwrap the strings (or even better - to not wrap them in the first
> place) before calling the loop logic, because this thing is not nice:
>
> file.clone().unwrap_or(std::path::PathBuf::from("None")).display()
>
> Besides these two points patch looks good, I will review a second patch once first one is pushed.
>
>
>> [...]
>>
>> - usage of map. I'm not sure how worthy it is. Mos likly changeset in farer future, mostly for my
>> education (or feel free to add :) )
>
> You are misusing the Option type. It is okay to check it with pattern matching when you are getting
> an Option from API call, when you are interested only in actual call result. But if you are using
> Option itself (taking it as a function parameter), the goal of Option type is to work on (possibly
> empty) underlying value without actually checking whether the value is there. Option is doing these
> checks for you providing map(), and_then() and other functions.
>
> For example, append_deployment_file() shouldn't take an Option as its input, instead it should take
> a plain value. And then be used with Option<...> (though its API) or with plain values where
> convenient.
>
> It is okay to not use functional-like approach, like chains of map() calls (Rust is not a
> pure-functional lang), but in that case it may be better to avoid functional-like APIs like Option
> (besides the use-case, when it is returned and immediately unwrapped).
Rebuke taken.
Will elaborate here to.
TYVM for review!
J.
>
>>
>> [...]
>>
>
>
>
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com M: +420775390109
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refactoredProperties3.patch
Type: text/x-patch
Size: 45321 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20181130/c9d8523e/refactoredProperties3-0001.patch>
More information about the distro-pkg-dev
mailing list