Currently lists are defined like that:
<?php
$definition = array(
'type'=> 'item_type',
'constraints'=> array('item constraints'),
'list'=> TRUE,
);
?>That's a bit confusing as it's not very clear that all keys correspond to the items contained in the list. So feedback has been that a type 'list' would make more sense. Thus, I'd suggest we change list definitions to work that way:
<?php
$definition = array(
'type'=> 'list',
'settings'=> array(
'item'=> array(
'type'=> 'item_type',
'constraints'=> 'item constraints',
),
),
// And if you want you can have that:
'constraints'=> array('list constraints'),
);
?>Note that via the use of the documented 'settings' key we do not have to invent a new definition-key for specifying the list item details - settings is already the place for type-specific settings. Also, it makes the list type not special at all, any contrib could define it's own custom list type if wanted. That way we can remove the current special 'list class' property, and instead of that simply do:
<?php
$definition = array(
'type'=> 'custom_list',
'settings'=> array(
'item'=> array(
'type'=> 'item_type',
'constraints'=> 'item constraints',
),
),
);
?>This would also influence how entity fields are defined, as all of those are lists of field items. So to make their definition inline with the above suggestion we could have that:
<?php
$definition = array(
'label'=> t('A text field'),
'type'=> 'field_item_list',
'settings'=> array(
'item'=> array(
'type'=> 'text_item',
'constraints'=> 'item constraints',
),
),
);
?>Whereas type 'field_item_list' points to our current "Field" class.