ID:2324140
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
The ability to override how a datum is represented when converted to a string.

This defaults to name if the var exists, or type if that exists, and the filename for the two cases where there isn't a name or a type, except for clients, as they use their ckey instead, and numbers use num2text(num,6).

While you can (and we do) set name to override this (even on datums, by just giving them a name var), in some cases such a value might be better calculated on read rather than try and keep name updated.

I'd love this feature for my integer library. While the name work around is possible in many cases, I consider it infeasible for pif_LongInt as this would end up requiring a bunch of division calls *every* time an operation occurs. Needless to say, if I want my library to remain fast this is not really an option.

As it stands, with the new operator overloading methods one can use my library nearly invisibly (i.e., like a built in number). Printing a string is one of two things where you have to use method calls explicitly for the library to work (the other being assignment). This would be a great feature to make it nicer to use.
I've been looking into this, and I think this is doable but with a caveat.

Currently object to text conversion is done by reading the name var if it exists. However, the same routine that grabs the name is also used when doing verb arguments. The client has to rely on the name var because it can't run a proc, so server-side command expansion has to use the name.

Essentially, the only way this is feasible is if the override call is only done when the object is embedded in a string, and every other case works like it did before. That would basically just end up being syntactic sugar and nothing more.

In your opinion, is this an acceptable compromise?
One of the uses I was thinking of for such a system was embedding debugging into about a things state to be displayed on runtimes. I'm not sure where that would lie on this compromise, but likely on the name var side.

That being said almost every other use case I can think of involves an explicit string embed.

The !FUN! parts would be raw outputting. file << datum or browse(datum) would likely use the type or name var when a programmer might expect it to use the string operator. You would need to carefully word the entry in the reference to properly manage expectations in that department.

In response to MrStonedOne
MrStonedOne wrote:
The !FUN! parts would be raw outputting. file << datum or browse(datum) would likely use the type or name var when a programmer might expect it to use the string operator. You would need to carefully word the entry in the reference to properly manage expectations in that department.

That's exactly my concern. When an object is output to the client, the client is just using the appearance data it already knows.
In response to Super Saiyan X
Super Saiyan X wrote:
http://www.byond.com/forum/?post=107443

rip ter13

Reason I marked it not feasible is because of inconsistencies in the existing implementation that would either require a total syntax overhaul, or a change to how labels are parsed based on the context of left/right operands in a number of operations.

Also the fact that operator overloading had been repeatedly marked "not feasible". With operator overloading, this is not very much in a realistic place.