std should collect api functions that are not specific to a given module #68

Activity

1. gvvaughan

   added this to the v41This milestone has been deleted milestone on Jul 17, 2014
2. gvvaughan

   added

   enhancement

   on Jul 17, 2014
3. gvvaughan

   self-assigned this

   on Jul 17, 2014
4. gvvaughan

   changed the title [-]std.lua contains language features that are not specific to a given module[/-] [+]std.lua should contain language features that are not specific to a given module[/+] on Jul 17, 2014
5. gvvaughan commented on Jul 21, 2014

   

   gvvaughan

   on Jul 21, 2014

   ContributorAuthor

   More actions

   I've decided that I will deprecate the superfluous object method variants of iterators.

   So far I've collected elems, pairs, ielems, ipairs and ripairs into a new std.lua module. If we have ripairs I should probably also add rielems, though I'm strongly leaning towards replacing ripairs with the more composable ireverse, which would eliminate the need for std.list.reverse and make implementation of ripairs and rielems trivial one-liners:

   local ripairs = func.compose (lua.ireverse, lua.ipairs)
   local rielems = func.compose (lua.ireverse, lua.ielems)

   I'll take care to respect __ipairs on Lua 5.1 with ireverse too. Which, in turn, makes the (IMHO) ill-conceived totable/__totable idioms redundant. Writing a complex object that behaves like a raw table (by hiding or generating some key/value pairs, say) can be achieved with existing machinery: i.e. __ipairs or __pairs.
6. gvvaughan commented on Jul 21, 2014

   

   gvvaughan

   on Jul 21, 2014

   ContributorAuthor

   More actions

   Now that I think about it, std.lua should be an implementation detail, and its functions should be exported from std for a more pleasant api:

   local std     = require "std"
   local ripairs = std.functional.compose (std.ireverse, std.ipairs)

   (Of course std.monkey_patch will scribble these into the global namespace as necessary)
7. gvvaughan commented on Jul 25, 2014

   

   gvvaughan

   on Jul 25, 2014

   ContributorAuthor

   More actions

   All but finished.

   In the vein of collecting high-level functions into the top-level std namespace, now, I just need to figure out what to do with the type vs. prototype mess I created: Ideally, a single std.type function would be the only api, taking the place of std.object.prototype and variants -- however, it's often useful to be able to recognize a primitive table, whether or not it happens to also have a _type field.

   Possibly, an optional second :primitive argument would fix those kinds of issues, and I'm sure by the time I implement #62, that will become a spurious stop-gap that can be removed... except that I'll have already used it all over the place by then and cleaning up will be a big time waster.

   Alternatively, I could close this issue, and leave a pointer to it in #62, fully expecting it to come out in the wash by then without any more code churn.

   Thoughts?
8. gvvaughan

   changed the title [-]std.lua should contain language features that are not specific to a given module[/-] [+]`std` should contain language features that are not specific to a given module[/+] on Jul 25, 2014
9. gvvaughan

   changed the title [-]`std` should contain language features that are not specific to a given module[/-] [+]`std` should collect api functions that are not specific to a given module[/+] on Jul 25, 2014
10. gvvaughan

    closed this as completedon Aug 5, 2014
11. gvvaughan

    removed

    in progress

    on Aug 5, 2014