It's an interface to a forward reading state machine who's final implementation is left up to the author. The whole "internal list" concept is an illusion.
I like the analogy of a finite state machine, even if that ... for my students ... is an advanced concept that would probably distract them. i'd rephrase that as: "forward reading finite iteration machine."
"list ... illusion:" trying to prevent the student from assuming there is an internal list is a priority when i teach.
"custom tokenizers:" interesting ... i assume you mean 'Select based IEnumerables.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Tsk tsk... that type reaction is IMO simply a reflection on an inability to grok the underlying complexity; not on the information and/or its relevance and/or its accuracy. It was after-all intended to provide an indication of the complexity underlying the architecting of Linq.
Ps. Plus my response was to you, not the student -- a good teacher would be able to gauge the level of their audience and adjust the presentation of a complex topic to match that.
Tsk tsk... that type reaction is IMO simply a reflection on an inability to grok
Tsk tsk...That reply suggests one or more of the following
1. You did not read the original post
2. You didn't care what the original post asked.
3. You don't understand the context of what student might mean in the original post.
Yes; first off IEnumerable was Microsoft implementation of functional programming algebras for a List. It is essentially a monadic data type that encapsulates List; monadic data types are typically designed to conform to a fairly standard set of functional algebras i.e. providing a common API for computations.
Err..no it wasn't.
IEnumerable existed long before linq. It wasn't added to the libraries in any way shape or form to support functional programming.
Now one could make an argument that they should have started from scratch when they did add linq but that is an argument and not a statement of fact.
One could also argue that they should have redid IEnumerable to support linq. However that argument would have been completely wrong since C# was a practical language not a university exercise. Redoing it would have broken the entire existing body of practical work that was using it. And would have been exactly the wrong thing to do for any language when attempting to enhance and not replace that language.
Extension methods... apparently so obvious that you missed it.
Apparently you do not know what you said...
"first off IEnumerable was Microsoft implementation of functional programming algebras for a List. "
And again, no it was not. It existed long before anything associated with functional programming was in the language.
Refutation of that statement has nothing to do with extension methods which were added long after IEnumerable. I can only suppose that you are claiming that they could have used extension methods when implementing linq. Perhaps. But still that has nothing to do with your original incorrect statement.
Let's review the opening paragraph's of the OP's post.
Imagine you have bright young student sitting down with you, whom you've introduced to Linq, and generics ... and, they've had no problems mastering 'Select and 'Where, 'Aggregate, etc.
You have introduced them to the use of 'yield return' in a method to return an IEnumerable they can turn into an instance of a collection. They "get that," and get use of yield means they can skip direct assignment to a pre-defined, initialized collection, or, a collection instance reference passed in as an 'out parameter.
And you are trying to explain to them the "deferred iteration/evaluation" aspect of IEnumerable, and the way that enables some advanced practices (function chaining).
To make it a little easier to grasp for those too easily confused by many words, and / or a greater context than just one singled out by one bit of syntax, namely IEnumerable.
The questions were contextual... which apparently you missed completely. Why else would the second question be about deferred evaluation aka lazy evaluation, contextually similar the third question; the fourth question, fifth question, and finally the sixth question.
Contextually it would be rather silly to focus only on the very rudimentary interface definition of IEnumerable when none of the questions related to that... they all were if you missed it related to the behavior of extension methods of IEnumerable.
Ps. if you find the functional programming confusing just say so... as opposed to engaging in an awkward and rather pointless debate; where you clearly had missed the context that was put forward in the OP's post, and similarly the context implied by the questions.
I hope someone can help me on this problem. i have a database (accdb) from access that i want to filter by several comboboxes.
1 st combobox filter row 1 (BaseM)
2nd combobox filters row 2 (Umat) based on the results from the first combobox.
3rd combobox filter row 3 (Gmat) based on combobox 2
I think the solution is to use the same method for the SelectedIndex event in all three combo boxes. Then, regardless of which combo box is changed, the same method will fire. Upon firing, the method should construct a Filter string based on all three selections.
Incidentally, you can use interpolated string syntax for easier coding and reading.
It's true that Access has a limited implementation of SQL, but I don't think you need SQL to do the filtering itself.
If I understand correctly, you have a database with columns BaseM, Umat, and Gmat. You have a DataGridView that displays the rows from this database, and you have combo boxes holding the unique, valid values for each of the mentioned columns. You would like the DataGridView to display only the rows that contain the values selected in the combo boxes.
If that is so, I would load all the rows from the database into the the dataset using SQL (basic select query), and I would then set the binding source's filter to a string that included all three combo box selections. I had mentioned using just one event handler for all three combo boxes. Something like this?
The current working directory when you run Launcher must be one level above Data for the relative path to be valid. But if you start in C:\TesterV4 then Data\Tests\Manufacturer\Data\anything.pdf will not be found because its actual location is further down the directory tree. You should use absolute paths, or preferably use the OpenFileDialog to ensure you get what the user wants.
To add to what Richard says, you shouldn;t be storing data in folders below that containing the app EXE file - normally this would be under Program Files, and all folders there are protected to reduce virus activity.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
Last Visit: 31-Dec-99 19:00 Last Update: 1-Dec-23 7:41