-
Notifications
You must be signed in to change notification settings - Fork 33
capitalization convention #19
Comments
Capitalization seems so subtle that I'm not surprised people ignored that rule. |
Maybe we should have some other convention then. It seems like the most sensible thing at the time since we need to have an iterator type to do lazy iteration anyway and those are capitalized. |
|
lazymap?
|
I personally like the capitalization convention. Kevin On Thursday, February 27, 2014, Jacob Quinn [email protected]
|
I'm not saying I agree, but should we close the door on, doing same later: Nim (formerly Nimrod): "The reality is that Nimrod is case insensitive and that's one of the best thing Nimrod has." [they also are agnostic to CamelCase vs camel_case..] |
One possibility is to have functions always return iterators when called on iterator objects, and provide a function (e.g., |
Once upon a time (truth be told, I can't find the email thread), it was decided that lowercase iterator functions would all be eager, while the corresponding uppercase name would be an Iterator object, which is thus lazy. After this was resolved and agreed to, it was immediately ignored, so we have kind of a free-for-all going on. I still think that was a good idea. Thus,
Map(f,itr)
would produce aMap
iterator that does mapping lazily, whereasmap(f,itr)
is equivalent tocollect(Map(f,itr))
, but can of course be more efficient. Most iterators in this package define a type for lazy iteration and then immediately define a function that just constructs the type, thus constructing a lazy iterator. Of course, for many of the iterators in this package, it isn't even sensible to evaluate them eagerly. In any case, it would be nice to have some consistent convention about eager versus lazy iterator evaluation.The text was updated successfully, but these errors were encountered: