replace earlier binding infrastructure by jonsequitur · Pull Request #408 · dotnet/command-line-api

jonsequitur · 2019-02-09T15:43:01Z

This is attempt #3 at a generalized model binding infrastructure with lessons learned from the previous two iterations. If we think this is a good approach, this is intended to replace the following types and their related code:

TypeBinder
MethodBinder
ReflectionBinder

This is intended to address the following scenarios in a way that is flexible enough to be leveraged within app models, e.g. DragonFruit:

Binding input from various sources (ParseResult, service provider, arbitrary inputs such as environment variables, etc.) to arbitrary types (including constructor parameters, property setters, and handler parameters)
Binding in the absence of invocation
Easier testing of binding operations

It also shifts the code for building options based on a method signature, which DragonFruit uses, into System.CommandLine.DragonFruit. Some of this may later move under the app model work but as it's highly convention-based, we decided that it does not belong in the core library.

KathleenDollard · 2019-02-12T20:02:44Z

+ return GetValues(context, ConstructorDescriptor.ParameterDescriptors);
+ }
+
+ public object CreateInstance(BindingContext context)


Nit, consider GetInstance

Can you explain how you think about the distinction here?

On second look, Create is fine

KathleenDollard · 2019-02-12T20:06:48Z

+ new SpecificSymbolValueSource(option));
+ }
+
+ public void BindMemberFromCommand<TValue>(


Does this mean BindMemberFromArgument? How will a tight coupling between commands and arguments here work with multiple arguments? I do not believe people think about commands having values as much as having arguments.

Ignore the above because this isn't the place for it, but to clarify the confusion.
Our implementation is at odds with the ways I believe people think about the problem, and reflects an implementation detail. I do not believe people say "What's the value of that command?" Nor "What's the value of the argument on that option?" I think they would say "What's the value of the argument?" or "What's the value of the option?" and that is how Help seems laid out to me. I think this is going to be a rough cognitive load and reflects an implementation detail, and I know I will keep making this mistake whenever I am thinking about the real problem (the CLI).
But this has nothing to do with the problem we are trying to solve today.

It does mean bind from the argument. The concern is a good one. I think conceptually "What is the value for this option" is more intuitive but less precise than "What is the value for this option's argument"? And yes, the value for a command will become more ambiguous with #310.

KathleenDollard · 2019-02-12T20:14:13Z

+
+namespace System.CommandLine.Binding
+{
+ public class ModelDescriptor


AppModels will need to set just some properties. I think this will be a need for some other cases as well. How would you pass the list of PropertyDescriptors to this class?

Do you mean set some properties that were not discovered via reflection?

KathleenDollard · 2019-02-12T20:24:52Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


People may be confused by this - properties now appear to have default values. Not sure if we can work with them.

This isn't intended to being limited the capabilities of reflection. The intention is to be able to annotate the model descriptor so that, for example, if you know that a given type behaviorally has a default, you can define that in the model.

KathleenDollard · 2019-02-12T21:31:23Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


Consider returning the type default instead of null.

Good catch.

jonsequitur · 2019-02-19T16:43:54Z

@dotnet-bot test Ubuntu16.04 Release

…cts to DragonFruit

jonsequitur · 2019-02-19T23:13:32Z

@dotnet-bot test Ubuntu16.04 Release

jonsequitur · 2019-02-09T15:43:01Z

This is attempt #3 at a generalized model binding infrastructure with lessons learned from the previous two iterations. If we think this is a good approach, this is intended to replace the following types and their related code:

TypeBinder
MethodBinder
ReflectionBinder

This is intended to address the following scenarios in a way that is flexible enough to be leveraged within app models, e.g. DragonFruit:

Binding input from various sources (ParseResult, service provider, arbitrary inputs such as environment variables, etc.) to arbitrary types (including constructor parameters, property setters, and handler parameters)
Binding in the absence of invocation
Easier testing of binding operations

It also shifts the code for building options based on a method signature, which DragonFruit uses, into System.CommandLine.DragonFruit. Some of this may later move under the app model work but as it's highly convention-based, we decided that it does not belong in the core library.

KathleenDollard · 2019-02-12T20:02:44Z

+ return GetValues(context, ConstructorDescriptor.ParameterDescriptors);
+ }
+
+ public object CreateInstance(BindingContext context)


Nit, consider GetInstance

Can you explain how you think about the distinction here?

On second look, Create is fine

KathleenDollard · 2019-02-12T20:06:48Z

+ new SpecificSymbolValueSource(option));
+ }
+
+ public void BindMemberFromCommand<TValue>(


Does this mean BindMemberFromArgument? How will a tight coupling between commands and arguments here work with multiple arguments? I do not believe people think about commands having values as much as having arguments.

Ignore the above because this isn't the place for it, but to clarify the confusion.
Our implementation is at odds with the ways I believe people think about the problem, and reflects an implementation detail. I do not believe people say "What's the value of that command?" Nor "What's the value of the argument on that option?" I think they would say "What's the value of the argument?" or "What's the value of the option?" and that is how Help seems laid out to me. I think this is going to be a rough cognitive load and reflects an implementation detail, and I know I will keep making this mistake whenever I am thinking about the real problem (the CLI).
But this has nothing to do with the problem we are trying to solve today.

It does mean bind from the argument. The concern is a good one. I think conceptually "What is the value for this option" is more intuitive but less precise than "What is the value for this option's argument"? And yes, the value for a command will become more ambiguous with #310.

KathleenDollard · 2019-02-12T20:14:13Z

+
+namespace System.CommandLine.Binding
+{
+ public class ModelDescriptor


AppModels will need to set just some properties. I think this will be a need for some other cases as well. How would you pass the list of PropertyDescriptors to this class?

Do you mean set some properties that were not discovered via reflection?

KathleenDollard · 2019-02-12T20:24:52Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


People may be confused by this - properties now appear to have default values. Not sure if we can work with them.

This isn't intended to being limited the capabilities of reflection. The intention is to be able to annotate the model descriptor so that, for example, if you know that a given type behaviorally has a default, you can define that in the model.

KathleenDollard · 2019-02-12T21:31:23Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


Consider returning the type default instead of null.

Good catch.

jonsequitur · 2019-02-19T16:43:54Z

@dotnet-bot test Ubuntu16.04 Release

…cts to DragonFruit

jonsequitur · 2019-02-19T23:13:32Z

@dotnet-bot test Ubuntu16.04 Release

jonsequitur · 2019-02-09T15:43:01Z

This is attempt #3 at a generalized model binding infrastructure with lessons learned from the previous two iterations. If we think this is a good approach, this is intended to replace the following types and their related code:

TypeBinder
MethodBinder
ReflectionBinder

This is intended to address the following scenarios in a way that is flexible enough to be leveraged within app models, e.g. DragonFruit:

Binding input from various sources (ParseResult, service provider, arbitrary inputs such as environment variables, etc.) to arbitrary types (including constructor parameters, property setters, and handler parameters)
Binding in the absence of invocation
Easier testing of binding operations

It also shifts the code for building options based on a method signature, which DragonFruit uses, into System.CommandLine.DragonFruit. Some of this may later move under the app model work but as it's highly convention-based, we decided that it does not belong in the core library.

KathleenDollard · 2019-02-12T20:02:44Z

+ return GetValues(context, ConstructorDescriptor.ParameterDescriptors);
+ }
+
+ public object CreateInstance(BindingContext context)


Nit, consider GetInstance

Can you explain how you think about the distinction here?

On second look, Create is fine

KathleenDollard · 2019-02-12T20:06:48Z

+ new SpecificSymbolValueSource(option));
+ }
+
+ public void BindMemberFromCommand<TValue>(


Does this mean BindMemberFromArgument? How will a tight coupling between commands and arguments here work with multiple arguments? I do not believe people think about commands having values as much as having arguments.

Ignore the above because this isn't the place for it, but to clarify the confusion.
Our implementation is at odds with the ways I believe people think about the problem, and reflects an implementation detail. I do not believe people say "What's the value of that command?" Nor "What's the value of the argument on that option?" I think they would say "What's the value of the argument?" or "What's the value of the option?" and that is how Help seems laid out to me. I think this is going to be a rough cognitive load and reflects an implementation detail, and I know I will keep making this mistake whenever I am thinking about the real problem (the CLI).
But this has nothing to do with the problem we are trying to solve today.

It does mean bind from the argument. The concern is a good one. I think conceptually "What is the value for this option" is more intuitive but less precise than "What is the value for this option's argument"? And yes, the value for a command will become more ambiguous with #310.

KathleenDollard · 2019-02-12T20:14:13Z

+
+namespace System.CommandLine.Binding
+{
+ public class ModelDescriptor


AppModels will need to set just some properties. I think this will be a need for some other cases as well. How would you pass the list of PropertyDescriptors to this class?

Do you mean set some properties that were not discovered via reflection?

KathleenDollard · 2019-02-12T20:24:52Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


People may be confused by this - properties now appear to have default values. Not sure if we can work with them.

This isn't intended to being limited the capabilities of reflection. The intention is to be able to annotate the model descriptor so that, for example, if you know that a given type behaviorally has a default, you can define that in the model.

KathleenDollard · 2019-02-12T21:31:23Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


Consider returning the type default instead of null.

Good catch.

jonsequitur · 2019-02-19T16:43:54Z

@dotnet-bot test Ubuntu16.04 Release

…cts to DragonFruit

jonsequitur · 2019-02-19T23:13:32Z

@dotnet-bot test Ubuntu16.04 Release

jonsequitur · 2019-02-09T15:43:01Z

This is attempt #3 at a generalized model binding infrastructure with lessons learned from the previous two iterations. If we think this is a good approach, this is intended to replace the following types and their related code:

TypeBinder
MethodBinder
ReflectionBinder

This is intended to address the following scenarios in a way that is flexible enough to be leveraged within app models, e.g. DragonFruit:

Binding input from various sources (ParseResult, service provider, arbitrary inputs such as environment variables, etc.) to arbitrary types (including constructor parameters, property setters, and handler parameters)
Binding in the absence of invocation
Easier testing of binding operations

It also shifts the code for building options based on a method signature, which DragonFruit uses, into System.CommandLine.DragonFruit. Some of this may later move under the app model work but as it's highly convention-based, we decided that it does not belong in the core library.

KathleenDollard · 2019-02-12T20:02:44Z

+ return GetValues(context, ConstructorDescriptor.ParameterDescriptors);
+ }
+
+ public object CreateInstance(BindingContext context)


Nit, consider GetInstance

Can you explain how you think about the distinction here?

On second look, Create is fine

KathleenDollard · 2019-02-12T20:06:48Z

+ new SpecificSymbolValueSource(option));
+ }
+
+ public void BindMemberFromCommand<TValue>(


Does this mean BindMemberFromArgument? How will a tight coupling between commands and arguments here work with multiple arguments? I do not believe people think about commands having values as much as having arguments.

Ignore the above because this isn't the place for it, but to clarify the confusion.
Our implementation is at odds with the ways I believe people think about the problem, and reflects an implementation detail. I do not believe people say "What's the value of that command?" Nor "What's the value of the argument on that option?" I think they would say "What's the value of the argument?" or "What's the value of the option?" and that is how Help seems laid out to me. I think this is going to be a rough cognitive load and reflects an implementation detail, and I know I will keep making this mistake whenever I am thinking about the real problem (the CLI).
But this has nothing to do with the problem we are trying to solve today.

It does mean bind from the argument. The concern is a good one. I think conceptually "What is the value for this option" is more intuitive but less precise than "What is the value for this option's argument"? And yes, the value for a command will become more ambiguous with #310.

KathleenDollard · 2019-02-12T20:14:13Z

+
+namespace System.CommandLine.Binding
+{
+ public class ModelDescriptor


AppModels will need to set just some properties. I think this will be a need for some other cases as well. How would you pass the list of PropertyDescriptors to this class?

Do you mean set some properties that were not discovered via reflection?

KathleenDollard · 2019-02-12T20:24:52Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


People may be confused by this - properties now appear to have default values. Not sure if we can work with them.

This isn't intended to being limited the capabilities of reflection. The intention is to be able to annotate the model descriptor so that, for example, if you know that a given type behaviorally has a default, you can define that in the model.

KathleenDollard · 2019-02-12T21:31:23Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


Consider returning the type default instead of null.

Good catch.

jonsequitur · 2019-02-19T16:43:54Z

@dotnet-bot test Ubuntu16.04 Release

…cts to DragonFruit

jonsequitur · 2019-02-19T23:13:32Z

@dotnet-bot test Ubuntu16.04 Release

jonsequitur · 2019-02-09T15:43:01Z

This is attempt #3 at a generalized model binding infrastructure with lessons learned from the previous two iterations. If we think this is a good approach, this is intended to replace the following types and their related code:

TypeBinder
MethodBinder
ReflectionBinder

This is intended to address the following scenarios in a way that is flexible enough to be leveraged within app models, e.g. DragonFruit:

Binding input from various sources (ParseResult, service provider, arbitrary inputs such as environment variables, etc.) to arbitrary types (including constructor parameters, property setters, and handler parameters)
Binding in the absence of invocation
Easier testing of binding operations

It also shifts the code for building options based on a method signature, which DragonFruit uses, into System.CommandLine.DragonFruit. Some of this may later move under the app model work but as it's highly convention-based, we decided that it does not belong in the core library.

KathleenDollard · 2019-02-12T20:02:44Z

+ return GetValues(context, ConstructorDescriptor.ParameterDescriptors);
+ }
+
+ public object CreateInstance(BindingContext context)


Nit, consider GetInstance

Can you explain how you think about the distinction here?

On second look, Create is fine

KathleenDollard · 2019-02-12T20:06:48Z

+ new SpecificSymbolValueSource(option));
+ }
+
+ public void BindMemberFromCommand<TValue>(


Does this mean BindMemberFromArgument? How will a tight coupling between commands and arguments here work with multiple arguments? I do not believe people think about commands having values as much as having arguments.

Ignore the above because this isn't the place for it, but to clarify the confusion.
Our implementation is at odds with the ways I believe people think about the problem, and reflects an implementation detail. I do not believe people say "What's the value of that command?" Nor "What's the value of the argument on that option?" I think they would say "What's the value of the argument?" or "What's the value of the option?" and that is how Help seems laid out to me. I think this is going to be a rough cognitive load and reflects an implementation detail, and I know I will keep making this mistake whenever I am thinking about the real problem (the CLI).
But this has nothing to do with the problem we are trying to solve today.

It does mean bind from the argument. The concern is a good one. I think conceptually "What is the value for this option" is more intuitive but less precise than "What is the value for this option's argument"? And yes, the value for a command will become more ambiguous with #310.

KathleenDollard · 2019-02-12T20:14:13Z

+
+namespace System.CommandLine.Binding
+{
+ public class ModelDescriptor


AppModels will need to set just some properties. I think this will be a need for some other cases as well. How would you pass the list of PropertyDescriptors to this class?

Do you mean set some properties that were not discovered via reflection?

KathleenDollard · 2019-02-12T20:24:52Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


People may be confused by this - properties now appear to have default values. Not sure if we can work with them.

This isn't intended to being limited the capabilities of reflection. The intention is to be able to annotate the model descriptor so that, for example, if you know that a given type behaviorally has a default, you can define that in the model.

KathleenDollard · 2019-02-12T21:31:23Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


Consider returning the type default instead of null.

Good catch.

jonsequitur · 2019-02-19T16:43:54Z

@dotnet-bot test Ubuntu16.04 Release

…cts to DragonFruit

jonsequitur · 2019-02-19T23:13:32Z

@dotnet-bot test Ubuntu16.04 Release

jonsequitur · 2019-02-09T15:43:01Z

This is attempt #3 at a generalized model binding infrastructure with lessons learned from the previous two iterations. If we think this is a good approach, this is intended to replace the following types and their related code:

TypeBinder
MethodBinder
ReflectionBinder

This is intended to address the following scenarios in a way that is flexible enough to be leveraged within app models, e.g. DragonFruit:

Binding input from various sources (ParseResult, service provider, arbitrary inputs such as environment variables, etc.) to arbitrary types (including constructor parameters, property setters, and handler parameters)
Binding in the absence of invocation
Easier testing of binding operations

It also shifts the code for building options based on a method signature, which DragonFruit uses, into System.CommandLine.DragonFruit. Some of this may later move under the app model work but as it's highly convention-based, we decided that it does not belong in the core library.

KathleenDollard · 2019-02-12T20:02:44Z

+ return GetValues(context, ConstructorDescriptor.ParameterDescriptors);
+ }
+
+ public object CreateInstance(BindingContext context)


Nit, consider GetInstance

Can you explain how you think about the distinction here?

On second look, Create is fine

KathleenDollard · 2019-02-12T20:06:48Z

+ new SpecificSymbolValueSource(option));
+ }
+
+ public void BindMemberFromCommand<TValue>(


Does this mean BindMemberFromArgument? How will a tight coupling between commands and arguments here work with multiple arguments? I do not believe people think about commands having values as much as having arguments.

Ignore the above because this isn't the place for it, but to clarify the confusion.
Our implementation is at odds with the ways I believe people think about the problem, and reflects an implementation detail. I do not believe people say "What's the value of that command?" Nor "What's the value of the argument on that option?" I think they would say "What's the value of the argument?" or "What's the value of the option?" and that is how Help seems laid out to me. I think this is going to be a rough cognitive load and reflects an implementation detail, and I know I will keep making this mistake whenever I am thinking about the real problem (the CLI).
But this has nothing to do with the problem we are trying to solve today.

It does mean bind from the argument. The concern is a good one. I think conceptually "What is the value for this option" is more intuitive but less precise than "What is the value for this option's argument"? And yes, the value for a command will become more ambiguous with #310.

KathleenDollard · 2019-02-12T20:14:13Z

+
+namespace System.CommandLine.Binding
+{
+ public class ModelDescriptor


AppModels will need to set just some properties. I think this will be a need for some other cases as well. How would you pass the list of PropertyDescriptors to this class?

Do you mean set some properties that were not discovered via reflection?

KathleenDollard · 2019-02-12T20:24:52Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


People may be confused by this - properties now appear to have default values. Not sure if we can work with them.

This isn't intended to being limited the capabilities of reflection. The intention is to be able to annotate the model descriptor so that, for example, if you know that a given type behaviorally has a default, you can define that in the model.

KathleenDollard · 2019-02-12T21:31:23Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


Consider returning the type default instead of null.

Good catch.

jonsequitur · 2019-02-19T16:43:54Z

@dotnet-bot test Ubuntu16.04 Release

…cts to DragonFruit

jonsequitur · 2019-02-19T23:13:32Z

@dotnet-bot test Ubuntu16.04 Release

jonsequitur · 2019-02-09T15:43:01Z

This is attempt #3 at a generalized model binding infrastructure with lessons learned from the previous two iterations. If we think this is a good approach, this is intended to replace the following types and their related code:

TypeBinder
MethodBinder
ReflectionBinder

This is intended to address the following scenarios in a way that is flexible enough to be leveraged within app models, e.g. DragonFruit:

Binding input from various sources (ParseResult, service provider, arbitrary inputs such as environment variables, etc.) to arbitrary types (including constructor parameters, property setters, and handler parameters)
Binding in the absence of invocation
Easier testing of binding operations

It also shifts the code for building options based on a method signature, which DragonFruit uses, into System.CommandLine.DragonFruit. Some of this may later move under the app model work but as it's highly convention-based, we decided that it does not belong in the core library.

KathleenDollard · 2019-02-12T20:02:44Z

+ return GetValues(context, ConstructorDescriptor.ParameterDescriptors);
+ }
+
+ public object CreateInstance(BindingContext context)


Nit, consider GetInstance

Can you explain how you think about the distinction here?

On second look, Create is fine

KathleenDollard · 2019-02-12T20:06:48Z

+ new SpecificSymbolValueSource(option));
+ }
+
+ public void BindMemberFromCommand<TValue>(


Does this mean BindMemberFromArgument? How will a tight coupling between commands and arguments here work with multiple arguments? I do not believe people think about commands having values as much as having arguments.

Ignore the above because this isn't the place for it, but to clarify the confusion.
Our implementation is at odds with the ways I believe people think about the problem, and reflects an implementation detail. I do not believe people say "What's the value of that command?" Nor "What's the value of the argument on that option?" I think they would say "What's the value of the argument?" or "What's the value of the option?" and that is how Help seems laid out to me. I think this is going to be a rough cognitive load and reflects an implementation detail, and I know I will keep making this mistake whenever I am thinking about the real problem (the CLI).
But this has nothing to do with the problem we are trying to solve today.

It does mean bind from the argument. The concern is a good one. I think conceptually "What is the value for this option" is more intuitive but less precise than "What is the value for this option's argument"? And yes, the value for a command will become more ambiguous with #310.

KathleenDollard · 2019-02-12T20:14:13Z

+
+namespace System.CommandLine.Binding
+{
+ public class ModelDescriptor


AppModels will need to set just some properties. I think this will be a need for some other cases as well. How would you pass the list of PropertyDescriptors to this class?

Do you mean set some properties that were not discovered via reflection?

KathleenDollard · 2019-02-12T20:24:52Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


People may be confused by this - properties now appear to have default values. Not sure if we can work with them.

This isn't intended to being limited the capabilities of reflection. The intention is to be able to annotate the model descriptor so that, for example, if you know that a given type behaviorally has a default, you can define that in the model.

KathleenDollard · 2019-02-12T21:31:23Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


Consider returning the type default instead of null.

Good catch.

jonsequitur · 2019-02-19T16:43:54Z

@dotnet-bot test Ubuntu16.04 Release

…cts to DragonFruit

jonsequitur · 2019-02-19T23:13:32Z

@dotnet-bot test Ubuntu16.04 Release

jonsequitur · 2019-02-09T15:43:01Z

This is attempt #3 at a generalized model binding infrastructure with lessons learned from the previous two iterations. If we think this is a good approach, this is intended to replace the following types and their related code:

TypeBinder
MethodBinder
ReflectionBinder

This is intended to address the following scenarios in a way that is flexible enough to be leveraged within app models, e.g. DragonFruit:

Binding input from various sources (ParseResult, service provider, arbitrary inputs such as environment variables, etc.) to arbitrary types (including constructor parameters, property setters, and handler parameters)
Binding in the absence of invocation
Easier testing of binding operations

It also shifts the code for building options based on a method signature, which DragonFruit uses, into System.CommandLine.DragonFruit. Some of this may later move under the app model work but as it's highly convention-based, we decided that it does not belong in the core library.

KathleenDollard · 2019-02-12T20:02:44Z

+ return GetValues(context, ConstructorDescriptor.ParameterDescriptors);
+ }
+
+ public object CreateInstance(BindingContext context)


Nit, consider GetInstance

Can you explain how you think about the distinction here?

On second look, Create is fine

KathleenDollard · 2019-02-12T20:06:48Z

+ new SpecificSymbolValueSource(option));
+ }
+
+ public void BindMemberFromCommand<TValue>(


Does this mean BindMemberFromArgument? How will a tight coupling between commands and arguments here work with multiple arguments? I do not believe people think about commands having values as much as having arguments.

Ignore the above because this isn't the place for it, but to clarify the confusion.
Our implementation is at odds with the ways I believe people think about the problem, and reflects an implementation detail. I do not believe people say "What's the value of that command?" Nor "What's the value of the argument on that option?" I think they would say "What's the value of the argument?" or "What's the value of the option?" and that is how Help seems laid out to me. I think this is going to be a rough cognitive load and reflects an implementation detail, and I know I will keep making this mistake whenever I am thinking about the real problem (the CLI).
But this has nothing to do with the problem we are trying to solve today.

It does mean bind from the argument. The concern is a good one. I think conceptually "What is the value for this option" is more intuitive but less precise than "What is the value for this option's argument"? And yes, the value for a command will become more ambiguous with #310.

KathleenDollard · 2019-02-12T20:14:13Z

+
+namespace System.CommandLine.Binding
+{
+ public class ModelDescriptor


AppModels will need to set just some properties. I think this will be a need for some other cases as well. How would you pass the list of PropertyDescriptors to this class?

Do you mean set some properties that were not discovered via reflection?

KathleenDollard · 2019-02-12T20:24:52Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


People may be confused by this - properties now appear to have default values. Not sure if we can work with them.

This isn't intended to being limited the capabilities of reflection. The intention is to be able to annotate the model descriptor so that, for example, if you know that a given type behaviorally has a default, you can define that in the model.

KathleenDollard · 2019-02-12T21:31:23Z

+
+ public bool HasDefaultValue => false;
+
+ public object GetDefaultValue() => null;


Consider returning the type default instead of null.

Good catch.

jonsequitur · 2019-02-19T16:43:54Z

@dotnet-bot test Ubuntu16.04 Release

…cts to DragonFruit

jonsequitur · 2019-02-19T23:13:32Z

@dotnet-bot test Ubuntu16.04 Release

R: move some tests into more specific namespaces
22fdb6c

jonsequitur force-pushed the decompose-ReflectionBinder branch from 928f0c0 to 22fdb6cCompare February 9, 2019 16:14

jonsequitur added 4 commits February 9, 2019 08:15

R: consolidate test models in one file
de893f4

R: remove FromKebabCase method
e3deb0b

R: rename some test models
cb4d7dd

R: add ParseResult.Parser and simplify some constructors
884f068

jonsequitur changed the title ~~[WIP] decompose binding~~[WIP] decomposed model bindingFeb 10, 2019

jonsequitur added 2 commits February 10, 2019 11:29

fixdotnet#395and re-enable test
657d31d

another model binding iteration
7db28e6

jonsequitur requested review from KathleenDollard and Keboo February 12, 2019 01:08

jonsequitur added 4 commits February 12, 2019 09:35

more ModelBinder tests, cleanup
2e6f78b

remove TypeBinder and ConstructorBinder
2fabf85

R: move SpecificSymbolValueSource to its own file
3107cfe

add support for binding from arbitrary sources using a delegate
37af44d

KathleenDollard reviewed Feb 12, 2019
View reviewed changes

address some PR comments
fdb2e43

jonsequitur force-pushed the decompose-ReflectionBinder branch from 853e3ed to 6eabddaCompare February 17, 2019 17:19

jonsequitur mentioned this pull request Feb 18, 2019
Hosting SOS under ClrMd for ELF dumps. dotnet/diagnostics#124
Merged

jonsequitur force-pushed the decompose-ReflectionBinder branch 3 times, most recently from 573c2ee to 0693638Compare February 19, 2019 15:09

jonsequitur force-pushed the decompose-ReflectionBinder branch from 0693638 to 87abf71Compare February 19, 2019 16:46

remove earlier binding implementations from core, move app model aspe…
10c374c
…cts to DragonFruit

jonsequitur force-pushed the decompose-ReflectionBinder branch from 87abf71 to 10c374cCompare February 19, 2019 20:17

jonsequitur changed the title ~~[WIP] decomposed model binding~~replace earlier binding infrastructureFeb 19, 2019

remove some HandlerDescriptor.From* methods
c838aa2

jonsequitur merged commit c9450cb into dotnet:masterFeb 20, 2019

jonsequitur deleted the decompose-ReflectionBinder branch May 20, 2019 15:45

R: move some tests into more specific namespaces
22fdb6c

jonsequitur force-pushed the decompose-ReflectionBinder branch from 928f0c0 to 22fdb6cCompare February 9, 2019 16:14

jonsequitur added 4 commits February 9, 2019 08:15

R: consolidate test models in one file
de893f4

R: remove FromKebabCase method
e3deb0b

R: rename some test models
cb4d7dd

R: add ParseResult.Parser and simplify some constructors
884f068

jonsequitur changed the title ~~[WIP] decompose binding~~[WIP] decomposed model bindingFeb 10, 2019

jonsequitur added 2 commits February 10, 2019 11:29

fixdotnet#395and re-enable test
657d31d

another model binding iteration
7db28e6

jonsequitur requested review from KathleenDollard and Keboo February 12, 2019 01:08

jonsequitur added 4 commits February 12, 2019 09:35

more ModelBinder tests, cleanup
2e6f78b

remove TypeBinder and ConstructorBinder
2fabf85

R: move SpecificSymbolValueSource to its own file
3107cfe

add support for binding from arbitrary sources using a delegate
37af44d

KathleenDollard reviewed Feb 12, 2019
View reviewed changes

address some PR comments
fdb2e43

jonsequitur force-pushed the decompose-ReflectionBinder branch from 853e3ed to 6eabddaCompare February 17, 2019 17:19

jonsequitur mentioned this pull request Feb 18, 2019
Hosting SOS under ClrMd for ELF dumps. dotnet/diagnostics#124
Merged

jonsequitur force-pushed the decompose-ReflectionBinder branch 3 times, most recently from 573c2ee to 0693638Compare February 19, 2019 15:09

jonsequitur force-pushed the decompose-ReflectionBinder branch from 0693638 to 87abf71Compare February 19, 2019 16:46

remove earlier binding implementations from core, move app model aspe…
10c374c
…cts to DragonFruit

jonsequitur force-pushed the decompose-ReflectionBinder branch from 87abf71 to 10c374cCompare February 19, 2019 20:17

jonsequitur changed the title ~~[WIP] decomposed model binding~~replace earlier binding infrastructureFeb 19, 2019

remove some HandlerDescriptor.From* methods
c838aa2

jonsequitur merged commit c9450cb into dotnet:masterFeb 20, 2019

jonsequitur deleted the decompose-ReflectionBinder branch May 20, 2019 15:45

R: move some tests into more specific namespaces
22fdb6c

jonsequitur force-pushed the decompose-ReflectionBinder branch from 928f0c0 to 22fdb6cCompare February 9, 2019 16:14

jonsequitur added 4 commits February 9, 2019 08:15

R: consolidate test models in one file
de893f4

R: remove FromKebabCase method
e3deb0b

R: rename some test models
cb4d7dd

R: add ParseResult.Parser and simplify some constructors
884f068

jonsequitur changed the title ~~[WIP] decompose binding~~[WIP] decomposed model bindingFeb 10, 2019

jonsequitur added 2 commits February 10, 2019 11:29

fixdotnet#395and re-enable test
657d31d

another model binding iteration
7db28e6

jonsequitur requested review from KathleenDollard and Keboo February 12, 2019 01:08

jonsequitur added 4 commits February 12, 2019 09:35

more ModelBinder tests, cleanup
2e6f78b

remove TypeBinder and ConstructorBinder
2fabf85

R: move SpecificSymbolValueSource to its own file
3107cfe

add support for binding from arbitrary sources using a delegate
37af44d

KathleenDollard reviewed Feb 12, 2019
View reviewed changes

address some PR comments
fdb2e43

jonsequitur force-pushed the decompose-ReflectionBinder branch from 853e3ed to 6eabddaCompare February 17, 2019 17:19

jonsequitur mentioned this pull request Feb 18, 2019
Hosting SOS under ClrMd for ELF dumps. dotnet/diagnostics#124
Merged

jonsequitur force-pushed the decompose-ReflectionBinder branch 3 times, most recently from 573c2ee to 0693638Compare February 19, 2019 15:09

jonsequitur force-pushed the decompose-ReflectionBinder branch from 0693638 to 87abf71Compare February 19, 2019 16:46

remove earlier binding implementations from core, move app model aspe…
10c374c
…cts to DragonFruit

jonsequitur force-pushed the decompose-ReflectionBinder branch from 87abf71 to 10c374cCompare February 19, 2019 20:17

jonsequitur changed the title ~~[WIP] decomposed model binding~~replace earlier binding infrastructureFeb 19, 2019

remove some HandlerDescriptor.From* methods
c838aa2

jonsequitur merged commit c9450cb into dotnet:masterFeb 20, 2019

jonsequitur deleted the decompose-ReflectionBinder branch May 20, 2019 15:45

R: move some tests into more specific namespaces
22fdb6c

jonsequitur force-pushed the decompose-ReflectionBinder branch from 928f0c0 to 22fdb6cCompare February 9, 2019 16:14

jonsequitur added 4 commits February 9, 2019 08:15

R: consolidate test models in one file
de893f4

R: remove FromKebabCase method
e3deb0b

R: rename some test models
cb4d7dd

R: add ParseResult.Parser and simplify some constructors
884f068

jonsequitur changed the title ~~[WIP] decompose binding~~[WIP] decomposed model bindingFeb 10, 2019

jonsequitur added 2 commits February 10, 2019 11:29

fixdotnet#395and re-enable test
657d31d

another model binding iteration
7db28e6

jonsequitur requested review from KathleenDollard and Keboo February 12, 2019 01:08

jonsequitur added 4 commits February 12, 2019 09:35

more ModelBinder tests, cleanup
2e6f78b

remove TypeBinder and ConstructorBinder
2fabf85

R: move SpecificSymbolValueSource to its own file
3107cfe

add support for binding from arbitrary sources using a delegate
37af44d

KathleenDollard reviewed Feb 12, 2019
View reviewed changes

address some PR comments
fdb2e43

jonsequitur force-pushed the decompose-ReflectionBinder branch from 853e3ed to 6eabddaCompare February 17, 2019 17:19

jonsequitur mentioned this pull request Feb 18, 2019
Hosting SOS under ClrMd for ELF dumps. dotnet/diagnostics#124
Merged

jonsequitur force-pushed the decompose-ReflectionBinder branch 3 times, most recently from 573c2ee to 0693638Compare February 19, 2019 15:09

jonsequitur force-pushed the decompose-ReflectionBinder branch from 0693638 to 87abf71Compare February 19, 2019 16:46

remove earlier binding implementations from core, move app model aspe…
10c374c
…cts to DragonFruit

jonsequitur force-pushed the decompose-ReflectionBinder branch from 87abf71 to 10c374cCompare February 19, 2019 20:17

jonsequitur changed the title ~~[WIP] decomposed model binding~~replace earlier binding infrastructureFeb 19, 2019

remove some HandlerDescriptor.From* methods
c838aa2

jonsequitur merged commit c9450cb into dotnet:masterFeb 20, 2019

jonsequitur deleted the decompose-ReflectionBinder branch May 20, 2019 15:45

R: move some tests into more specific namespaces
22fdb6c

jonsequitur force-pushed the decompose-ReflectionBinder branch from 928f0c0 to 22fdb6cCompare February 9, 2019 16:14

jonsequitur added 4 commits February 9, 2019 08:15

R: consolidate test models in one file
de893f4

R: remove FromKebabCase method
e3deb0b

R: rename some test models
cb4d7dd

R: add ParseResult.Parser and simplify some constructors
884f068

jonsequitur changed the title ~~[WIP] decompose binding~~[WIP] decomposed model bindingFeb 10, 2019

jonsequitur added 2 commits February 10, 2019 11:29

fixdotnet#395and re-enable test
657d31d

another model binding iteration
7db28e6

jonsequitur requested review from KathleenDollard and Keboo February 12, 2019 01:08

jonsequitur added 4 commits February 12, 2019 09:35

more ModelBinder tests, cleanup
2e6f78b

remove TypeBinder and ConstructorBinder
2fabf85

R: move SpecificSymbolValueSource to its own file
3107cfe

add support for binding from arbitrary sources using a delegate
37af44d

KathleenDollard reviewed Feb 12, 2019
View reviewed changes

address some PR comments
fdb2e43

jonsequitur force-pushed the decompose-ReflectionBinder branch from 853e3ed to 6eabddaCompare February 17, 2019 17:19

jonsequitur mentioned this pull request Feb 18, 2019
Hosting SOS under ClrMd for ELF dumps. dotnet/diagnostics#124
Merged

jonsequitur force-pushed the decompose-ReflectionBinder branch 3 times, most recently from 573c2ee to 0693638Compare February 19, 2019 15:09

jonsequitur force-pushed the decompose-ReflectionBinder branch from 0693638 to 87abf71Compare February 19, 2019 16:46

remove earlier binding implementations from core, move app model aspe…
10c374c
…cts to DragonFruit

jonsequitur force-pushed the decompose-ReflectionBinder branch from 87abf71 to 10c374cCompare February 19, 2019 20:17

jonsequitur changed the title ~~[WIP] decomposed model binding~~replace earlier binding infrastructureFeb 19, 2019

remove some HandlerDescriptor.From* methods
c838aa2

jonsequitur merged commit c9450cb into dotnet:masterFeb 20, 2019

jonsequitur deleted the decompose-ReflectionBinder branch May 20, 2019 15:45

R: move some tests into more specific namespaces
22fdb6c

jonsequitur force-pushed the decompose-ReflectionBinder branch from 928f0c0 to 22fdb6cCompare February 9, 2019 16:14

jonsequitur added 4 commits February 9, 2019 08:15

R: consolidate test models in one file
de893f4

R: remove FromKebabCase method
e3deb0b

R: rename some test models
cb4d7dd

R: add ParseResult.Parser and simplify some constructors
884f068

jonsequitur changed the title ~~[WIP] decompose binding~~[WIP] decomposed model bindingFeb 10, 2019

jonsequitur added 2 commits February 10, 2019 11:29

fixdotnet#395and re-enable test
657d31d

another model binding iteration
7db28e6

jonsequitur requested review from KathleenDollard and Keboo February 12, 2019 01:08

jonsequitur added 4 commits February 12, 2019 09:35

more ModelBinder tests, cleanup
2e6f78b

remove TypeBinder and ConstructorBinder
2fabf85

R: move SpecificSymbolValueSource to its own file
3107cfe

add support for binding from arbitrary sources using a delegate
37af44d

KathleenDollard reviewed Feb 12, 2019
View reviewed changes

address some PR comments
fdb2e43

jonsequitur force-pushed the decompose-ReflectionBinder branch from 853e3ed to 6eabddaCompare February 17, 2019 17:19

jonsequitur mentioned this pull request Feb 18, 2019
Hosting SOS under ClrMd for ELF dumps. dotnet/diagnostics#124
Merged

jonsequitur force-pushed the decompose-ReflectionBinder branch 3 times, most recently from 573c2ee to 0693638Compare February 19, 2019 15:09

jonsequitur force-pushed the decompose-ReflectionBinder branch from 0693638 to 87abf71Compare February 19, 2019 16:46

remove earlier binding implementations from core, move app model aspe…
10c374c
…cts to DragonFruit

jonsequitur force-pushed the decompose-ReflectionBinder branch from 87abf71 to 10c374cCompare February 19, 2019 20:17

jonsequitur changed the title ~~[WIP] decomposed model binding~~replace earlier binding infrastructureFeb 19, 2019

remove some HandlerDescriptor.From* methods
c838aa2

jonsequitur merged commit c9450cb into dotnet:masterFeb 20, 2019

jonsequitur deleted the decompose-ReflectionBinder branch May 20, 2019 15:45

R: move some tests into more specific namespaces
22fdb6c

jonsequitur force-pushed the decompose-ReflectionBinder branch from 928f0c0 to 22fdb6cCompare February 9, 2019 16:14

jonsequitur added 4 commits February 9, 2019 08:15

R: consolidate test models in one file
de893f4

R: remove FromKebabCase method
e3deb0b

R: rename some test models
cb4d7dd

R: add ParseResult.Parser and simplify some constructors
884f068

jonsequitur changed the title ~~[WIP] decompose binding~~[WIP] decomposed model bindingFeb 10, 2019

jonsequitur added 2 commits February 10, 2019 11:29

fixdotnet#395and re-enable test
657d31d

another model binding iteration
7db28e6

jonsequitur requested review from KathleenDollard and Keboo February 12, 2019 01:08

jonsequitur added 4 commits February 12, 2019 09:35

more ModelBinder tests, cleanup
2e6f78b

remove TypeBinder and ConstructorBinder
2fabf85

R: move SpecificSymbolValueSource to its own file
3107cfe

add support for binding from arbitrary sources using a delegate
37af44d

KathleenDollard reviewed Feb 12, 2019
View reviewed changes

address some PR comments
fdb2e43

jonsequitur force-pushed the decompose-ReflectionBinder branch from 853e3ed to 6eabddaCompare February 17, 2019 17:19

jonsequitur mentioned this pull request Feb 18, 2019
Hosting SOS under ClrMd for ELF dumps. dotnet/diagnostics#124
Merged

jonsequitur force-pushed the decompose-ReflectionBinder branch 3 times, most recently from 573c2ee to 0693638Compare February 19, 2019 15:09

jonsequitur force-pushed the decompose-ReflectionBinder branch from 0693638 to 87abf71Compare February 19, 2019 16:46

remove earlier binding implementations from core, move app model aspe…
10c374c
…cts to DragonFruit

jonsequitur force-pushed the decompose-ReflectionBinder branch from 87abf71 to 10c374cCompare February 19, 2019 20:17

jonsequitur changed the title ~~[WIP] decomposed model binding~~replace earlier binding infrastructureFeb 19, 2019

remove some HandlerDescriptor.From* methods
c838aa2

jonsequitur merged commit c9450cb into dotnet:masterFeb 20, 2019

jonsequitur deleted the decompose-ReflectionBinder branch May 20, 2019 15:45

R: move some tests into more specific namespaces
22fdb6c

jonsequitur force-pushed the decompose-ReflectionBinder branch from 928f0c0 to 22fdb6cCompare February 9, 2019 16:14

jonsequitur added 4 commits February 9, 2019 08:15

R: consolidate test models in one file
de893f4

R: remove FromKebabCase method
e3deb0b

R: rename some test models
cb4d7dd

R: add ParseResult.Parser and simplify some constructors
884f068

jonsequitur changed the title ~~[WIP] decompose binding~~[WIP] decomposed model bindingFeb 10, 2019

jonsequitur added 2 commits February 10, 2019 11:29

fixdotnet#395and re-enable test
657d31d

another model binding iteration
7db28e6

jonsequitur requested review from KathleenDollard and Keboo February 12, 2019 01:08

jonsequitur added 4 commits February 12, 2019 09:35

more ModelBinder tests, cleanup
2e6f78b

remove TypeBinder and ConstructorBinder
2fabf85

R: move SpecificSymbolValueSource to its own file
3107cfe

add support for binding from arbitrary sources using a delegate
37af44d

KathleenDollard reviewed Feb 12, 2019
View reviewed changes

address some PR comments
fdb2e43

jonsequitur force-pushed the decompose-ReflectionBinder branch from 853e3ed to 6eabddaCompare February 17, 2019 17:19

jonsequitur mentioned this pull request Feb 18, 2019
Hosting SOS under ClrMd for ELF dumps. dotnet/diagnostics#124
Merged

jonsequitur force-pushed the decompose-ReflectionBinder branch 3 times, most recently from 573c2ee to 0693638Compare February 19, 2019 15:09

jonsequitur force-pushed the decompose-ReflectionBinder branch from 0693638 to 87abf71Compare February 19, 2019 16:46

remove earlier binding implementations from core, move app model aspe…
10c374c
…cts to DragonFruit

jonsequitur force-pushed the decompose-ReflectionBinder branch from 87abf71 to 10c374cCompare February 19, 2019 20:17

jonsequitur changed the title ~~[WIP] decomposed model binding~~replace earlier binding infrastructureFeb 19, 2019

remove some HandlerDescriptor.From* methods
c838aa2

jonsequitur merged commit c9450cb into dotnet:masterFeb 20, 2019

jonsequitur deleted the decompose-ReflectionBinder branch May 20, 2019 15:45


		public bool HasDefaultValue => false;

		public object GetDefaultValue() => null;

Uh oh!

Conversation

jonsequitur commented Feb 9, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonsequitur commented Feb 19, 2019

Uh oh!

jonsequitur commented Feb 19, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jonsequitur commented Feb 9, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonsequitur commented Feb 9, 2019•
edited
Loading

jonsequitur commented Feb 9, 2019•
edited
Loading

jonsequitur commented Feb 9, 2019•
edited
Loading