On Mon, Jun 7, 2010 at 3:40 PM, Scott Carey <[email protected]> wrote: > > On Jun 7, 2010, at 3:30 PM, Doug Cutting wrote: > >> On 06/07/2010 03:11 PM, Bill de hOra wrote: >>> This means writers can't leverage schema defaults, so writers should do >>> something like this? >>> >>> Message message = new Message(); >>> // no defaults set >>> String quux = message >>> .getSchema() >>> .getField("foo") >>> .defaultValue() >>> .getTextValue(); >>> message.foo=new Utf8(quux); >>> >>> [ignoring that the writer needs to know the schema type]. I suspect >>> people will just write in garbage (like empty strings). >> >> No, we don't expect folks to do that. If a writer never sets a field >> then they might be better off dropping that field from their schema. If >> the writer only rarely sets it, then a schema which is a union with null >> might be better, making the field optional. But if the field is usually >> set but it's awkward for the programmer to know whether its set, then >> automatically filling in a default might be a useful feature and the >> default from the schema is probably a good value to use. >> >> Like Philip, I too am +1 for enhancing the SpecificCompiler to set >> default values from the schema in generated code. The only downside I >> see is perhaps a slight performance loss: if the default value is always >> overwritten then the allocation and setting of it will still be executed >> for each instance. > > For my specific use case, defaults being set all the time would hurt > performance quite a bit. (the schema not trivial -- ~5k in JSON) > > If the specific compiler generated a couple constructors -- > * A default empty argument constructor -- fills fields with defaults. > * A constructor with all fields passed in -- assigns fields from the > constructor and does nothing with defaults.
Unfortunately, the latter is bad for compatibility. If there are two fields of the same time, it's pretty easy (since there's not necessarily a canonical order) for this to introduce a nasty incompatibility. This is not theoretical: Thrift ran smack into this. PBs have "Builder" objects, which I imagine don't satisfy your performance worries. If you have getters and setters, you can implement setFoo() with "this.fieldsSet.setBit(FOO); this.foo = foo);" (i.e., use a bitmap to remember what has and hasn't been set). The current API doesn't use setters, I think, though, so this wouldn't be easily backwards compatible.
