Add an isEmpty() and hasProperty() methods to improve DX

Here is a patch adding a new isEmpty public method.
I will update the issue summary to help the maintainer to review this.

This patch is part of the #1day1patch initiative.

I fixed a tiny mistake in the comment.

I have some issues with this new method. It's name suggests that it returns FALSE if the value exists and is not empty while it returns TRUE if the value does not exist or is empty (instead of throwing an exception). In fact, I never seen it returning TRUE and it continues to throw exceptions when used on a non-existing property or field...

I tried to replace it by the following code but it only fix the first behavior and still not allow to easily check if a field/property exists.

  public function isEmpty() {
    try {
      $value = $this->value();
    }
    catch (EntityMetadataWrapperException $e) {
      $value = FALSE;
    }
    return empty($value);
  }

May we create another method allowing to do something like this ?

$wrapper->doesExist('my_suspicious_field');

Or may we change the isEmpty method to have something more like this ?

$wrapper->isEmpty('my_suspicious_field');

This patch introduces an EntityStructureWrapper::hasChild() method that checks if the given child exists without throwing an exception.

It allows to do things like this :

if ($wrapper->hasChild('field_my_field') && $wrapper->field_my_field->isEmpty()) {
  // Do something.
}

Sorry, I forgot to include the EntityMetadataWrapper::isEmpty() as exposed in #6

Here is a new patch containing the isEmpty() from #6 and the hadChild() from #7

Issue summary update.

I think you should use the existing getIdentifier() public method.

Updated issue summary.

if (!$wrapper->hasChild('field_name')) {...}

I'm not sure hasChild() is the right name for that method. Elsewhere, these are called properties, aren't they? And if, say, I have an entityreference field on users, I get a chain of properties $node_wrapper->author->entityref_to_node... child doesn't seem right when these can double back on themselves and be circular...

Hi joachim, thank you for your review.
I am sorry but I don't get the point, probably because of the language barrier.

The purpose of this hasChild() method is to safely check if there is a field or a property named like this on the entity before querying it to avoid having to deal with Exceptions. We could name it hasComponent() if it suits better to the concept.

If you think it could lead to an infinite loop in some cases I may have coded it wrong. I don't remember why I didn't use the getPropertyInfo() method instead of get() but if you think it could be better and safer I can rewrite my patch.

My point was entirely about the method name. hasProperty() would be my suggestion.

And I don't mean there's an infinite loop in the code, not at all!

I meant that with the properties that are references to other entities, you can loop round. Eg:

- node has an 'author' property to the user entity
- you can put an entityref field on users that points to nodes, and this will define a property

So if the field on the user points to a node that the user is the author of, you can go $user_wrapper->node_field->author->value() and you're back where you started. Hence 'child' doesn't seem to really fit.

hasProperty() seems like a better fit.
it's close to hasOwnProperty() in ECMAScript-ish dynamic languages.

Isn't it confusing to use "property" in the name of a method that can check the existence of properties and fields?

@joachim: sorry for the misunderstanding about the circular relations.

To Entity API metadata wrappers, everything is a property: $node->title becomes the title property, and a node FieldAPI field field_foo becomes the field_foo property.

Here is a new patch.

It would be a great feature. I don't understand why it is still pending.

The hasProperty() method is identical to the output you can get from simply doing isset() on an unknown property, so I don't think that adds anything.

In other words:

$wrapper->hasProperty('field_name') === isset($wrapper->field_name)

Meanwhile, the isEmpty() property seems to be equivalent to calling empty($property->value()), which doesn't help us much. I do see the exception catching there, but I don't think that actually would trigger unless you were calling this method on an undefined property, which can be tested by calling isset. So:

if(isset($wrapper->field_name) && !empty($wrapper->field_name->value())) { ... }

Equals

if($wrapper->hasProperty('field_name')) && !$wrapper->field_name->isEmpty())) { ... }

However, when you combine the idea behind hasProperty with isEmpty by passing the name to isEmpty, you do get a helpful function that catches exceptions AND tells you whether the property is empty:

   public function isEmpty($name) {
    try {
      $value = $this->$name->value();
    }
    catch (EntityMetadataWrapperException $e) {
      $value = FALSE;
    }
    return empty($value);
  }

Thus

isset($wrapper->field_name) && !empty($wrapper->field_name) === $wrapper->isEmpty('field_name')

I'm updating the patch to combine the two functions in this way. As well as an interdiff.

Love this! I wanted a simple way to know if a node that I tried to load with entity_metadata_wrapper() exists, without attempting to load the whole node and all it's fields with $node->value().

If the node doesn't exist, I can't access $node->nid->value() (it throws an exception), even though the property isset.

Which this patch, I can simply say $node->isEmpty() and get the information I need in a lightweight fashion.

These are a real nice addition, a must for code readability

I'm not sure if it is good to use exception to handle this case. But a little bit strange to me.

isEmpty() should translate to $value === NULL, if the property does not exist it is not not-empty, it does not exist. I.e., the passed property name is an invalid parameter and should throw an exception. This needs to be documented via @thrown as well.

+   *   The name of the child to check.
+   * @return bool
+   *   TRUE if the child exists, FALSE if it does not.

Misses a new line before @return.

Rerolling the patch from #20, which will apply endlessly creating Fatal errors for duplicate methods.

I think this is also related to the issue #1596594: EntityMetadataWrapperException: Parent Data Structure Not Set and maybe if that one is fixed this won't be necessary.

I was getting a fatal error about calling value() on null when using isEmpty() on a property that doesn't exist. A quick !empty() seems like a good fit here.