Coding Tutorial: The C# foreach loop works on any standard collection, but what do we need to do to make it work on collections we've written for ourselves? Source code available at: github.com/Jas...
Anything else you want to know? Just ask. Download the source code at github.com/JasperKent/Implementing-IEnumerable Keep up to date by subscribing: th-cam.com/channels/qWQzlUDdllnLmtgfSgYTCA.html
It took me 2 hours trying to figure out what the non-generic version implementation is until I came across your video, thank you thank you thank you!!!
I highly admire your level of understanding with the topic and what a beautiful way to present all those concepts in a precise way. Thank you so much for making and sharing this gold with the community.
Great info, one question, is it possible to apply to enums? Or apply this pattern to a class with no backing collection, but be able to enumerate through its fields? For example i have a class with a lot of const string fields(100+), and i want to be able to enumerate them.
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: th-cam.com/video/X975bFJvTfY/w-d-xo.html. The class of strings is a bit different, so I'll put together a video for that.
So using: " _somevariable.Count " does not iterate via IEnumerable under the hood ? If "_somevariable.Count " does not iterate fully in first place, why i couldnt set .Count as condition in a for-loop and be same memory efficient ? Im new to C#.
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.
that seems like so much work for something so basic. having an extra class in there (bookenumerator) just for that is really unsatisfying. and then the historic non-generic version. i just want to provide the next element and eventually reset and it ends in all this boilerplate and clutter. is there no simplistic solution to this simple functionality?
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?
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.
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.
Anything else you want to know? Just ask.
Download the source code at github.com/JasperKent/Implementing-IEnumerable
Keep up to date by subscribing: th-cam.com/channels/qWQzlUDdllnLmtgfSgYTCA.html
It took me 2 hours trying to figure out what the non-generic version implementation is until I came across your video, thank you thank you thank you!!!
I highly admire your level of understanding with the topic and what a beautiful way to present all those concepts in a precise way. Thank you so much for making and sharing this gold with the community.
Tne most complete explanation of the IEnumerable interface on the internet!
brilliant video.Must see and try if Enumerable is giving you any issue
Mr Kent You are amazing . I never thought I could find such a video anywhere . TY
That some in depth explanation. I never got that before.
Best of video about ienum ... You cover all things about it ... Thank you so much
I was expecting a KFC promotion.
Dope tutorial. Thanks man
Very good explanations, keep up the good work!
Safed my day thnx mate.
Beautiful.
good insight into the Ienumerable,. thank you sir
My pleasure.
Thank you very much sir, that was reaaallly helpful!
Great job!
Great info, one question, is it possible to apply to enums? Or apply this pattern to a class with no backing collection, but be able to enumerate through its fields? For example i have a class with a lot of const string fields(100+), and i want to be able to enumerate them.
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: th-cam.com/video/X975bFJvTfY/w-d-xo.html. The class of strings is a bit different, so I'll put together a video for that.
The new video is up now: th-cam.com/video/jkdHqGRJBU4/w-d-xo.html
Thanks a lot
Great content, thanks!
So using: " _somevariable.Count " does not iterate via IEnumerable under the hood ? If "_somevariable.Count " does not iterate fully in first place, why i couldnt set .Count as condition in a for-loop and be same memory efficient ? Im new to C#.
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.
Nice video! Thank you!
Glad you liked it!
that seems like so much work for something so basic. having an extra class in there (bookenumerator) just for that is really unsatisfying. and then the historic non-generic version.
i just want to provide the next element and eventually reset and it ends in all this boilerplate and clutter. is there no simplistic solution to this simple functionality?
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?
Wonderful!
Cheers! :)
Nice video. But why do we need Ienumerable at all ? All the work is done by Ienumerator. Ienumerable does not do anything other return Ienumerator.
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.
Can i just make the list public so i can acces it in the foreach loop ?
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.
well selling chicken isn't his only hobby
I'd never have imagined that Colonel Sanders would sound like me when he opens his mouth.
you are very confusing, because u jumping from one thing to onother
Sorry.