Default values #15
Comments
|
I've also wondered about having default values too, so this is a great issue to raise. One reason for the current design with
So all that made me lean toward the current One obvious one is that, when the |
|
When posed as an either/or question, I'm ambivalent. I don't think default values are inherently better than option types or vice versa. They can both fill each other's role to some extent. That said, I think the two concepts are orthogonal. Especially in languages that support both. void sendMail(bool asHtml = true);
void sendMail(Option<bool> asHtml);
void sendMail(Option<bool> asHtml = None);Having only option types at their disposal forces programmers to introduce an extra state in the system where this might not be appropriate. In the preceding example, Another example is the |
|
Yeah, I suppose I see your point; sometimes you don't want to add a new |
I think languages like Java, C#, etc. would most likely use
Could this be solved by requiring that, in case both the subtype and supertype declare a default value for a particular field/parameter, the values must be compatible (according to the subtyping rules) ? That way it wouldn't matter whether the caller or the callee is responsible for default values; the end result is effectively the same. Though, with that restriction in place, I think it makes sense to make the caller responsible for providing the default values. See examples below.
If that distinction is truly needed, you can still use an Option type. No harm done.
I don't think the documentation/annotation/metadata direction is enough whenever the subtype contains a field/parameter with a default value the supertype is not aware of. See example 2 below. In this case the component model glue code has to be aware of default values.
I completely understand. I'll leave that tradeoff for you to make. ExamplesIt would be awesome if, through some mechanism, the following examples would Just Work™. /** EXAMPLE 1: **/
// Component A:
export sendEmail() { ... }
// Component B:
import sendEmail()
sendEmail(); // No transformation needs to be done.
/** EXAMPLE 2: **/
// Component A:
export sendEmail(asHtml: bool = false) { ... }
// Component B:
import sendEmail()
sendEmail(); // Component model glue code transforms this call to `sendEmail(false)`
/** EXAMPLE 3: **/
// Component A:
export sendEmail(asHtml: bool) { ... }
// Component B:
import sendEmail(asHtml: bool = false)
sendEmail(); // The language of component B transforms this call to `sendEmail(false)`
sendEmail(false); // No transformation needs to be done.
/** EXAMPLE 4: **/
// Component A:
export sendEmail(asHtml: bool = false) { ... }
// Component B:
import sendEmail(asHtml: bool)
sendEmail(false); // No transformation needs to be done.
/** EXAMPLE 5: **/
// Component A:
export sendEmail(asHtml: bool = false) { ... }
// Component B:
import sendEmail(asHtml: bool = false)
sendEmail(); // The language of component B transforms this call to `sendEmail(false)`
sendEmail(false); // No transformation needs to be done.
/** COUNTER EXAMPLE: Should NOT work? **/
// Component A:
export sendEmail(asHtml: bool = false) { ... }
// Component B:
import sendEmail(asHtml: bool = true) // Import triggers an error in the component model subtyping rules?
// sendEmail(); |
My expectation here is that the language bindings start with the interface type (which does not have implicit nullability, only
That's an interesting idea! Yes, I suppose theoretically it could. It seems like this would put further requirements on this constant-valued interface-typed expression language, though. Thanks for writing out all those examples! I hadn't even thought about the interaction between default values and function subtyping allowing extra optional parameters... some of those cases were rather surprising to me and it seems like we'll need to think long and hard about this. |
|
Nice to see this fleshed out proposal. Having to deal with None v Some branches in all places where things are optional does create overhead that is nicer to avoid with default values. Is the intention for the "default" default implementations of types to be defined? Can we extend the proposal semantics to the WIT definitions at this point? |
TLDR, these proposed changes:
optiontype from its special status in various places.Definition
Regarding the
listconstant: every provided<constant>must be a subtype of the list's<intertype>.Aliases
Types
Every constant expression has a fully deterministic interface type.
Updates to existing definitions
This is already more detailed than I intended it to be. Let me know if there is interest in pursuing this any further.
The text was updated successfully, but these errors were encountered: