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.
Why is it incorrect to not provide defaults when defaults are part of the schema author's intention? Or put another way, why is reader/writer asymmetry a goal under a given schema?
It's not incorrect nor is asymmetry a goal. (I don't think Scott meant either of those to be the case.) Java instance default values were not the primary purpose of default values in a schema, but they're a fine, complementary use of them.
Doug
