print("Hey this is my debug message " … print(table))
is uglier than
print("Hey this is my debug message " … table)
I guess
print(“Hey this is my debug message”, table) is ok. But if you want to add newlines it is annoying.
But to you point about weirdness, maybe the thing to do is to create a new print function called something like “debug_print” (only hopefully more terse) that does its damnest to turn anything you try to print into a human readable string.
This would be very useful, I hate this limitation on concatenation.
Honestly, at first I thought “this guy is crazy, what sort of nonsense is this stupid request?”
Then I begin to think broader. What came to mind was Google Chrome’s “log()” function. I provide this as an example to demonstrate @Shedletsky’s point.
However, I strongly am against what he is proposing. Instead, I suggest a more procedural, and easier to understand why it differs from standalone Lua mechanics, function added to the table library.
table.stringify()
That way it can be given optional stringify’able parameters as needed, or a callback function as to what to do with specific data. However, the default behavior should be as shown in my image above.
In all reality, one could just JSONEncode the table; but for some reason a stringify() functions sits better with me.
Since Lua is not typed, I would like to not think about types when I am coding.
If I need to remember to stringify my table variables then I need to think about types and I will continue to get errors unless I remember to do this when I print().
Basically the only thing I want to think about is the problem I am trying to solve. This other stuff adds cognitive load and makes my code uglier.
If you really need something like this built in for you to properly debug your games, you are doing something wrong.
There has never been a case for me where I’ve needed to convert a table to a string to show it in the output.
Can you be more specific on what you’re trying to debug? I could probably offer a better design-plan as far as the general Roblox game design structure goes.
You need to look away from web-related programming aspects, Roblox development is much different.
I am saving tables in DataStore and I want to print them to see what is being saved.
Alright, I guess it would be handy to have this.
However, there are very limited use-cases for this in my opinion.
Why should you need to verify what the contents of your tables are, if you are the one who wrote to it in the first place? You shouldn’t need to worry so much about displaying debug information, rather you should worry about what you are submitting in the first place, so that you can design a system that is ready to approach it. There’s nothing wrong with getting your hands dirty with the API to get personalized results that you want.
Thats just my two cents on the specific situation.
Ultimately I don’t have any problem with this being suggested, but at the same time, there are better things that ROBLOX could be focusing on than tiny little nit-pick things like this.
So to paraphrase your advice is to not have bugs that need debugging.
What I am proposing is probably a five liner in C++ land given a dump function for tables exists.
Oh, actually I meant more of just
print("Here's my table")
print(someTable)
Sure, if thats how you want to phrase it.
Design it in a predictable specific manner to begin with, so you don’t have to expect bugs to happen.
Yeah, I’m sure its easy. If its not in the engine by the time I’m an intern, I’ll toss it in there for you.
Heres the thing thats kinda getting to me though. You worked at Roblox for almost 8 years, and yet you never even thought about implementing this into the code?
I feel like your lack of memory isn’t Lua’s problem 
A table in Lua is a bit more of an abstract data type, saying we should allow it is like saying we should concatenate a coroutine.
Why should I need to verify what my code does, if I’m the one who wrote it in the first place? There’s such a thing as bugs in which behavior you intended does not turn out the way you intended it to be. You, a high school student, have a lot of gall telling a professional programmer to “just write code so there aren’t any bugs in the first place!” Just today I’ve used a custom printTable function on three separate occasions (different bugs) to find out what was going wrong with tables.
The first was that I was trying to add two tables together, but for some reason decided to check if the value existed in the other table before adding it. I printed the table out in its entirety to quickly figure out what I was doing wrong.
The second was that we were trying to check why settings[regionName] was returning nil, and printed out the table, and found that I had defined the regions as {region1, region2, region3} instead of {region1=true, region2=true, etc) which wasn’t apparently obvious due to how the settings were generated
The third was that I was trying to figure out why certain things weren’t being added to a custom TargetFilter module and I found out I was adding a table instead of the contents.
All of those would have been painful to debug without seeing the table at glance. You not having found a need to print out tables for debugging purposes does not mean it is not useful to other people.
From a general perspective, yeah, I can understand why this is wanted, and I have no issue with it. I’m not trying to down-play the idea of this feature, as I said in the post you quoted me on… I’m just analyzing Shedletsky’s situation specifically, and I’m trying to offer him a better means of approaching the debugging of this issue, because that seems to be the reason why hes suggesting it in the first place.
The only good reasoning I’ve seen on this thread against making … work with tables is that it’s inconsistent with what Lua normally does. I like Shedletsky’s debug print idea, that just tries to do whatever it can to print out what it’s given.
The first step in debugging is to understand what the bug is causing. Without printing out the table, you can’t fully understand what’s going wrong. Is table.Health nil because it got overwritten? Is table.Health nil because you made a typo? Is table.Health nil because it somehow got nested in a different table? The quickest way to find that out is printing out the table.
no way d00d
I think you meant tostring()
You could use a metatable with the __concat field to make it be formatted as a string when …'ed.
That would be nice to have indeed.
That would be nice to have too indeed.
And all this because doing something as simple as overwriting print/warn/tostring very quickly isn’t fun.
y u do dis