php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #55266 Traits vs Type hints
Submitted: 2011-07-22 07:44 UTC Modified: 2011-10-17 21:55 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:0 (0.0%)
From: mchlpl at gmail dot com Assigned: gron (profile)
Status: Closed Package: Class/Object related
PHP Version: 5.4.0alpha2 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: mchlpl at gmail dot com
New email:
PHP Version: OS:

 

 [2011-07-22 07:44 UTC] mchlpl at gmail dot com
Description:
------------
Traits, when used in a class, are not added to class' type, and therefore can not be use in type hints. The RFCs on traits https://wiki.php.net/rfc/traits  and on horizontal reuse https://wiki.php.net/rfc/horizontalreuse do not explain if this is by design.

On the other hand Traits seem to share the same namespace as Classes and Interfaces, since it is impossible to have an Interface and a Trait that share the name ('Fatal error: Cannot redeclare class' is raised when this is attempted).

Test script:
---------------
<?php
trait SomeTrait {}

class SomeClass {
  use SomeTrait;
}

$a = new SomeClass();

var_dump(is_a($a,'SomeTrait'));

Expected result:
----------------
bool(true)

Actual result:
--------------
bool(false)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-07-22 13:36 UTC] me at mikestowe dot com
I believe this is the correct result as $a is not an instance of the trait but rather of the class that utilizes the trait.
 [2011-07-22 14:50 UTC] mchlpl at gmail dot com
Mike: That's one way of looking at it. My point of view is that a trait adds methods to class' interface (where interface is a set of public members of a class - both methods and fields) and this should be reflected in class type.

Currently (unless I missed something that was not mentioned in RFC - I admit to not have gone through SVN version of docs) there seem to be no way to check if class uses a trait or no. Only new functions mentioned are trait_exists() and get_declared_traits(). Checking if the object has a method will not work, if trait is meant to override method in host class. Having traits reflected in object's type, would solve this problem nicely. Adding another function to glabal namespace (uses_trait() ?) is not something I would like to see.
 [2011-07-22 14:51 UTC] alex dot howansky at gmail dot com
> $a is not an instance of the trait but rather of
> the class that utilizes the trait.

You can say the same of interfaces and abstracts, but is_a returns true for 
them.

Test script:
---------------
trait someTrait {}

interface someInterface {}

abstract class someAbstract {}

class someClass extends someAbstract implements someInterface {
    use someTrait;
}

$a = new someClass();
var_dump(is_a($a, 'someClass'));
var_dump(is_a($a, 'someAbstract'));
var_dump(is_a($a, 'someInterface'));
var_dump(is_a($a, 'someTrait'));

Expected result:
----------------
bool(true)
bool(true)
bool(true)
bool(?)

Actual result:
----------------
bool(true)
bool(true)
bool(true)
bool(false)
 [2011-07-23 07:47 UTC] gron@php.net
My view on this issue is that traits do not constitute types and do not provide interfaces. (I proposed the later one in the beginning in the sense of traits are interfaces with implementation, but this was disregarded to make clear that traits are neither classes nor interfaces.)

Thus, is_a should also not say anything about a trait.
Traits are not units of encapsulation, they do not guarantee to provide/protect any invariants.

However, if you need to know what traits are used by a class, please refer to: ReflectionClass::getTraits()

I just noticed that we have the following function in the SPL:
http://php.net/manual/en/function.class-implements.php
That should probably be mirrored to provide the same functionality as ReflectionClass::getTraits().

Not sure what the design policies are here. From a symmetry perspective there should be a class_uses() function, but from my personal perspective, class_implements should get nuked and uses should transition to the reflection extension if they need such meta programming facilities. Well, the later is not practical, so we will probably need to have class_uses().
 [2011-07-23 07:49 UTC] gron@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: gron
 [2011-07-23 19:08 UTC] gron@php.net
Automatic comment from SVN on behalf of gron
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=313640
Log: Added missing class_uses(..) function to SPL to mirror class_implements(..).

# Was pointed out as missing in bug #55266.
 [2011-07-23 19:13 UTC] gron@php.net
-Status: Assigned +Status: To be documented -Assigned To: gron +Assigned To:
 [2011-07-23 19:13 UTC] gron@php.net
Added class_uses(..) in SPL to mirror existing class_implements(..) per http://svn.php.net/viewvc?view=revision&revision=313640
 [2011-10-16 18:46 UTC] gron@php.net
-Status: Open +Status: To be documented
 [2011-10-16 18:46 UTC] gron@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2011-10-17 21:55 UTC] gron@php.net
-Status: To be documented +Status: Closed -Assigned To: +Assigned To: gron
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 13:01:29 2024 UTC