|
Hello everyone,
I am wondering why do we need to derive some type from IEnumerator<T>? Could anyone show me some useful samples?
I think using IEnumerator<T> itself should be enough in all cases?
thanks in advance,
George
|
|
|
|
|
Well, when to derive or just use the interface is according your context. If using IEnumerator is enough, you needn't derive from it. But sometimes, your class has its own responsebilities besides IEnumerator. So you will implement this interface.
|
|
|
|
|
Thanks adamzhang,
I can understand this point, such as the derived class may have some special rules for MoveNext. 
But my confusion is how to initialize and create an instance of such derived class? Could you show a sample with some pseudo code please?
regards,
George
|
|
|
|
|
I'm sorry, but the term you are looking for is not derive. It's implement. There is a whole world of difference in OO terms.
|
|
|
|
|
Sorry, it is my mistake to use the wrong word. My confusion is how to implement a class, which implements IEnumerator<t>, especially how to write the constructor, any ideas or samples?
regards,
George
|
|
|
|
|
In most cases you dont need to do that.
read up on the "yield return" keyword, that will generate a ienumerable<t> for you
|
|
|
|
|
Thanks Roger,
I have found great samples by using yield.
regards,
George
|
|
|
|
|
Hello everyone,
New to C#, a simple question which my book does not cover.
If we do not specify the public/private access of get/set, then it is of the same as the public/private access to the property itself, but we can overwrite it.
For example, in the following code, in get method, when we do not specify public/private, it will be automatically the same as the property Abc, which makes get public, but in set, we can overwrite it to make it private?
public class MyList
{
class Foo
{
private int _abc;
public int Abc
{
get
{
return _abc;
}
private set
{
_abc = value;
}
}
}
static void Main()
{
Foo f = new Foo();
return;
}
}
thanks in advance,
George
|
|
|
|
|
Properties by their nature are public accessors for private/protected variables.
If you don't want an external object to be able to set a property, don't provide a set function. That makes it read-only from the calling object.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
What do you mean "public accessors for private/protected variables.", John? Default are public to property, set and get?
regards,
George
|
|
|
|
|
If you don't want to provide set method, just cut it off from property field, no need to put private accessor in front.
|
|
|
|
|
Thanks adamzhang,
Good point. 
regards,
George
|
|
|
|
|
True if you're using a backing field, but if you're using automatic properties en 3.0/3.5, you'll need a private set for it to work.
class WithAutomaticProperties {
public String NoBackingField { get; private set; }
}
class WithBackingField {
private string backing;
public String HasBackingField { get { return backing; } }
}
Scott P
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
|
|
|
|
|
|
George_George wrote: What means "use an accessor to implement an interface"? Does it mean implement an accessor in a class which (the accessor) is declared in an interface?
Exactly.
|
|
|
|
|
Thanks Rob,
Another confusion from this document is "You cannot use accessor modifiers on an interface or an explicit interface member implementation".
http://msdn.microsoft.com/en-us/library/75e8y5dd(VS.80).aspx[^]
"cannot use accessor modifiers on an interface" means can not use accessor modifiers like public/private on interface accessor declaration or on some class's accessor which implements the interface's accessor?
regards,
George
|
|
|
|
|
"
When you use an accessor to implement an interface, the accessor may not have an access modifier. However, if you implement the interface using one accessor, such as get, the other accessor can have an access modifier.
"
Everything specified by an interface is public and you can't change that. (That's the meaning of "interface".)
When an interface specifies a property, it must specify at least one accessor. If the interface specifies only one, you can't modify the accessibiity of that accessor, but you may implement the other accessor and choose to make it non-public.
|
|
|
|
|
Great PIEBALDconsult!
But why it is "may not have an access modifier"? It should be must not, agree?
regards,
George
|
|
|
|
|
George_George wrote: It should be must not,
Indeed.
|
|
|
|
|
Thanks PIEBALDconsult,
But when we implement a property's accessor in a class, and not using explicit interface implementation, we can use access modifiers. Right?
Here is my code, correct?
interface IFoo
{
int abc
{
get;
}
}
class Foo : IFoo
{
private int _abc;
public int abc
{
get
{
return _abc;
}
private set
{
_abc = value;
}
}
}
regards,
George
|
|
|
|
|
|
Sorry PIEBALDconsult,
I made a mistake. I think when we implement an accessor defined in an interface, whether or not using explicit implementation in the class, we can not add any modifiers.
But if in the interface, only one accessor is defined for a property, we can add modifier to the other accessor of the property (as shown in my above sample).
Any comments? Agree or?
regards,
George
|
|
|
|
|
Ummm, yeah, the "explicit" doesn't matter.
|
|
|
|
|
Thanks for your confirmation, PIEBALDconsult!
regards,
George
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
