[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Error handling and Exception with an iterator.
- From: "szbnwer@..." <szbnwer@...>
- Date: Fri, 7 Sep 2018 01:30:37 +0000
hi there! :)
Il giorno gio 6 set 2018 alle ore 20:50 Dirk Laurie
<dirk.laurie@gmail.com> ha scritto:
[...]
> iterator = lfs.dir()
> while true do
> local f = pcall(iterator)
> if not p then break end
> ...
> end
and in addition, one can make something like this, in case of need:
for x in
(function(...) -- some minor description
-- your ad-hoc hack
-- this can be started to be resolved from `return
originalFunctionThatYouWantedToHack()` just the way that Dirk
suggested
end)( --[[param for the iter]] )
do -- for
-- whatever
end
i already needed this 2 times, as this was a bit of a standalone
function, but the "hacked" iterator would be meaningless in itself,
otherwise id make the ad-hoc fun' a freestanding function.
the 1st appearance was a line iter where i could have nothing, a
string, or one or more files as a target for the iteration. more files
had to be assembled as they were one for the loop. :D the 2nd is for
ordering, like getting an array for key order or just a string for
ascending/descending or nothing for default.
i think it is ugly a bit, but works great, as its the least complexity
and garbage for lua, and always on the right place for using upvalues,
just as well for the codeflow, but the latter could take comments for
the beginning of the ad-hoc function, as the calling gonna be much
below with probably some enlightening input, and for the `do` as its
not a simple do-end block, just to make it a bit prettier and
foolproof :D
btw i think languages with control(param){block} syntax just cant be
as pretty as lua when `for x in longStuff do` and `if soManyConditions
then˙ are broken like i did above... :D
have fun, and all the bests for both of u! :)