Yii2: [PHP7] Consider to deprecate yii\base\Object as object might become soft-reserved

[suralc]

PHP 7 will soft reserve object as a possible typehint for a 7.x release (or may never use it at all). Deprecating yii\base\Object in favor of yii\base\BaseObject (or a better name) early (in 2.1) might reduce some pain once installations are upgraded if php should decide to use the object name.

I'm not sure if the patch below is the best way to go forward as the deprecation notice is only triggered if parent::__construct() is called in all child classes. However triggering the deprecation message on autoload makes it harder to locate the class using the old inheritance chain.
The deprecation is based on the fact that php in the future might use object; causing the class declaration to cause a fatal error.

Possible patch (only targets the framework itself not extensions, no tests for the deprecation notice).:
https://github.com/yiisoft/yii2/compare/master...suralc:deprecate-php7

I did not create this as a pull-request as the vote is not yet formally closed. The vote on soft-reserving object sits at 38:10 in favor so it is likely going to pass.

[cebe]

Thanks for pointing this out, need to check it.

[qiangxue]

Will the name be case sensitive or not?

[samdark]

I guess both will be reserved. We'll see when it will be accepted and someone will create a patch.

[cebe]

Class names are case insensitive so it would not matter in which case we write it.

[suralc]

@cebe The voting has been closed:

[...] the following typenames are now reserved:
Resource
Object
Mixed
Numeric

http://marc.info/?l=php-internals&m=142833998201071&w=2

[cebe]

Thanks for the info, have already seen it. This is causing much trouble. Yii 2.0.x will not run at all on php7 because of this... Not sure how to solve the issue yet. As far as I see, there is no way without breaking BC. Renaming the base class of all things is a huge thing...

ref: https://twitter.com/cebe_cc/status/585573046808879104

[cebe]

maybe something like this could work:

<?php

namespace yii\base;

class BaseObject { /* current implementation */ }

if (version_compare(PHP_VERSION, '7.0.0', '<')) {
    // ensure code works on php < 7.0.0 to not break BC
    class_alias('yii\base\BaseObject', 'yii\base\Object', false);
}

[suralc]

You don't need class_alias (could be nicer with deprecation notices, though). If the class isn't used it won't be autoloaded and won't cause harm (Classes relying on Object will fatal either way, missing class or forbidden name). You could just have Object extend BaseObject and trigger a deprecation notice in it's constructor

[suralc]

Also (thus the soft reserving in the initial post): (and yes, the rfc is ambigous in my oppinion)

To be clear, this RFC is about declaring these names as reserved, not
about actually /using/ them. There's no language in the RFC about
actually throwing errors or other code-breaking behavior. Therefore,
even should all of them pass, it does _NOT_ mean that your code using
these names suddenly stops working on PHP7. It means that you have
been warned that using the names of intrinsics is a bad idea, and that
the language reserves the /right/ to make doing so an error at some
point in the future.

http://marc.info/?l=php-internals&m=142654982915943&w=2

Deprecation as soon as possible and add a notice to the docs that using Object over BaseObject is bad practice should be enough for now:

Possible route:

1. Introduce BaseObject in 2.0.x and have Object extend BaseObject (add a note to docs)
2. Deprecate Object in 2.1 (and make sure it will never be loaded by default or by some user site optimization based on classmaps) make sure to trigger E_USER_DEPRECATED(?).
3. Everyone using Object has been warned and does so at their own risk. If their code fails at some point it's not the frameworks fault.

[cebe]

okay, thats weird, imo it should add some implementation that stops using the words as class names.
The RFC itself is very clear about this:

This breaks any and all cases where these new reserved words are used in class, interface or trait names. It does not break any usages as function or method names or as class constants.

[cebe]

You don't need class_alias (could be nicer with deprecation notices, though). If the class isn't used it won't be autoloaded. You could just have Object extend BaseObject and trigger a deprecation notice in it's constructor

tests like $var instanceof \yii\base\Object will fail if there is no alias. Also code in user applications extending from Object will break.

[suralc]

You won't be able to hint against yii\baseobject once the name is used, if it is handled like the scalar type names.

Some idea when and if object breaks code would be helpful.

edit: I missed a point in the text that was located here earlier, so I removed it.

[cebe]

You won't be able to hint against yii\baseobject once the name is used, if it is handled like the scalar type names.

thats clear, but we can do this to keep BC on PHP versions <7.0.0

[klimov-paul]

This could be solved without BC break.
We need to rename yii\base\Object class to yii\base\BaseObject, adjusting any internal inheritance. So yii\base\Component extends yii\base\BaseObject.
Then we simply re-create yii\base\Object in following way:

namespace yii\base;

class Object extends BaseObject
{
    // empty
}

After that framework code will become compatibale with PHP 7, while any developer, which uses ealier version and yii\base\Object will never notice anything.

[klimov-paul]

Although, no.
This would not work for checks like:

if ($object instanceof 'yii\base\Object')

If developer relies on such code anywhere it will break.

[samdark]

https://github.com/php/php-src/blob/PHP-7.0.0/UPGRADING

  Furthermore the following class, interface and trait names are now reserved
  for future use, but do not yet throw an error when used:

      resource
      object
      mixed
      numeric

So this one would not be a problem for PHP7 release.

[klimov-paul]

Still it may become a problem at PHP 7.1 or other future releases.

[tecnologiaterabyte]

Should consider taking a clean compatible version php 7 or higher warning of possible incompatibilities changes in php code, and could apply all patches delayed for fear bc break, and maintain other yii2 version with less than 7 php for a while.

[cebe]

for now there is no need for action anymore as yii will still run on php7. we can consider a change in 2.1 to get rid of Object.

[nkovacs]

Why not define the class alias in 2.0.x, and add a notice to the documentation of Object that BaseObject should be used instead? That way we can start using BaseObject now, and we'll have less code that will be broken later.

[omnilight]

... and mark Object class as deprecated

[kavitama]

Maybe it's too crazy but I throw it anyway ...why not "duplicate" the yii\base\Object using a new name and start with the deprecation "ads" about the chance of PHP 7 ?

[cebe]

what do you mean with "and start with the deprecation "ads" about the chance of PHP 7" ?

[kavitama]

Start informing there is already a new namespace/class available in case PHP 7 is adopting this restriction... I know it could sound crazy but you will guarantee not to break backward compatibility

[cebe]

PHP 7.0.x will not adopt this restriction, it may come in 7.1 or 7.2 or later if they find a need for it.

[cebe]

https://github.com/php/php-src/pull/2080

[rob006]

RFC for this was accepted and (probably) object keyword will be reserved in PHP 7.2.

[samdark]

https://github.com/php/php-src/pull/2080#issuecomment-310924120

[cebe]

its broken now:

$ php --version
PHP 7.2.0alpha3 (cli) (built: Jul 14 2017 14:17:25) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.2.0-dev, Copyright (c) 1998-2017 Zend Technologies

$ php vendor/bin/phpunit 

Fatal error: Cannot use 'Object' as class name as it is reserved in /home/cebe/dev/yiisoft/yii2/framework/base/Object.php on line 77

[cebe]

We need to rename Object class but as far as I see we have not really discussed a name yet.
Imo Object is a really weird name for class as it is not an instance but a class. BaseObject for that would have just the same issue.

How about naming it what it realy is: BaseClass ?

[klimov-paul]

Should be ConfigurableObject or ConfigurableClass then, as it implements Configurable interface.

[cebe]

It implements two things: Configurable and Property feature. But I like the name ConfigurableClass.

[rob006]

@cebe Usually we deal with instances of this class, so IMO Object is more natural than Class.

[klimov-paul]

Properties are not the matter of interface or meaning and are not bound to just setters and getters.
For example: if you parse XML document using SimpleXML lib you will receive SimpleXMLElement object with virtual properties matching the source doument tags, which are not declared anyhow at SimpleXMLElement class itself.

Also logic put into Object::__set(), Object::__get() can be easily changed in its decendants completly, while demands put via implemented interface are mandatory.

[nkovacs]

Imo Object is a really weird name for class as it is not an instance but a class.

Class names describe the instances of that class, so the Object name was just fine, since instances of Object were objects. I would expect an instance of class Class to be a class. In Java, it is.

[klimov-paul]

Class keyword represents a set of objects, while object keyword represents a single object.
Over entire framework we follow convension which uses singular noun form instead of plural - same should be here.

[samdark]

How about just Configurable?

[klimov-paul]

How about just Configurable?

It is already taken by an interface.

[samdark]

Then ConfigurableClass sounds fine.

[rob006]

I really don't like using "class" as a part of name for... class. And I completely don't understand problems with using "object" in the same context. PHP already doing it, and this issue is the best example that "object" is more intuitive in this case - PHP 7.2 will introduce object typehint, not class.

[samdark]

Either object or class is fine to me. Let's vote. 👍 for class, 👎 for object.

[cebe]

Thanks for the comments, you are right, object makes more sense.

[samdark]

If we're going to have more in it than being configurable, lets rename it to BaseObject.