I am *very* surprised at the fact that C# does not support parameterized property!
The only thing I get is the so-called Indexer, but that does not provide the same functionality as parameterized property.
For example, I can write the following code in VB:
Public Class test
Property Name(ByVal key As String) As String
Get
Return key
End Get
Set(ByVal value As String)
End Set
End Property
Property Address(ByVal key As String) As String
Get
Return key
End Get
Set(ByVal value As String)
End Set
End Property
End Class
The two properties both have a String parameter and both return a String object. However, in C# I can only write only *ONE* indexer:
public string this[string key] { get { return key; } set { } } |
There is no other way to declare another indexer that accepts a string parameter and returns a string object.
I always think C# is the successor of C/C++ in terms of power and expression. But it seems I am wrong.
What is the background of this design Why C# cannot provide the same good language struct as VB
Parametersized property!?
Timmy0614
it is not such an important feature, but fo COM backward compatability it is.
for example I want a COM interface for my .net class and I just can't do it without wrapping my c# object in an object written in another language
SaintAnger
Its not all that surprising. I'm not sure of the official reason, but there are quite a number of complications that named indexers bring to the table, and its pretty easy to emulate anyway.
If SomeClass had an indexer that took a string as a parameter and returned a string, you could do this:
public class Test {
private SomeClass _names = new SomeClass();
private SomeClass _addresses = new SomeClass();
public string Name {
return _names;
}
public string Address {
return _address;
}
}
From the callers perspective, one uses the class just as if Name and Address were parameterized properties:
Test test = new Test();
test.Name["MyName"].ToString();
My guess is that VB's syntax was just better suited for supporting parameterized properties. C# is very powerful, and I would use it over VB any day. But, there are things that VB is better at than C#. Anyone who has ever tried to write an MS Office extension in C# knowns this.
I, too, was distressed when I leanred that C# does not support parameterized properties. However, over time I have found them only to be minimally usefull. In the last 3-4 years since I started using C#, I can only think of one time where it really would have been helpful to use them. For everything else, I've used collections or my own custom class with an indexer, and it often works out better than if I had used a parameterized property.
PBrall
Think of the power of C/C++. Can you think of anything that C/C++ CANNOT do that other similar languages can do
Yes, tuples, parameter widening and return type narrowing in derived classes, all of which are supported in Eiffel. There is also lamda functions, which will be supported in C# 3.0. There are plently others I could probably think of if given enough time.
You have to realize that designers of a language have a lot of goals they have to balance. C++ is a great language, but too complicated for many programmers to learn and use effectively. It takes 10+ years for you to truely master C++ in all its complexities and intricacies. I'm not even sure there is a compiler that fully implements the C++ specification (maybe gcc, but there always seem to be some obscure piece of the sepc that wasn't implemented correctly). VB was designed as an alternative that is much easier to learn and use. However, it proved to be very limited in some ways, and lead to a lot of bad programming practices (IMHO). C# (and I suppose VB.NET) does a very good job of bridging that gap of being both very powerful and relatively easy to learn and use. With C# 3.0, C# will have a ton of new features that can hardly be dreamed of in C++.
As I've already demonstrated in my first post, indexers can be used to emulate parameterized properties in virtually any situation, and IMO it usually works as well if not better that way. If you want to criticize C# for a feature that is hardly needed, I guess thats you're right. But, I think you're throwing the baby out with the bath water.
Helio D
Woyler
I agree with you. It is supprising that this feature is not supported.
but - for property get you can just define a method that gets parameters and get the same behaviour
for set you cannot do it.
blitz_beck
It may have something to do with the differences in binding rules. Because of the differences in the syntax at the call site between VB abd C#, VB can disambiguate members based on return types whereas C# cannot. Also, C# has different design goals in mind than VB. They may have just decided that parameterized properties weren't worth the added complexity to the syntax, since it a feature that isn't needed often and could potentially hieghten the barrier of entry for programmers unfamiliar with C#. Many developers have also asked for an abbreviated syntax for properties, which MS admits COULD be done, but for every solution they tried, they found the disadvantages outweighted the advantages of such a syntax change.
ESTAN
I know this kind of 'complaint' never ends with something useful. They always have an excuse for not implementing an eays-to-implement thing.
End of this thread. Do not reply.
kenniejaydavis
Think of C++ and the complexity of multiple inheritance. Stroustrup did it however...
Think of the power of C/C++. Can you think of anything that C/C++ CANNOT do that other similar languages can do
The only thing in my mind is that if you program in C/C++, you don't need other languages. C# is very disapointing from the beginning, though my post is several years late (because m$ did not have this forum yet then).
Thoug property is only conceptual, but I want parameterized property in syntax; I do not want methods as a workaround.