Move Entity/TypedData normalization inline

Because I can :p

1. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php
   @@ -269,4 +269,11 @@ public function url($rel = 'edit-form', $options = array()) {
   +   * {@inheritdoc}
   +   */
   +  public function normalize($format = NULL, array $context = array()) {
   +    return $this->getExportProperties();
   +  }
   +
    }
   

   General question: does it make sense to keep getExportProperties as public method?

2. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php
   --- a/core/lib/Drupal/Core/Entity/Entity.php
   +++ b/core/lib/Drupal/Core/Entity/Entity.php
   
   +++ b/core/lib/Drupal/Core/Entity/Entity.php
   @@ -442,4 +442,15 @@ protected function urlGenerator() {
   +    $attributes = array();
   +    foreach ($this as $name => $field) {
   +      $attributes[$name] = $field->normalize($format, $context);
   +    }
   
   +++ /dev/null
   @@ -1,53 +0,0 @@
   -class ConfigEntityNormalizerTest extends UnitTestCase {
   

   It feels wrong to let the entity class assume things about typed data. Afaik this code would be better for ContentEntityBase but even more important iterating over $this is problematic. We might at least should check instanceof here. Also: We can't just drop test coverage like that but replace it with tests for all the new methods.

That removes all the unit tests I did :(

Decide if EntityInterface::normalize() and TypedDataInterface::normalize() should have a more generic/specific/different name

Could it be just toArray() everywhere? Do we need the format and context options? I guess this needs to be extendable anyway such that I can plug in normalizers for new formats in a separate class still?

1. +++ b/core/lib/Drupal/Core/Entity/EntityInterface.php
   @@ -299,4 +299,16 @@ public function getEntityType();
   +   *   The format the normalization result will be encoded as
   

   Missing trailing point. What kind of formats are supported here. I guess this should point me to related documentation about the normalizer as this method is out of normalizer-context now.

2. +++ b/core/lib/Drupal/Core/Entity/EntityInterface.php
   @@ -299,4 +299,16 @@ public function getEntityType();
   +   *   Context options for the normalizer
   

   What can be in there? Again probably some pointer (maybe for the whole method) would be good. Misses trailing point also.

toArray() is nice, but "cast to an array" is also sort of what TypedData::getValue() does already (and I was kind of hoping it could get renamed toArray() at some point)
Related question: are the two (the current getValue() and the proposed normalize() / toArray()) really different ?

Regarding the format and context params; If we do go with this idea (I am semi-convinced at this stage :)) an entity should have no business with either of those.

I think we should also consider not using normalize() too. toArray() works better I think. Normalize is a term adopted by Serializer, to reflect how its architecture works (IMO).

yched, could they be consolidated to TypedData objects? In answer to your question, I don't think they really are different :)

See also #2002138: Use an adapter for supporting typed data on ContentEntities, which is dropping Entity::getValue() and renaming getPropertyValues() to getFieldValues. Not touching FieldItem yet, but yes, getValue() -> toArray() is exactly what I wanted to do there.

TypedDataInterface::toArray() is pretty crazy, because complex data is an extension of it, it shouldn't implement that.

An array representation of Non-ComplexData does not make much sense to, because most of those are scalar/primitive values. $string->toArray() => array('the_string') ? :)

Related question: are the two (the current getValue() and the proposed normalize() / toArray()) really different ?

hm, for fields yes, but - speaking of the typed data API, no - not necessarily. The internal value is up to the data type and may be anything, including classed objects, etc.. It's just whatever the class wraps.

Yes, on TypedDataInterface, getValue() can be anything and there might not be a useful array representation of that.

ComplexDataInterface on the other hand, should always have a useful to Array() representation as it contains a set of properties and their values can be returned as array. But their values might not be arrays.

In #2002138: Use an adapter for supporting typed data on ContentEntities, we discussed to rename getFieldValues (which I renamed from getPropertyValues()) to toArray(), so that content entities would only have that method and not an additional wrapper as currently added here.

Is this still needed? Shouldn't be postponed in anycase.