|
|
|
I will only note that based on a vast array of language requests that I have seen over the years that you might want to at least discuss it with a few people first just to insure that
- It is feasible
- Usable to a large number of people
- Not already existing
|
|
|
|
|
|
You could easily achieve the same code through the use of a code snippet.
|
|
|
|
|
|
I think you're mixing a lot of concerns in your code there. In general language changes should be autonomous with clearly defined boundaries that prevent the possibility of unwanted edge cases creeping in. As it is, you are asking them to introduce features to satisfy problems that could be easily avoided without mixing concerns - yes, you are mixing concerns here. Let's take your MyInt32Property sample and look at it in a different way.
This satisfies your DRY principle concerns at a stroke. Now, one of the examples you give is age. As age can be a complex object, containing rules about what constitutes a valid age, you would probably want to make this a class as well:<pre lang="c#">public class Age : PositiveInt32Value
{
protected override void ValidateValue(int value)
{
base.ValidateValue(value);
if (value < 18) throw new ArgumentException("You are way too young to be using this site");
if (value > 900) throw new ArgumentException("Who do you think you are? A Time Lord?");
}
}
|
|
|
|
|
Thank you for sharing reply.
Indeed, I implement like yours in current C# version.
But I encounter a some problem in this implementation.
1.I must change many place if I insert OnPropertyChanged method call in your Value property.(If a class has many propeties like Value1,Value2,Value3...ect)
2.A littel bit redundant code block.
It is more short.
property PositiveInt32ValuProperty Int32 Value;
My idea is superior to current implementation in at least these 2 point.
If you have some idea to solve these problems, I greatly appreciate if you show it to us.
>autonomous with clearly defined boundaries
I think my idea is enough to be autonomous.
My idea is "We can define property implementation and use it in class definition"
That all.
Property template solve a lot of problem (around INPC,Validation,redundancy...etc) with autonomous feature.
Higty
modified 27-Mar-14 21:57pm.
|
|
|
|
|
Higty wrote: I must change many place if I insert OnPropertyChanged method call in your Value property.(If a class has many propeties like Value1,Value2,Value3...ect)
Why would you need to insert the call in many places? Make it part of the underlying class and bind to that, and I have no idea what you mean about your redundant code block. If you implemented the functionality in my version you could have something like this:
public Age Age = new Age();
public PositiveInt32Balance DaysSinceSomeEvent = new PositiveInt32Balance();
Age.Value = -2; Note that I could have implemented these as either a field OR a property. It doesn't matter.
|
|
|
|
|
>Why would you need to insert the call in many places? Make it part of the underlying class and bind to that
Because I could not determine all things in the future.
Think about such case.
I implement like this because I don't need INPC interface at first.
I don't want to implement unnecessary code to fire OnPropertyChanged because simply I don't need it.
public int Value
{
get { return _value; }
set { _value = value; }
}
That ok in current requirement.
But some business requirement is changed, now I need to fire PropertyChanged event.
(Or other example, I must add validation before or after the code "_value = value".)
You can create a property like this at first.
public int Value
{
get { return _value; }
set
{
OnPropertyChanging(value);
ValidatingValue(value);
_value = value;
ValidatedValue(value);
OnPropertyChanged(value);
}
}
But it is unnecessary who don't use INPC or validation.
And it cause a little bit performance cost.(Even though, probably it can be ignorable in many case...)
Can you determine all of what you need in the future?
I could not see all thing in the future.
Best design could be changed by requirement.
My idea easily solve these situation by changing one line of code.(DRY principle)
Redundant means the current implementation
public int Value
{
get { return _value; }
set
{
ValidateValue(value);
_value = value;
}
}
More simple and less code
property PositiveInt32ValuProperty Int32 Value;
How do you think of?
modified 27-Mar-14 21:56pm.
|
|
|
|
|
I'm sorry, but I really don't like the sound of what you're proposing. What happens if I want to have only a protected setter? As I said, you have to be able to cater for edge cases with a change to the language. And if you're going the step to have a class in your property then what do you actually gain over what I showed you?
By the way, you might want to remove your email address if you don't want to be inundated with spam.
|
|
|
|
|
Ok, I know that you don't like it.
It's fine.
I'm not interest in what you like or not.
I just want to know concrete advantage or disadvantage.
And I changed my signature.
Thank you for your recomendation.
regards.
Higty
|
|
|
|
|
Higty wrote: I'm not interest in what you like or not.
That really doesn't ring true since you spent so long trying to convince me that it was a good proposal. As for concrete disadvantage, I don't know how many different ways I can tell you that it must cover edge cases, and this doesn't. As I said, what happens if I want a protected or a private setter?
|
|
|
|
|
Excuse me, I could not figure out "a protected or a private setter" what you said.
Higty
|
|
|
|
|
public int MyProperty { get; private set; }
|
|
|
|
|
It is a case that has no advantage with property template feature.
It looks that you are completely missing a point.
Higty
|
|
|
|
|
No, I'm not missing the point. I am not the thundering moron you seem to think I am. The example I showed you was just to clarify what a differently scoped setter or getter was as you did not seem to understand what the term meant. Having the setter with a different scope is a fairly common approach where you want to control access to setting the value - and your syntax does not take this into account. This is what I have been talking about all along - that a feature has to be able to cope with edge cases and common usage patterns. I give up debating it with you - it's over to the compiler team but I can pretty much guarantee you that they won't include it because you haven't shown how to cope with these cases and they do not add features if there can be side effects.
|
|
|
|
|
>Having the setter with a different scope is a fairly common approach
Of course.It is absolutely common usage patterns as you say.
My idea for different scoped getter,setter is
public property T MyReadOnlyProperty
{
get
{
return field;
}
private set
{
field = value;
}
}
public class Person
{
property MyReadOnlyProperty Int32 Age;
}
I showed a concept at Here[^].
Even though it didn't show in the detail, but developer who has good sense can be grasp a point of this feature.
I think that it is premature to show entire the detail spec.
Language team may be glad to see a concept or idea that inspire them not the entire detail of feature spec.
I know there are so many things under the foot to achieve only single language feature.
Once they grasp concept they can implement it with solving other many issue(Intellisense,backward compatibility...etc) to achieve it.
Because they have much more knowledge of C# than me.
Of cource it must be valuable to implement.
In this case, the results same to your above sample shown below.
public class Person
{
public int MyProperty { get; private set; }
}
So, there are no advantage or disadvantage by using property template with this case.
You can use property template or use current language feature.
Maybe I use current language feature.
>as you did not seem to understand what the term meant.
Paul, please don't be critical, please don't talk about whether I understand or not, please talk about a feature, design problem, a question of this feature.
regards.
Higty
|
|
|
|
|
Code snippets and other IDE magic are working around language deficiencies, and are generally 'write helpers' rather than things that help a reader or modifier of the code (i.e. 90% of interactions with the code).
I do feel that there's a missing language feature in this area but I'm not sure it's quite been nailed here. What would solve the INPC and validation scenarios would be
class SomeClass : INotifyPropertyChanged {
public int Value { get; set; beforeset ValidateValue; afterset Notify; }
public string Description { get; set; afterset Notify; }
private int ValidateValue(string property, int value) { ... }
private void Notify<T>(string property, T value) {
}
}
'beforeset' and 'afterset' would take a method reference or a lambda matching Func<string, T, T> and Action<string, T> respectively where T is the property type, so beforeset methods can update the value if needed, and both methods get given the property name if they want to use it for data binding, INPC notifications or error messages.
The compiler could insert the relevant calls into the auto-generated property method very easily.
|
|
|
|
|
This whole discussion seems to be arguing for C/C++ macros (albeit in a limited context).
|
|
|
|
|
The fact that you're trying to shoehorn items like validation in on the item does tend to indicate that the item should probably be encapsulated. I know that we all tend to let things like this through, but the idea that we've moved from having a simple value to something that has actual logic does suggest that we should be encapsulating that item (if we adopt a pure SOLID approach). Yes, there would be an additional level of indirection in the code, but the actual logic of the change would be encapsulated. I give an example of an Age class above to illustrate my point.
|
|
|
|
|
I do see the point but I think that when your validation is range checking or something equally simple it's overkill to create a class for it. Every class increases the complexity of the system and makes it harder to understand, and creating a whole class for a single if condition is adding (imo) more confusion than having the validation in place.
|
|
|
|
|
In this particular case, I really wish that .NET provided AOP as a first class citizen. A lot of this would go away if we could weave in things seamlessly. That, to me, is the feature that's missing.
|
|
|
|
|
AOP is a more general mechanism to do this kind of thing. I'm on the fence about it though, it is arguably too far down the road towards magic, because you see an attribute and you really have no idea what it's doing if there is potentially AOP code from referenced assemblies in play.
I think I'd rather see specific language features to make it simple to deal with the 90% case, even if at some point AOP becomes available as well at a later time.
|
|
|
|
|
BobJanova wrote: it is arguably too far down the road towards magic
It be voodoo dude  . If, however, they made it obvious that it was an AOP attribute rather than a general attribute, this would help - say use |AOPAttribute| as opposed to [OrdinaryAttribute].
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
