[RFC][DISCUSSION] Object type hint, now with added variance

(Oops, I forgot to inherit the interface:

 interface Factory {
     function make(...$args): object;
 }

 class FooFactory implements Factory {
     function make(...$args): Foo;
 }

sorry for the noise)

Hi Levi,

On Tue, Feb 14, 2017 at 11:55 AM, Dan Ackroyd danack@basereality.com
wrote:

Hi Levi,

Hi Levi,

For instance enumerations (or enums) are one possible type I can see us
adding that may not be objects.

I very much look forward to the RFC for enums, and have for some time.
When are you thinking of submitting it for discussion and voting?

I can understand your concerns. At the same time, I hope you can
understand that people won't want to put off introducing features that
they want in the meantime.

I think if you were able to give a timeline for when an Enum RFC could
be introduced, before the PHP 7.2 release, we could talk about whether
it would be right to hold off on this RFC for now.

Otherwise I suggest Michał updates the voting options, and we open the
voting in a week or so.

cheers
Dan

Let me clarify that I'm not against this object variance; there is
nothing intrinsic about object variance that prevents enums (or
typedefs/type aliases). Rather it's how it is achieving that
variance that is an issue. This is something that should ship along
with full covariance/contravariance and not be a special case which
may unintended side-effects later (such as preventing enums without
breaking BC). Does that make sense?

Here's a concrete compatibility concern. Let's assume we have the
following code:

interface Factory {
    function make(...$args): object;
}

class FooFactory {
    function make(...$args): Foo;
}

Currently the engine would not have to know anything about Foo to know
if it is a sub-type of object. It would not need to require it to even
be defined.

However, if at some point in the future we add non-object types it may
now error or autoload.

Since the engine is clueless about types until autoloading happens, this is
easily solvable by providing a marker syntax for non-object hints. For
instance function foo() : enym:MyEnum {}

The current (and valid) assumption by both the engine and userland
reflectors is that anything after the : in a return type declaration is
one of:

• bool
• array
• int
• float
• string
• callable
• void
• $classOrInterfaceName

Regardless of this RFC, and considered that object is an already reserved
keyword, you can't use the same syntax for enum types anyway, since you're
going to break a crapton of userland code.

The way to avoid the compatibility concern is to implement this
feature the same way we wold implement full covariance, which would
similarly need to know about the types involved.

Does that make more sense as to why the assumption that unknown types
are object types is an issue?

--

Given inline comments above, can we archive the enum discussion?

On Tue, Feb 14, 2017 at 11:55 AM, Dan Ackroyd danack@basereality.com
wrote:

Hi Levi,

On 24 November 2016 at 08:58, Dan Ackroyd danack@basereality.com
wrote:

Hi Levi,

For instance enumerations (or enums) are one possible type I can see
us
adding that may not be objects.

I very much look forward to the RFC for enums, and have for some time.
When are you thinking of submitting it for discussion and voting?

I can understand your concerns. At the same time, I hope you can
understand that people won't want to put off introducing features that
they want in the meantime.

I think if you were able to give a timeline for when an Enum RFC could
be introduced, before the PHP 7.2 release, we could talk about whether
it would be right to hold off on this RFC for now.

Otherwise I suggest Michał updates the voting options, and we open the
voting in a week or so.

cheers
Dan

Let me clarify that I'm not against this object variance; there is
nothing intrinsic about object variance that prevents enums (or
typedefs/type aliases). Rather it's how it is achieving that
variance that is an issue. This is something that should ship along
with full covariance/contravariance and not be a special case which
may unintended side-effects later (such as preventing enums without
breaking BC). Does that make sense?

Here's a concrete compatibility concern. Let's assume we have the
following code:

interface Factory {
    function make(...$args): object;
}

class FooFactory {
    function make(...$args): Foo;
}

Currently the engine would not have to know anything about Foo to know
if it is a sub-type of object. It would not need to require it to even
be defined.

However, if at some point in the future we add non-object types it may
now error or autoload.

The way to avoid the compatibility concern is to implement this
feature the same way we wold implement full covariance, which would
similarly need to know about the types involved.

Does that make more sense as to why the assumption that unknown types
are object types is an issue?

Thanks, this argument is convincing.

Overall, I think the utility of the object typehint is very limited. If
introducing an object typehint now will pose issues for an enum
implementation later (which I consider significantly more important), I
would prefer to defer its introduction until a later time.

People have pointed out that there will still be ways to implement enums
without breaking BC, either by prefixing enum type annotations with "enum",
or by making enum values objects. These suggestions may have merit, but
they should be evaluated on their own merit when the proposal comes up.
We should avoid being forced into a corner where we have to chose a
specific implementation due to BC concerns.

Nikita