Thanks for your comments everyone. I'll stick with return.
On 13/04/12 22:12, Petr Bena wrote:
> I have no knowledge of Lua, but I don't see what is problem with print
> here, the function print is supposed to print output to output device
> in most of programming languages, just as in this case,
On Sun, Apr 15, 2012 at 5:40 PM, Marcin Cieslak wrote:
>>> Trevor Parscal wrote:
>> +1 to all the points for using return values.
>
> Zope has a nice solution here:
>
> print "Asdsds"
>
> prints actually to the internal magic variable "printed"
> which has to be returned later with
>
> return
>> Trevor Parscal wrote:
> +1 to all the points for using return values.
Zope has a nice solution here:
print "Asdsds"
prints actually to the internal magic variable "printed"
which has to be returned later with
return printed
if it's going to end up as the function result.
Not sure i
On 13/04/12 22:19, Petr Bena wrote:
> Tim, is there any code publicly available for the new extension you
> talk about? I would like to see it, if it exist (and isn't anything
> secret).
Yes, it is the Scribunto extension in Git. You can get the latest
version with:
git clone https://gerrit.wikim
On 14/04/12 00:19, Gabriel Wicke wrote:
> I am no Lua expert, but would guess that the usual
> collect-in-list-and--finally-join method can avoid the performance
> penalty in Lua too.
Yes, it works. With short strings, the memory overhead of the table
elements can become excessive, so it makes sen
+1 for only supporting return values. The case where one needs
thousands of string concats is pretty rare and can be worked around,
and seems like the only reasonable argument in favour of using print.
One exit point per function is much easier to read than juggling
possible scattered print statem
On 13/04/12 19:18, Rob Lanphier wrote:
> I imagine there's going to be a lot of cut-and-paste going on, so
> if we can establish best practices early (keeping a close eye on how it's
> being used), we can introduce some good genetic stock into future Lua
> scripts.
Imagine my shock when I first re
On Fri, Apr 13, 2012 at 7:19 AM, Gabriel Wicke wrote:
> From a language perspective, I would much prefer return values instead
> of side effects, even if those side effects could be converted into a
> return value with a special print implementation.
>
I think I agree with Gabriel here (and look
+1 to all the points for using return values.
If we have to implement an output buffer in Lua, we have probably
failed. Output buffering is is messy and prone to error. It's certainly not
a good design from a usability standpoint, and it's generally messy to deal
with.
Template invocations should
On 13/04/12 16:19, Gabriel Wicke wrote:
>> Does anyone have any thoughts on return versus print generally? Are
>> there other reasons we would choose one over the other?
>
> From a language perspective, I would much prefer return values instead
> of side effects, even if those side effects could b
On 13.04.2012 16:12, Petr Bena wrote:
I have no knowledge of Lua, but I don't see what is problem with print
here, the function print is supposed to print output to output device
in most of programming languages, just as in this case, so I don't
understand why we should want to use return (which
On Fri, Apr 13, 2012 at 09:45:52PM +1000, Tim Starling wrote:
>
> Does anyone have any thoughts on return versus print generally?
If you do go with the print solution, someone will eventually request
something along the lines of PHP's output buffering functions[1] so they
don't have to rewrite fu
> Does anyone have any thoughts on return versus print generally? Are
> there other reasons we would choose one over the other?
>From a language perspective, I would much prefer return values instead
of side effects, even if those side effects could be converted into a
return value with a special
On 13 April 2012 13:45, Tim Starling wrote:
> At the moment, in the Lua support extension we have been developing,
> wikitext is output to the wiki via the return value of a function. For
> example in wikitext you would have:
>
> {{#invoke:MyModule|myFunction}}
>
> Then in [[Module:MyModule]]:
>
On 13 April 2012 13:12, Petr Bena wrote:
> I have no knowledge of Lua, but I don't see what is problem with print
> here, the function print is supposed to print output to output device
> in most of programming languages, just as in this case, so I don't
> understand why we should want to use ret
Tim, is there any code publicly available for the new extension you
talk about? I would like to see it, if it exist (and isn't anything
secret).
On Fri, Apr 13, 2012 at 2:12 PM, Petr Bena wrote:
> I have no knowledge of Lua, but I don't see what is problem with print
> here, the function print is
I have no knowledge of Lua, but I don't see what is problem with print
here, the function print is supposed to print output to output device
in most of programming languages, just as in this case, so I don't
understand why we should want to use return (which is supposed to
return some data / pointe
17 matches
Mail list logo
