lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


On 16/02/2012 12:19 PM, Tim Hill wrote:

others can critique it (or ignore it!) as they wish...


I've been away trying to get some actual work done, but I'll bite now:


1. Generality. Library routines should apply to as many problem domains
as possible. So no adding home mortgage functions to the math library,
for example.


Sounds good. This rules out things like XML and JSON libraries.



2. Non-Triviality. Routines that can be written in 5-10 lines of Lua
code don't seem good candidates to me.
Giving repeated idioms names can be a good thing, even if they're only one or a few lines of code. It's about abstraction -- the power is in the abstraction expressing intent and being easier to read than obscure incantations that "do the same thing" but rely on understanding arcana to understand. A raw example (from C) would be using XOR operations to swap variables instead of a swap() function. Both are valid, in different contexts. 



The example earlier of a "set()"
function to create a set from a table (migrate array values to keys)
seems to me to fall into that category. [If you go down this road you
end up with developers really just stringing together dozens of calls to
runtime functions, with the result that the code no longer looks like
Lua and the underlying operation is all but lost in the mess.]


Who cares what the underlying operation is?
The whole point of programming with abtract data types is that they are abstracted from the problem domain. If the inliner is good then it won't matter which version you type.
If I want a Set data type I want to perform operations such as s:contains(x) and s:intersection_with(y) -- operations that we all understand from the abstract language of Sets. I'd much prefer to string together calls like this than know how to get the same results directly with a Lua table (keep in mind the Set example may not be the perfect example for this). 



3. Performance. Some things are hard to code efficiently in Lua, and
routines that handle heavy lifting in C do make some sense.
You'd need to elaborate to clarify what you have in mind here. Are General, Non-trivial things that are missing from Lua core? 



4. Abstraction. Some operations are inherently platform-dependent in
their implementation, even if they can be exposed through a standard
interface. [Lua does pretty well on this, but it does inherit some of
the failures in this regard of the underlying C runtime (the format of
paths passed to the file open functions comes to mind).]


File paths fail your generality test in my view.
The beauty of Lua is that it doesn't impose arbitrary abstractions of it's own making to any domain other than computation. 



[As an aside, imho adding lots of library routines can lead to AWFUL
code. First off, inexperienced developers can get lost amongst a huge
sea of library routines, fail to find the "ideal" routine and end up
writing the code themselves anyway (or worse, bending the wrong routine
to the task). Second, inexperienced developers often treat library
routines as "magic", particularly when it comes to performance, and end
up writing slow code and then blaming the runtime library for not being
instantaneous. The bloated Java and .Net libraries are examples of this.]
I'm not sure inexperienced developers behavior need to be taken into account. Better to look at what experienced developers do and how to support them do it more consistently. 

Ross









--Tim



On Feb 15, 2012, at 2:28 AM, Dirk Laurie wrote:


Op 14 februari 2012 03:17 schreef Jay Carlson <nop@nop.com
<mailto:nop@nop.com>> het volgende:


    Let me give some examples. Maybe it's the whole list, or even a
    superset. Feel free to say, "I never use that" or "I never use
    that and I can't see why anybody would". Or say "using a library
    function for that would be just as verbose as inlining it." Don't
    feel free to say,"that's trivial". The more trivial something is,
    the more likely we agree on how it works. I am so tired of
    writing/pasting these trivial functions, and looking for what
    they're called in other people's code.

When looking through your list, I often find that I use something like
it — but seldom exactly the same. I've sampled one case below.

You can skip the rest of this post if you like, since I'm not
soliciting constructive criticism of my conventions. My point is only
that the fact that you do it your way and I do it my way is an
argument in favour of not enshrining either in a `standard` library.

Dirk

    Shallow-copy a table. I'd use a shallow merge-copy too.


I use this more versatile function. Shallow-copy has `{}` and
shallow-merge has
the destination table as third argument.

function util.import(from,items,to)
-- import(from,nil,to) copies everything; can be used as shallow table
copy
-- import(from,items,_ENV) copies items to current environment
-- import(from,items) copies items to global environment
-- import(from) copies everything to global environment
-- import(from,foo) replaces foo by a new table if foo is not a table
-- import("name") copies from require "name"
-- if `items` has only one item, it need not be put into a table
-- all versions return the table `to`
to = to or _G or getfenv() -- specified or Lua 5.2 or Lua 5.1
-- FAQ: Why make _G the default, not _ENV?
-- Ans: Otherwise in interactive mode nothing happens past the current
line.