I don't actually see anything that needs to be done, do you? It seems like the defaults are all fine...
After looking it over during today's meeting, I agree that it seems possible to set up…
Your thoughts on just a method-only interface with an opaque underlying datatype that we can iterate on if we see fit without changing any client code?
At this point, I can't predict whether…
I've removed if_present
, replacing it with matches!(/* ... */, Present { .. })
where it was used (c58fed0)
The idea of using a parameterized trait is nice, but in this case I'd prefer to use methods named set
and set_if_ok
. The former always updates the set point, while the latter only updates the…
This is not the place to debate Husht […]
Agreed. I think you get the tradeoff at this point, so let me know whether you want to have is_present
.
Now a point might be that try_from doesn't give you a SpecifiedValue, it gives you a Result<SpecifiedValue, SomeKindaError>.
Exactly.
But then wouldn't it be most natural just to…
In the Absent case, it's the 0th tuple entry of the payload. In the Present case, it's the spec field of the payload.
If you find it less disorienting, we could do this:
pub enum…
[…] if I already have a SpecifiedValue, is there a way to make it the set_point of a Regulator? Perhaps there should be […]
Yes, I think we should add a set
method for this as soon as…
I think it's best to keep Husht as close as possible to Rust in terms of features, for two reasons.
- If a proposed Rust feature gets adopted by Husht but not by Rust, there's a danger that…
To me, it seems perfectly natural to have this:
pub enum SpecifiedValue {
Absent(String),
Present {
spec: String,
value: f64
}
}
An absent…
Yes, I'll do this—I was just waiting for a go-ahead from you. I should've mentioned that in the last comment.
Or do you just want to defer this issue until after we switch to a view in which elements and regulators are viewed in a more egalitarian fashion?
Yes: the issue becomes moot if we ditch the…
The most convenient place to see a curvature regulator might be in-line with the display of its subject element. So perhaps we need a hybrid of unary regulators in the element list and poly-ary…
I think I've finished responding to this comment and addressing or responding to all the code-level comments. Please review again at your convenience! I'll be working on #64…