I am always printing debug text. Like this:
30% of my bugs are this:
What if we overload the … operator to dump the table to a string and concatenate it?
This is becoming a common pattern in my code:
I am always printing debug text. Like this:
30% of my bugs are this:
What if we overload the … operator to dump the table to a string and concatenate it?
This is becoming a common pattern in my code:
What if you learned about tostring() ?
Or print(a,b,c) ?
Encoding it to some format… eh
tostring() not useful for tables.
Then make it useful.
print() uses getfenv(0).tostring to change non-strings into strings.
If you overwrite the tostring to turn tables into JSONEncode, print will do the same.
EDIT: @Shedletsky example:
local Http = game:GetService("HttpService")
local ts = tostring
local env = getfenv(0)
function env.tostring(val)
if type(val) == "table" then
return Http:JSONEncode(val)
end return ts(val)
end
print("A table:",{a="b"})
A table: {"a":"b"}
I’m talking about making the default behavior useful.
I’m not talking about whether it is possible to do it in a way that requires the scripter to understand the Lua internals.
Didn’t you already make a thread about formatting tables using tostring or something?
Yes. This is a new context where table dumping is useful and should be the default.
Wouldn’t you first want to finish the thread where we get a way to easily table dump?
This is a case where feature A is twice as useful if someone puts in a tiny bit more work and also does feature B.
So no.
Basicly, if they make tostring dump tables, it would automaticly change print too.
Only problem is: It might break some scripts in some weird way, as it would be highly unexpected.
I tend to just use print("dfghsdfghsdajhfjsadhafjkasdhfjk", somevalue);
.
Works with any number of params and any type of params. And works with warn
too.
You could also override print()
(in, say, a module) to dump tables and other values if applicable.
I’m not sure how I feel about this. My biggest argument against it would be that the way in which the table is represented as a string is an arbitrary choice then, which will make sense for some people but won’t for others.
From an intuitiveness standpoint, making the format as it is written in Lua (i.e. “{a = 1, b = 2}”) would be easiest to understand. However, from a practical point of view, you’d probably prefer a JSON representation if you actually do something with the concatenated string apart from printing it. But a JSON representation may be overly complicated or confusing to read for people who just script in Lua and don’t know about JSON.
That is opposed to tostring-ing numbers for example, there is not really any ambiguity in how to represent a decimal number in a string. For tables, that ambiguity would be there, that’s why I would be against it.
Moreover, how do you handle cycles in tables properly? Do you handle them in the first place or do you just give an error? There are a ton of arbitrary choices that don’t have clear arguments in favor/against them there.
It is not an overload on table, it is an overload on …
My post is about the fact that there is an arbitrary choice in the algorithm that will be used by … to turn the table into a string. It’s better to leave this up to the programmer who wants to print the table in my opinion.
With regard to formatting, it should actually probably be a format specific to Studio such that we could eventually build an interface for modifying the table in memory (like Visual Studio) and setting conditional breakpoints on values in the table.
If we changed … to have a special meaning for tables, it wouldn’t stop you from writing your own serialization it just makes the default more useful.
Could be a little strange for someone who already knows Lua but is new to ROBLOX. But it wouldn’t be the first language change.
I think if this is provided, an override for print() should also be provided. Maybe similar to how JavaScript does things.
And there’s another issue related to debugging that I think is important. If I accidentally concatenate a big table to something instead of a small number variable and don’t thoroughly check my code, I could run into some interesting errors or behaviour of my code later on that I have to trace back to the fact that I was trying to concatenate a table instead of what I wanted to concatenate. That wouldn’t occur when the error is there, because I’d realise my mistake instantly. I think that’s especially important for people who are new to scripting.
You constantly have this problem in Lua because Lua has no compile time type checking.