|
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].
|
|
|
|
|
Hi.
Thank you for your reply.
I think your idea must be supported by Framework too.
Higty
|
|
|
|
|
Hello,
I don't know, is it secure to send windows password via netNamedPipeBinding to WCF service running on windows service? Hence, I request your thoughts on this and here is the scenario
We are asking the user to enter the windows user name and password from client application and sending them to WCF service(without explicit encryption) since the service need to interact with network mapped drive but currently we are not sure whether .net takes care of encrypting the user name and password and sends it via pipe or not.
About service details,
1. It uses the netNamedPipeBinding because we wanted this to be within machine level scope
2. Security mode set to mode="Transport" inthe config file
3. Transport protectionLevel set to protectionLevel="EncryptAndSign" inthe config file
4. There is no app.config at client side but creating object by passing "NetNamedPipeSecurityMode.Transport" "new NetNamedPipeBinding(NetNamedPipeSecurityMode.Transport)"
5. The machine where the wcf service is hosted may or may not be connected to internet
Is these enough? Or should I use explicit encryption? If explicit encryption required then, how to do?
Thanks, Sudhakar
|
|
|
|
|
Best way to check is to get a diagnostic tool and see what's actually sent across the pipe. If you're interacting with a WCF service over a non-secure channel then it's probably going by plain text.
However if you're on a single machine then it may not matter – if someone bad has access to the machine then you've got more problems than how your app handles data locally.
Probably best not to use your email as your display name, you'll get lots of spam if you publish your email like that.
|
|
|
|
|
I am creating a setup and deployment project in visual studio 2010. I need some custom action to be performed. I added an user interface with a text box that will accept the mail ID from user during installation and check from the database whether the mail id already exists in my user table.
Please help me.
|
|
|
|
|
AshwiniSH wrote: Please help me.
With what, you have not asked a question?
|
|
|
|
|
Sorry.
In my setup project, I want to add an user interface with a text box that will accept the mail ID from user during installation and check from the database whether the mail id already exists in my user table.
|
|
|
|
|
And what is the problem with doing that? Will the setup program have access to the database?
|
|
|
|
|
I created a setup project in VS2010 and added a user interface selecting a text box field. The user interface is appearing during installation. I want to validate the input entered in the text box. How can I do this?
Where should I check this?
Please help me in how to validate the fields.
In VS2012, Install shield Limited edition I did not find how to add user interface also.
|
|
|
|
|
AshwiniSH wrote: Where should I check this?
Presumably you will capture the input and validate it against some values that you have in your code.
|
|
|
|
|
Yes the input will be provided during installation (Say username), I want to validate this. Where should I write code to check this validation?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
