Case: $node parameter. Neither 'stdClass' nor 'object' are accepted a types (see also discussion/arguments at #595084: Rollback type hinting for $node). Leaving off the type hint parameter gives ERROR:

Missing parameter type.

But for $node there is currently AFAIK no recommended type (and certainly no obvious interface type in D7).

But according to the Drupal Documentation Standards no type is required: https://www.drupal.org/coding-standards/docs#param:

The @param tag is followed by an optional data type indicator, then the variable name of the parameter, and then a newline.

There are many reasons that insisting on a type hint is nevertheless well advised, but since Drupal7 is not sufficiently object-oriented and does not fully adopt "Design By Contract" against Interfaces, it is not always clear what one should use as a type hint. As an avid fan of full object-orientation and graphical software engineering with Unified Modeling Language (UML), I am certainly in favour of always using type hints, which are handled quite well (mostly) by PEAR:PHP_UML. See also discussion/debate/arguments Documentation standard for @param and @return data types.

But as long as the official Drupal Coding Standards don't require a type, and as long as it is not clear (thanks to Drupal7's lack of decent OOP) what type one should choose, I do not think Coder should insist on a type hint.

Another case: one should here be able to omit the type of the $flag handler.

/**
 * Whether the given flag is applicable to the given bundle and entity type.
 *
 * @param $flag
 *   The flag handler to check.
 * @param string $entity_type
 *   The entity type to check against.
 * @param string $bundle
 *   The bundle to check against.
 *
 * @return bool
 *   Whether the given flag is applicable to the given bundle and entity type.
 */
function _flagplus_flag_may_apply($flag, $entity_type, $bundle) {

Comments

webel’s picture

Issue summary: View changes
webel’s picture

Issue summary: View changes
webel’s picture

More cases: with stdClass:

/**
 * A render array with flagplus banners (if any applicable).
 *
 * @param stdClass $node
 *   The node to add banners to.
 *
 * @return array
 *   A render array with flagplus banners (if any applicable).
 */
function _flagplus_banners(stdClass $node) {
/>

Gives Coder error:

Expected 'object' but found 'stdClass' for parameter type.



Using 'object' for both the @param type and the function signature type hint fails:
<?php
/**
 * A render array with flagplus banners (if any applicable).
 *
 * @param object $node
 *   The node to add banners to.
 *
 * @return array
 *   A render array with flagplus banners (if any applicable).
 */
function _flagplus_banners(object $node) {
Unkown type hint "object" found for $node.

But leaving 'object' off the actual type hint, but on the @param type, works (passed Coder without ERROR):

/**
 * A render array with flagplus banners (if any applicable).
 *
 * @param object $node
 *   The node to add banners to.
 *
 * @return array
 *   A render array with flagplus banners (if any applicable).
 */
function _flagplus_banners($node) {

(All of which makes me cry with desire for full OOP and Java under model-driven development with graphical UML support more than I can express. Drupal7 is primitive. W.r.t. Drupal Code of Contact. It can't be an insult to anybody if I simply state that nearly the entire Drupal effort is primitive as far as OOP is concerned.)

webel’s picture

klausi’s picture

Status: Active » Fixed

I think this is fixed now with #2474479: False report for stdClass type hint: Expected "object" but found "stdClass" for parameter type, please reopen if there is still a problem.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.