Controlling object concatenation.

ID:107443
 
Jan 22 2011, 4:23 pm (Edited on Jan 23 2011, 9:06 am)
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
Simple request...

Would it be possible to give users access to a function that controls the result of concatenation of objects to strings? The current method seems to be that, for non-atoms, it displays their type, and for atoms, it displays their name (with the improper macro, I believe). I do a lot of customization of how things are presented to the user, and I think being able to adjust the default display of said objects would be significantly simpler than using object.show() or object.display() every time I want to show the "correct" data.

This is more for convenience than anything else...

datum
 proc
  to_text()
   return "[type]"

atom
 to_text()
  return "\improper[name]"


And then later:
mob
 var
  title
  first_name
  middle_name
  last_name

 to_text()
  if(title)       . += title
  if(first_name)  . += (. ? " " : null) + first_name
  if(middle_name) . += (. ? " " : null) + middle_name
  if(last_name)   . += (. ? " " : null) + last_name

 Greg
  title = "Dr."
  first_name = "Gregory"
  last_name = "House"

// ...
var/mob/mob = new /mob/Greg
world << "[mob] is super cool." // "Dr. Gregory House is super cool."


It can also act as a standard function to change how to present the objects, to make life a little easier.

mob
 to_text(show_title=TRUE, show_first_name=TRUE, show_middle_name=TRUE, show_last_name=TRUE) // I'd use flags for this, but to show it a little bit easier...
  if(show_title && title)             . += title
  if(show_first_name && first_name)   . += (. ? " " : null) + first_name
  if(show_middle_name && middle_name) . += (. ? " " : null) + middle_name
  if(show_last_name && last_name)     . += (. ? " " : null) + last_name

// ...

var/mob/mob = new /mob/Greg
world << mob.to_text(show_first_name=FALSE, show_middle_name=FALSE) // "Dr. House". more "respectful?"


Other than this, it could be customized to provide more in-depth information on other types...

client
 to_text()
  return "client:[key]@[address || "DAEMON"]"


And you know, all that jazz.
#1 Jan 23 2011, 8:06 pm
http://www.byond.com/members/Forumaccount?skip=14#tostring
Not exactly in the feature tracker, but the feature tracker is probably not even read.
Though I'd love for less features and faster processing speed, which opens up flexibility completely by itself.
Hopefully BYOND'll have actual improvements after the upcoming flash client's out and away, which should be getting along better when/if the new website's finished.
#2 Jan 24 2011, 8:53 am
While I can see this being useful, there are two problems: 1) It's relatively easy, albeit not fun, to work around. 2) This would add to the complexity of the output process and possibly slow some games down slightly (though probably not by a lot).

#1 is usually a feature killer because if it's possible to do something another way, we usually stick with that for the sake of not further cluttering up the language. But it's not always so, so the possibility to implement this remains open. I'll move it to Needs Discussion.
#3 Feb 4 2011, 5:12 pm
As I mentioned in my blog post, this would be useful for compensating for some of the shortcomings of BYOND's built-in procs (particularly rgb()).

I imagine there are a lot of things about the DM language that you (the staff) would like to change but can't (because it's tough to do and not really worth the hassle). I think this feature could help in making some soft-coded features that "fix" aspects of DM.
#4 Feb 5 2011, 4:45 pm
I'm not sure I follow what you mean about a shortcoming in rgb(); that's a pretty straightforward proc.
#5 Feb 5 2011, 6:28 pm
Lummox JR wrote:
I'm not sure I follow what you mean about a shortcoming in rgb(); that's a pretty straightforward proc.

Yes, rgb() is good for what it does but it only converts from RGB values to the #RRGGBB string. Having a toString proc provides ways for user-created code to integrate more nicely with the built-in features of DM.

http://www.byond.com/members/ Forumaccount?command=view_post&post=102684#color

http://www.byond.com/members/ Forumaccount?command=view_post&post=102684#tostring

A lot of DM's shortcomings can be addressed by libraries but without some changes to BYOND, there will always be a limit to the elegance of these user-created solutions. We're not given good built-in objects for handling colors, sizes (ex: "16x12"), screen_locs (parsing "3:16,4:8" is fun, right?), or dates. A toString proc would make it possible for a library to fix all of these problems.
#6 Feb 5 2011, 7:35 pm
Another thing. "[src]" puts the name of the object, if I recall correctly. Not everyone wants the name of their object to be "The contents of this object are: eggs, cake, pie", and they might want to just call the object "Cooking Box."
#7 Feb 5 2011, 7:53 pm
In other programming languages like C#, this function is included and used frequently. It's extremely useful for debugging purposes. There are no security risks, the notion that there are is silly.
#8 Feb 5 2011, 8:29 pm (Edited on Feb 5 2011, 8:44 pm)
I'm all for this. A standard way of allowing objects to declare their own 'name' would do a lot to help in many areas. Additionally, the number of knowledgeable developers vs. non-knowledgeable developers in support of vs. against is typically a pretty good way of showing usefulness, it seems.
#9 Feb 6 2011, 12:39 am
I've asked for this feature myself, for one reason and one reason only, a string datum. Being able to control how a datum gets added to a text string would make the process far easier than my current implementation (of having to use a custom proc to output the contents of the datum).

Being able to do
var/String/S = new("Hello world")
S.replace("world","all")
world << "[S]"


Is a lot more friendly than having to call something like S.text or S.toString(). And since datums don't have a name variable by default without turning them into an atom you're basically forced to inherit all of the crap from atoms just to make use of that functionality.
#10 Feb 7 2011, 7:52 am (Edited on Feb 8 2011, 1:13 pm)
I'm not sure what needs to be discussed here. Lummox said that this feature is easy to workaround and that having it would clutter the language. The problem is that the lack of this feature clutters up every library that would use it but has to use a workaround instead.

It seems like a simple default implementation for atom/toString would take care of backwards compatibility concerns. What other issues need to be discussed?

Edit: I can understand that you want the language to remain easy to use but it's silly to leave out useful features and call it "being clutter free". While we're on the topic, thanks to whoever made this comments page clutter free =)
#11 Jun 4 2011, 6:50 pm (Edited on Jun 4 2011, 7:00 pm)
Nadrew wrote:
...
And since datums don't have a name variable by default without turning them into an atom you're basically forced to inherit all of the crap from atoms just to make use of that functionality.

You can actually define one yourself, and it'll even act like the atom/name variable (in inputs, grids, stats, and text outputs). The only (good) exception is that it doesn't add "The" in front of lowercase words.

string
    var/name

    New(_name)
        name = _name

mob/verb/Test()
    var/string/S = new("this is my string")
    world<<"[S]"


The only challenge then is keeping your name variable updated. But in your case, simply storing the string in it to begin with would solve that (albeit be a little confusing at first)



@OT

I think operator overloading like this is one of the cooler features DM is still missing. Of course, full operator overloading would require stricter types for prototyping, I would imagine. I guess the next best thing would be a ToString() process.
#12 Jun 4 2011, 7:26 pm
The problem is that you can't always keep the name string up to date.

Color
    var
        red
        green
        blue
    New(r, g, b)
        name = rgb(r, g, b)
        
        red = r
        green = g
        blue = b


// elsewhere in the code:

var/Color/c = new(0, 0, 0)

...

c.red = 100
world << "the color is [c]."


If you're going to manually update name, you might as well manually call rgb() or give the /Color object a setRed() proc that can update the name.