Custom toString implementation

368 views
Skip to first unread message

mi...@joinblink.com

unread,
Mar 13, 2017, 7:18:45 AM3/13/17
to ScalaPB
Hi, first of all, thanks for a great plugin. 

I was wondering if it would be possible to provide an option of custom toString methods? Or an option for ScalaPB not to override the one inherited from the base class?

I have some data on some of the proto fields that we would like not to end up in logs when I log the proto object. Unfortunately, given how ScalaPB does toString (the toString method from (scalapb.field).type is not used, instead choosing to operate on the proto types), the only way I could quickly find to override it was to collision the Printer object on the classpath and make a custom version that doesn't print one custom message used to wrap the string with. This is obviously less than ideal.

Currently using 0.6.0-pre2. 

Nadav Samet

unread,
Mar 13, 2017, 11:13:45 AM3/13/17
to mi...@joinblink.com, ScalaPB
Hi Mike,

The provided toString() is designed to be compatible with the ASCII format used by all protobuf implementations. Allowing customization will break compatibility. You still have a few options:
1. If you only want to drop some fields: write a function that clears up sensitive fields and pass your proto through it before you log.
2. If you don't care for that toString() compatibility: write a trait that overrides toString() and use (scalapb.message).extends (see https://scalapb.github.io/customizations.html). I haven't tested if toString() can be overrriden this way, but you can certainly add toMyFormat() that returns any string you'd like.

HTH, Nadav

mi...@joinblink.com

unread,
Mar 13, 2017, 11:41:36 AM3/13/17
to ScalaPB, mi...@joinblink.com
Hi Nadav,

Thanks for your reply. 

I looked into both options and sadly, given that scalapb explicitly generates the toString function, 2 is not an option. 

Option 1 is obviously possible, but it is very error prone as one cannot guarantee that someone won't just chuck the proto file into the log.debug without stripping the content one day. Being able to control toString would protect against this.

I understand that scalaPB has to be compatible with google ascii format. However, is it necessary for the toString method to return said text format? 

Given the wide use of toString method for logging / debugging / etc should it be part of any explicit specification? Json libraries usually use toJson (or similar) rather than toString for a similar reason.

Wouldn't something like toProtoString, while keeping toString free for any use, make more sense?

Thanks,
Mike

Nadav Samet

unread,
Mar 13, 2017, 11:52:44 AM3/13/17
to mi...@joinblink.com, ScalaPB
The reason toString() was chosen to return this format is for consistency with the Java API. I re-opened https://github.com/scalapb/ScalaPB/issues/235 as maybe there's a way to change how toString works without breaking it for existing users. Let's discuss there.

--
You received this message because you are subscribed to the Google Groups "ScalaPB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalapb+unsubscribe@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scalapb/f4af1c42-dea8-47ec-b645-754e0fc91d79%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
-Nadav
Reply all
Reply to author
Forward
0 new messages