Proposal: weak toString methods

[Dave Porter]

Hi all,

I wanted to briefly highlight an area that could use some pervasive, casual, whenever-you're-in-there-anyway improvement: toString methods. These are used in a lot of automatic debugging, so when they're bad they're frustrating and when they're good they can be life savers.

A lot of classes have no toString and use the default "ClassName:sc####", and could be more descriptive. SC.LabelView for example could append the first short snippet of its displayTitle. Controllers could append the toString of their content.

Some classes have eye-bleeding ones like SC.Record's, which stringifies the entire attribute hash and spits it out (a potentially gigantic string). Instead maybe it would be useful to have the SC ID, the store ID and the store key.

Tweaking or adding toString methods is super easy: it's simple code, there's no performance consideration, and nothing depends on them (or at least nothing should). It's not a critical change so it can happen whenever you're in a file for another reason, or whenever you feel like it. Thoughts? Any general reason that this is a bad idea?

Happy Friday,

Dave

[Topher Fangio]

I personally would love more useful toString() methods. Like you said, they can be a lifesaver at some points, and truly frustrating when it's useless.

Regarding SC.Record: I agree that the mass of attributes is generally useless, however, I think the id and store key might be a bit too few. Very often, it's helpful for me to see the "name" attribute since the IDs could change on the backend when we re-run stuff. Sure, I could look it up in the database, but right now, it's fairly nice to be able to distinguish them.

Perhaps for SC.Record, users could define a set of default attributes (defaultToStringAttributes or something) to be used when calling toString() ?

So to answer your question: +1 for better toStrings :-)

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dave Porter]

Thanks Topher! I like the idea of grabbing the "name" attribute if it's present, maybe "title" if not... although there could be rare, weird, unintended consequences to getting random unknown properties. As for the user-defines-a-list-of-attributes approach for SC.Record, I thought of that, but I really suspect that that would become another unknown, unused feature. I'm not sure there's much benefit from going from procedural to declarative there – if the developer has a specific set of attributes they want to show up in toString, they can always just override toString.

Three cheers for better toStrings.

Cheers,

Dave

[Maurits Lamers]

Re: SC.Record: we could add a specific format used by the toString to the API which can be overridden in the model. Because of the huge differences between records it might be very useful.

cheers

Maurits

[Dave Porter]

I've created a monster. I don't think engineering SC.Record#toString as anything more than another overridable method is worth it, but I am eager to be proved wrong!

[Topher Fangio]

What may be most beneficial is if SC.Record#toString accepted a list of attributes. Then, you could override toString on the record and call sc_super(["attributes", "i", "care", "about"]). If no attributes are provided, it does what it currently does.

This seems like a good way to not introduce a bunch of new "functionality" or "api" so-to-speak, but would still allow easy customization should the developer want it.

Thoughts?

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Maurits Lamers]

What I wanted to suggest is that we do not override SC.Record#toString but to create a property which is read by toString to generate the actual string given.

By default it would contain a few properties, but a model can easily override it. It is more clear to a developer than playing with sc_super() (which does not allow arguments btw). In what way would this be a monster?

[Topher Fangio]

Ah, good point about sc_super.

In any case, I think the "monster" was just the fact that adding a new API to an object simply for toString() debugging seems a bit awkward. Although, personally, I do think it would be helpful, so I would like to see this become a reality even if most people don't know about it or use it.

Also, I think by default, it should do exactly what it does now; so the property would start out with all attributes and if overridden, you could pare it down.

Is there an advantage to changing the functionality to auto-show a few random properties that may or may not exist? Particularly, I know that a lot of other people don't even program in english, so the "name" or "title" fields being automatic wouldn't make much sense for them...

Thoughts?

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141