However, I'd argue that as it stands it doesn't really move the needle in developer experience. I believe there is a lot more we could do.
Example taken from the patch:
+ $fields['weight'] = FieldDefinition::create('integer')
+ ->setLabel(t('Weight'))
+ ->setDescription(t('The weight of this term in relation to other terms.'))
+ ->setFieldSetting('default_value', 0);
Could be simplified to:
+ $fields['weight'] = new IntegerFieldDefinition()
+ ->setLabel(t('Weight'))
+ ->setDescription(t('The weight of this term in relation to other terms.'))
+ ->setDefaultValue(0);
IntegerFieldDefinition would extend BaseFieldDefinition, and setDefaultValue() would be implemented in IntegerFieldDefinition.
In fact, this could be simplified further. 'Label' and 'Description' appear to be required so we could actually write the following.
+ $fields['weight'] = new IntegerFieldDefinition(t('Weight'), t('The weight of this term in relation to other terms.'))
+ ->setDefaultValue(0);
Another example from the patch:
+ $fields['changed'] = FieldDefinition::create('integer')
+ ->setLabel(t('Changed'))
+ ->setDescription(t('The time that the term was last edited.'))
+ ->setPropertyConstraints('value', array('EntityChanged' => array()));
Could become:
+ $fields['changed'] = new EntityChangedFieldDefinition();
+ ->setLabel(t('Changed'))
+ ->setDescription(t('The time that the term was last edited.'));
Note that all the obscure constraint stuff would now abstracted away for people that need to create new entity definitions.
Or even simpler:
+ $fields['changed'] = new EntityChangedFieldDefinition(t('Changed'), t('The time that the term was last edited.'));
Thoughts?