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.
ID:2324140
 Dec 11 2017, 9:43 pm
|
|||||||
Resolved
| |||||||
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. | |
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. | |
Super Saiyan X wrote:
http://www.byond.com/forum/?post=107443 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. | |
any update on this being allowed now?
i'd really love to change the default sigfigs | |
Bump
| |
Lummox JR resolved issue with message:
A special proc called operator"" can be defined for objects, altering how they get converted to text when embedded in a string via brackets. It is important to note this will NOT affect how the object is seen by clients. | |
rip ter13