|
You could start by READING THE NAME OF THE FORUM!
Sorry about the shouting, but it's been one of those days - and it's only 09:15...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Come on, take it easy, it's friday. Hear me? TAKE IT EASY 
Edit: Oh, come on, guys. I was just kidding... It's friday...
modified on Friday, December 17, 2010 11:54 AM
|
|
|
|
|
Hello All,
I found the need to use enumeration as indexer to simplify coding and just realized, I created bugs all over.
The situation is like this...
using System;
using System.Collections.ObjectModel;
namespace Demo
{
class Program
{
public enum AFormatType
{
None = 0,
ItemA = 1,
ItemB = 2,
ItemC = 3,
ItemD = 4,
}
public class AFormat
{
AFormatType _type;
public AFormat(AFormatType type) { _type = type; }
public AFormatType FormatType
{
get { return _type; }
}
}
public class AFormatCollection : Collection<AFormat>
{
public AFormat this[AFormatType type]
{
get
{
for (int i = 0; i < this.Count; i++)
{
AFormat format = base[i];
if (format.FormatType == type)
{
return format;
}
}
return null;
}
}
}
static void Main(string[] args)
{
AFormatCollection collFormats = new AFormatCollection();
collFormats.Add(new AFormat(AFormatType.ItemA));
collFormats.Add(new AFormat(AFormatType.ItemB));
collFormats.Add(new AFormat(AFormatType.ItemC));
collFormats.Add(new AFormat(AFormatType.ItemD));
AFormat testFormat = collFormats[0];
}
}
}
I was surprised to find that the testFormat is null. Is the C# enum nothing better than the C++? If the compiler considers this to be another this[int index], why did this compile successfully?
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
modified on Saturday, December 18, 2010 1:24 AM
|
|
|
|
|
0 is always legal when an enum is expected
From the C# language spec:
13.1.3 Implicit enumeration conversions
An implicit enumeration conversion permits the decimal-integer-literal 0 to be converted to any enum-type.
|
|
|
|
|
harold aptroot wrote: 0 is always legal when an enum is expected
I think that explains the issue, since the output of the ff. are the same: ItemC.
(NOTE: reversed the content)
static void Main(string[] args)
{
AFormatCollection collFormats = new AFormatCollection();
collFormats.Add(new AFormat(AFormatType.ItemD));
collFormats.Add(new AFormat(AFormatType.ItemC));
collFormats.Add(new AFormat(AFormatType.ItemA));
collFormats.Add(new AFormat(AFormatType.ItemB));
testFormat = collFormats[1];
if (testFormat != null)
{
Console.WriteLine(testFormat.FormatType.ToString());
}
testFormat = collFormats[AFormatType.ItemC];
if (testFormat != null)
{
Console.WriteLine(testFormat.FormatType.ToString());
}
}
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
You start with adding ItemA..ItemD to the list. Then you loop through the list, looking for item "None". That's done here;
for (int i = 0; i < this.Count; i++)
{
AFormat format = this[i];
if (format.FormatType == type)
{
return format;
}
}
return null;The first time it goes through that loop, format.FormatType = "ItemA", and type == "None". It'll continue with the loop, check "ItemD", and move on to the "return null" statement.
Try this code;
collFormats.Add(new AFormat(AFormatType.ItemA));
collFormats.Add(new AFormat(AFormatType.ItemB));
collFormats.Add(new AFormat(AFormatType.ItemC));
collFormats.Add(new AFormat(AFormatType.ItemD));
AFormat testFormat = collFormats[0];
collFormats.Add(new AFormat(AFormatType.None));
testFormat = collFormats[0];
Enjoy 
I are Troll 
|
|
|
|
|
I think you have missed the main point.
AFormatCollection : Collection<AFormat> is a collection and therefore supports the this[int index],
so the AFormat testFormat = collFormats[0]; is asking for the zero-indexed item.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
modified on Friday, December 17, 2010 6:03 AM
|
|
|
|
|
Paul Selormey wrote: so the AFormat testFormat = collFormats[0]; is asking for the zero-indexed item.
Ask your debugger;
for (int i = 0; i < this.Count; i++)
{
AFormat format = base[i];
if (format.FormatType == type)
{
return format;
}
}
return null;
Your indexer-implementation doesn't return anything based on index, it's returning the item that has the specified enumvalue. The debugger will loop through the collection, compare the type parameter from your indexer to the FormatType property. Since there's no item in the collection with a enumvalue None, null is returned.
It's not going to take the 0 as a hint that it should use the inherited indexer, it'll simply convert your 0 into the enums value for (int)0 and use the indexer that's specified for the enum.
I are Troll
|
|
|
|
|
Eddy Vluggen wrote: It's not going to take the 0 as a hint that it should use the inherited indexer, it'll simply convert your 0 into the enums value for (int)0 and use the indexer that's specified for the enum.
In which case it should also convert 1 to the enums value for (int)1, right? Try it.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
No, see my earlier comment. The conversion from int to enum is only implicit when the int is zero.
|
|
|
|
|
harold aptroot wrote: No, see my earlier comment.
Right, I am only implying that from his statements.
I have verified your earlier comment and it is valid, the only valid explanation to this issue.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Paul Selormey wrote: In which case it should also convert 1 to the enums value for (int)1, right? Try it.
You're right, the framework took the correct indexer 
I are Troll
|
|
|
|
|
As I know from OOP theory, the purpose of private Properties is to have the variables of an object protected from other classes, that could accidentaly change their value, thus provoking complications in a software. Am I correct till here?
Then I started to read C# and I found out that variables are called fields and they are also usually private. But there are also Properties with set and get which are used to change variables' (fields') values.
For instance:
I have a variable category in a class Myclass.
To follow strict C# grammar I write
private int cat;
and then I create a property with set and get
public int Category<br />
{<br />
get { return cat; }<br />
<br />
set { cat = value; }<br />
}
Therefore I can access the property from any other class using
Myobject.Category = 5
And here comes the question: why use such a complicated way? Why not use directly a public cat field? After all, cat is still not protected since I can directly change Category instead.
Thanks in advance for any reply.
|
|
|
|
|
|
Thanks for the links.
Still, it confuses me a bit, in the way that I have to give two different names in order to describe one object variable. like in the example above. The word 'Category' has a meaning for my class, but I am obliged to use a different word for the field, therefore I chose cat, but I find it poor in a semantic way.
Also, I am wondering if that is a Microsoft's "invention" or a general OOP thinking. Does it exist in Java too? I never met it in C++, MFC or other frameworks, nor in UML.
|
|
|
|
|
nstk wrote: The word 'Category' has a meaning for my class, but I am obliged to use a different word for the field, therefore I chose cat, but I find it poor in a semantic way.
Typically you will use Category for the property name and category or _category for the local variable name.
The same OO concept existed in C++ - it was simply a public method though. Properties are not necessary, it's just a new way of saying "public method that returns a value and keeps the value private." In C++ you'd simply write a public function, and some people even used the word "Get".
public int GetCategory()
{
return category;
}
public void SetCategory(int i)
{
category = i;
}
Same thing. However C# property offers you a convenient way of not even declaring the local variable! For example this works without even declaring your local variable called "cat".
public int Category
{
get;
set;
}
Again, this is for future use, where you have the option of changing how Category gets implemented (you can add a variable later, or write the get or set methods with some different code, but the caller would never need to know.) In the mean time, the compiler generates a local variable under the covers for you.
|
|
|
|
|
Let me give you the strong need of property in C#.
Suppose there's one field <code>CustomerID and you have assigned CustomerIDProperty to get and set values for CustomerID.
Now After a years requirements being changed and They say they need some validation on CustomerID now you can not change or not advisable to put a check of CustomerID everywhere in the code, At that time you can simply put check at set method of CustomerIDProperty to be rescued.
Property is introduced because of the changing requirement in software field.
"Walking on water and devloping a software both are the easy things,Provided both FROZEN".
|
|
|
|
|
Hiren Solanki wrote: Let me give you the strong need of property in C#.
...
Property is introduced because of the changing requirement in software field.
Property was introduced just as a convenience, not because of any need. The change requirement could easily be implemented with normal methods as in C++. It's a quicker way to code for the developer, it's a quicker way to call for the consumer (no parentheses required), offers an auto-generation option, and signifies intent of the developer with fewer comments (a property is used when there is little calculation and no side effects). None of these are necessary though.
|
|
|
|
|
Also that Interfaces can specify properties, but not fields.
|
|
|
|
|
It also gives hints at what to look for when reflecting through an object. IE Some asp.net data grids will auto bind columns to all properties of an object.
|
|
|
|
|
kevinnicol wrote: Some asp.net data grids will auto bind columns to all properties of an object.
That's true and good point, but that's a .NET issue that wasn't applicable to C++.
modified on Friday, December 17, 2010 2:40 PM
|
|
|
|
|
oops, thought I was in the C# forums, must have stumbled into the C++ forums by accident.
|
|
|
|
|
kevinnicol wrote: oops, thought I was in the C# forums, must have stumbled into the C++ forums by accident
The point is to answer in context of the OP's questions, and if you had taken the time you spent on your clever sarcasm and spent it on reading all the OP's posts instead, you'd know he was coming from an OO background from C++. So I think you need to decide if you want to help someone with a question in context, or if you want to show off your mad skilz 
The OP said "I am wondering if that is a Microsoft's "invention" or a general OOP thinking. I never met it in C++." By way of my response to you, I was telling him that data grid data binding with properties is a Microsoft-specific invention for C#/.NET, and not general OOP thinking. I replied to your post to help him and the lurkers, not educate you.
But as a token of goodwill, I'm still willing to educate you. You misused "IE" in your previous post. You might want to look that one up.
|
|
|
|
|
There was no sarcasm intended, I just saw your reply in my email and truly thought I had made a reply in the wrong forum. There was no intent of sarcasm or showing of my "mad skilz". I will choose to take your token of goodwill as that and not passive aggression; in the future will use eg. instead of ie. in those cases. Thanks.
|
|
|
|
|
kevinnicol wrote: There was no sarcasm intended
Oh sorry, my bad!  Since you already know about e.g., you're ahead of 90% of the people out there....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
