Implementing IEnumerable 

My pleasure.

Glad you liked it!

Cheers! :)

There are ways to do both of those, but they are a bit tricky, so I'll do another video rather than try to explain here. If all goes to plan, I'll post it next Thursday.

Actually, I realized that I've already done this for enums here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-X975bFJvTfY.html. The class of strings is a bit different, so I'll put together a video for that.

The new video is up now: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-jkdHqGRJBU4.html

You hardly ever need to do this. In most cases you just expose the enumerator of the private collection. I've never written an enumerator for myself in commercial code.

@@CodingTutorialsAreGolet me just say I'm amazed at your reply speed, thumbs up is well deserved, thank you for your work. I have a class with an array of lists at its center (my attempt at a custom hashmap). I implemented an indexer for the class and now my plan was to implement ienumerable. that would probably be one of those cases where i would have to write my own enumerator, no?

Good question. For a collection which has a Count property, then writing a regular for-loop is not really any different in terms of functionality or efficiency from writing a foreach-loop. However, the foreach-loop syntax tends to be easier (once you're used to it). Plus, the foreach-loop works on any collection that implements IEnumerable, whereas the for-loop has the additional requirement of having a Count.

Good question. The problem with making the list public would be (depending on circumstances) that you give the client code *too* much access. They'd to able to add to it as well as merely read it. One alternative is to give them public access but only through the IReadonlyCollection interface, which does as the name suggests.

@@CodingTutorialsAreGobut to me accessing books by Libray[idx] doesn’t make sense. Realistically, a library could have many properties like name, location, hours, employees, etc.

Fair point. I think regarding a library as a collection of books is a reasonable default, but you're right; it could equally be regarded as a collection of Employees. There are various ways round that, but my instinct would be to use interfaces, so class Library : IEnumerable, IEnumerable {...} and then use explicit interface implementation to distinguish the two. If you want to use and indexer, you'd have to find another interface that includes the indexer, but indexers are so rarely used, I doubt it's worth the bother. You get ElementAt() for free as an extension to IEnumerable.

To an extent, you are right. foreach does not require the collection to implement IEnumerable, merely to have a method GetEnumerator which returns an IEnumerator. But more generally in C#, it is not enough for an object to have a method, it must declare in a standardized way that it has the method - and that's done through an interface. Thus IEnumerable declares that a class has GetEnumerator without the need for any more detailed checks.

@@CodingTutorialsAreGo Isnt this an unnecessary hoop to jump thru ? Since the object in your example uses a list, why doesnt the compiler make our lives easy and just realise that it already has a getenumerator ? Just because the list is in an oject shouldnt matter. The information is already there. If someone wanted to define a new one for their new container all well and good. Couldnt it all be "under the hood".

@@youtischia It could be done like that, but it's not the way languages like C# go. The problem would be that if you just happened to write a method called GetEnumerator that was nothing to do with this feature (unlikely in this case, but highly possible with interfaces in general) then the system would pick it up anyway. The idea is that the developer declares the behaviour they want, the compiler doesn't assume it.

I'd never have imagined that Colonel Sanders would sound like me when he opens his mouth.

Sorry.