[RFC][DISCUSSION] Object type hint

On Sun, Oct 23, 2016 at 1:39 AM, Michał Brzuchalski
michal@brzuchalski.com wrote:

Hi all,

I would like to initiate discussion for Object typehint RFC
https://wiki.php.net/rfc/object-typehint

This feature is developed to provide missing functionality which is needed
and quite easy to introduce.
There are many people which I've talked about the benefits of this
functionality.

For those who doesn't like the idea and think they won't need neither use
it rather than just saying 'no' they
please say why other people who want to use that parameter type are wrong,
for wanting to do that.

If there is anything left to discuss, please comment.

Thanks to @Danack for drafting.

regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

I generally don't mind keywords/new classes being added to minor
versions. However I am nervous about this one as I am sure there are a
lot of class Object floating around. Maybe this would be best suited
for 8.0 with E_DEPRECATED being emitted to warn people of the
up-coming change? Also, can the RFC be edited to give an example of
how people will be affected?

Other than this issue I support this RFC.

Hi!

I would like to initiate discussion for Object typehint RFC
https://wiki.php.net/rfc/object-typehint

I don't see why it would be important that the variable is an object but
not important which kind of an object. There's very small number of
things you can do with an object without knowing the exact type. For
generic functions, like serialization, there's no reason why they
shouldn't be able to serialize integers or nulls or booleans. On the
contrary, many objects would not be serializable. For less generic
functions, like DI containers, object type is next to useless since you
can't just pass any object to implement a service - it should actually
implement the required service. So adding "object" does not add real
specificity to it.

This feature is developed to provide missing functionality which is needed
and quite easy to introduce.
There are many people which I've talked about the benefits of this
functionality.

For those who doesn't like the idea and think they won't need neither use
it rather than just saying 'no' they
please say why other people who want to use that parameter type are wrong,
for wanting to do that.

They probably think more "strictness" and more checks means better code.
It is usually not true per se. E.g. in the RFC examples the type does
not seem to be serving a good purpose - it's either wrong (like in the
case of json_decode - it won't always return an object), or nonspecific

• like in factory, very rarely one has a factory returning just
  arbitrary objects, no matter what they are.
  --
  Stas Malyshev
  smalyshev@gmail.com

On Sun, Oct 23, 2016 at 3:39 AM, Michał Brzuchalski michal@brzuchalski.com
wrote:

Hi all,

I would like to initiate discussion for Object typehint RFC
https://wiki.php.net/rfc/object-typehint

This feature is developed to provide missing functionality which is needed
and quite easy to introduce.
There are many people which I've talked about the benefits of this
functionality.

For those who doesn't like the idea and think they won't need neither use
it rather than just saying 'no' they
please say why other people who want to use that parameter type are wrong,
for wanting to do that.

Type hinting, along with the assert statement, provide a means to establish
expectations for a methods. It's part of a coding paradigm known as 'design
by contract' and it's critical for large teams and projects that are used
among multiple teams.

Checking to see if a variable is an object in no way provides a real test
of what can be done with it. Can it be iterated on? Probably, but not
always. Does a method exist on the object? No way to know without further
testing.

Defining what an object can do is the reason interfaces exist. This is also
why objects are allowed to implement multiple interfaces, so that they can
be labeled according to all the roles they can fulfill.

My principle worry with this RFC is it encourages an anti-pattern - not
using interfaces and thereby not clearly labeling what objects can and
cannot do.

The one situation this might be useful requires additional testing anyway -
that would be a method that will receive objects of one or more classes
that don't have a common interface and rewriting the class to add the
desired interface isn't viable (for example, the objects come from
different packages). In that event though type hinting for an object is
only going to be the first step in determining if the code state is sane,
you'll also need to check if the object belongs to one of the several
classes the code can work with. This gets even hairier when dealing with a
collection of objects. I wrote this generic assertion for Drupal 8.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Assertion%21Inspector.php/function/Inspector%3A%3AassertAllObjects/8.2.x

In your own code you'll likely need to do something similar with your
argument. Incidentally, these sorts of tests, which can only fail if the
code is wrong, are what assert statements are to be used for, not
exceptions. This way the check for correct objects can be turned off in
production to avoid the cpu overhead of the test (assuming your function
doesn't need to switch to different branches depending on the exact object
used).

In summary, -1 to this as it encourages bad code writing.

Hi,

I would like to initiate discussion for Object typehint RFC
https://wiki.php.net/rfc/object-typehint

This feature is developed to provide missing functionality which is needed
and quite easy to introduce.
There are many people which I've talked about the benefits of this
functionality.

I just wished a few weeks ago I was able to typehint that. Actually I
even tried just to lern it doesn't work.

It's a unit test helper method to make a method on an object public,
signature:

protected function makeMethodPublic(object $obj, string $methodName):
ReflectionMethod

So, I can come up with exactly one (to me) useful case, but it's
arguable not "that important" and I certainly wouldn't and didn't add an
is_object check for this, so there goes my priority for it.

thanks,

• Marus

Hi Michal!

First of all, many thanks to you and Dan for pushing this forward. It is
indeed a very needed and long due addition to the engine.

I just wanted to clear up the use-case scenarios for everyone in here that
keeps stating that this will lead to bad code.
It is very unlikely to type-hint "object" inside your business domain.
Where this functionality is useful is any of the following (with examples):

• generic hydrators/property access (these exist, and they are widely used
  inside form components)

class SillyLibraryHidrator
{
public function hydrate(object $object, array $someData)
{
// pseudo:
foreach ($objectReflectionProperties as $p) {
$p->setValue($object, $someData[$p->getName()]);
}
}
}

• serializers - also widely used, can generally tell them to produce an
  object of a certain type. Consumers would then wrap it, and use a more
  specific type-hint

interface JsonSerializer
{
public function serialize(object $object) : string;
public function deSerialize(string $data, string $className) : object;
}

• identity maps - typically part of ORMs

interface IdentityMap
{
public function add(string $id, object $object) : void;
public function getId(object $object) : ?string;
public function getObject(string $id) : ?object;
}

• code generators

interface WrapThingIntoAProxy
{
public function wrap(object $object) : object;
}

• instantiation logic for generic factories

interface AGenericFactory
{
public function create(array $data, string $className) : object;
}

• table data gateways/repositories

interface TableDataGateway
{
public function fetchById(array $identifier) : ?object;
}

These are just some of the examples that get direct benefit from this sort
of type-hint, or at least the scenarios that I work with on a daily basis.

Please don't tell me that I have to get back to is_object(), because:

• it is implicitly part of the implementation, and not part of the
  reflectable signature AS IT SHOULD BE
• it is more code for me to test
• I cannot throw a TypeError myself, if a non-object is given (TypeError
  can't be instantiated in userland, AFAIK), and every time I have to design
  custom exceptions (also to be tested/documented)
• this way is actually faster than a manual is_object() check
• intent is conveyed to the consumer directly, and not via documentation
  docblock
• allows for explicit nullability, yet splitting object/non-object APIs
• many library-level codebases rely on generic code that doesn't know
  about one specific type, but just about "objects"

The alternative is going with full generics, but that's not viable for now.
This additional type hint is pretty much covering the scenarios above in a
very approachable way.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Sun, Oct 23, 2016 at 12:39 AM, Michał Brzuchalski <michal@brzuchalski.com

wrote:

Hi all,

I would like to initiate discussion for Object typehint RFC
https://wiki.php.net/rfc/object-typehint

This feature is developed to provide missing functionality which is needed
and quite easy to introduce.
There are many people which I've talked about the benefits of this
functionality.

For those who doesn't like the idea and think they won't need neither use
it rather than just saying 'no' they
please say why other people who want to use that parameter type are wrong,
for wanting to do that.

If there is anything left to discuss, please comment.

Thanks to @Danack for drafting.

regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Hi,

Michał Brzuchalski wrote:

I would like to initiate discussion for Object typehint RFC
https://wiki.php.net/rfc/object-typehint

I like this proposal. We already have an object type internally for the
same reasons (functions acting on a generic object), so it makes sense
to extend this to userland which may want to do the same kinds of things.

One potential benefit is that functions can be more generic. I imagine
there's some functions out there typed against \stdClass which could
really accept any object if given the option.

Best of luck.

Andrea Faulds
https://ajf.me/