IBox::setOptions() - Code Metrics - Antidot-be/bpost-api-library - Measure and Improve Code Quality continuously with Scrutinizer

IBox::setOptions()
last analyzed 2016-08-25 18:47 UTC

↳ Parent: IBox

Size

Total Lines

Duplication

Lines	0
Ratio	0 %

Importance

Changes

Metric	Value
dl	0
loc	1
c	0
b	0
f	0

<?php

namespace Bpost\BpostApiClient\Bpost\Order\Box;

/**
 * Interface IBox
 * @package Bpost\BpostApiClient\Bpost\Order\Box
 */
interface IBox
{

    /**
     * @param array $options
     */
    public function setOptions($options);


    /**
     * @return array
     */
    public function getOptions();

    /**
     * @param \Bpost\BpostApiClient\Bpost\Order\Box\Option\Option $option
     */
    public function addOption(Option\Option $option);


    /**
     * @param string $product
     */
    public function setProduct($product);


    /**
     * @return string
     */
    public function getProduct();

    /**
     * @remark should be implemented by the child class
     * @return array
     */
    public static function getPossibleProductValues();

    /**
     * Return the object as an array for usage in the XML
     * @param  \DomDocument $document
     * @param  string $prefix

     * @return \DomElement
     */
    public function toXML(\DOMDocument $document, $prefix = null);

    /**
     * @param  \SimpleXMLElement $xml
     * @return self
     */
    public static function createFromXML(\SimpleXMLElement $xml);
}


1			<?php
2
3			namespace Bpost\BpostApiClient\Bpost\Order\Box;
4
5			/**
6			* Interface IBox
7			* @package Bpost\BpostApiClient\Bpost\Order\Box
8			*/
9			interface IBox
10			{
11
12			/**
13			* @param array $options
14			*/
15			public function setOptions($options);
			0 ignored issues – show Documentation introduced 2016-03-24 12:08 UTC by Report Bug Copy Issue Report For interfaces and abstract methods it is generally a good practice to add a `@return` annotation even if it is just `@return void` or `@return null`, so that implementors know what to do in the overridden method. For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a `@return` doc comment to communicate to implementors of these methods what they are expected to return. Loading history...
16
17			/**
18			* @return array
19			*/
20			public function getOptions();
21
22			/**
23			* @param \Bpost\BpostApiClient\Bpost\Order\Box\Option\Option $option
24			*/
25			public function addOption(Option\Option $option);
			0 ignored issues – show Documentation introduced 2016-03-24 12:08 UTC by Report Bug Copy Issue Report For interfaces and abstract methods it is generally a good practice to add a `@return` annotation even if it is just `@return void` or `@return null`, so that implementors know what to do in the overridden method. For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a `@return` doc comment to communicate to implementors of these methods what they are expected to return. Loading history...
26
27			/**
28			* @param string $product
29			*/
30			public function setProduct($product);
			0 ignored issues – show Documentation introduced 2016-03-24 12:08 UTC by Report Bug Copy Issue Report For interfaces and abstract methods it is generally a good practice to add a `@return` annotation even if it is just `@return void` or `@return null`, so that implementors know what to do in the overridden method. For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a `@return` doc comment to communicate to implementors of these methods what they are expected to return. Loading history...
31
32			/**
33			* @return string
34			*/
35			public function getProduct();
36
37			/**
38			* @remark should be implemented by the child class
39			* @return array
40			*/
41			public static function getPossibleProductValues();
42
43			/**
44			* Return the object as an array for usage in the XML
45			* @param \DomDocument $document
46			* @param string $prefix
			0 ignored issues – show Documentation introduced 2016-03-24 12:08 UTC by Report Bug Copy Issue Report Should the type for parameter `$prefix` not be `string\|null`? This check looks for `@param` annotations where the type inferred by our type inference engine differs from the declared type. It makes a suggestion as to what type it considers more descriptive. Most often this is a case of a parameter that can be null in addition to its declared types. Loading history...
47			* @return \DomElement
48			*/
49			public function toXML(\DOMDocument $document, $prefix = null);
50
51			/**
52			* @param \SimpleXMLElement $xml
53			* @return self
54			*/
55			public static function createFromXML(\SimpleXMLElement $xml);
56			}
57

Antidot-be / bpost-api-library

IBox::setOptions() last analyzed 2016-08-25 18:47 UTC

Size

Duplication

Importance

Duplication Side-by-Side

Filter issues like

IBox::setOptions()
last analyzed 2016-08-25 18:47 UTC