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.
Then I can use the latter to avoid the performance issue.
FWIW, I have written wrappers around all of my datum classes to deal with this,
and I have wanted to either modify the SpecificCompiler or have a new generated
object 'flavor' that had the safe-construction, union resolution, and getter
methods that my wrappers provide. I just haven't had time and its lower
priority than some other enhancements I'll need soon.
-Scott
>
>> 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
