Introducing "Array Of" RFC

10 years ago by Philip Sturgeon — view source

unread

Hey,

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

10 years ago by Andrea Faulds — view source

unread

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

I think this is a great proposal.

I have one question, however. Though I doubt it would be a frequent
usage, would { function (StdClass[][] $x) {} } work, for representing an
array of arrays?

Andrea Faulds
http://ajf.me/

10 years ago by Robert Stoll — view source

unread

Hey,

-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Wednesday, January 15, 2014 7:18 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Introducing "Array Of" RFC

Hey,

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

--

First of all, I really like the RFC, good idea, well done.

But about some details. I am not sure if I got the implementation right (haven't done any code contributions so far, so
I am not really familiar with the source code) but it seems that a check for NULL is implemented for the actual
parameter which is perfectly fine (done for other type hints as well) but it also checks if all members of an array are
not NULL and the check returns a failure if NULL is detected. I think that's wrong, NULL is a perfect valid entry in an
array.

Furthermore, what about type hints like the following ones:
function foo(int[] $qualities, callable[] $callables){}

Seems like they are not supported. But might be that I am totally wrong and did not understand the code

10 years ago by Andrea Faulds — view source

unread

But about some details. I am not sure if I got the implementation right (haven't done any code contributions so far, so
I am not really familiar with the source code) but it seems that a check for NULL is implemented for the actual
parameter which is perfectly fine (done for other type hints as well) but it also checks if all members of an array are
not NULL and the check returns a failure if NULL is detected. I think that's wrong, NULL is a perfect valid entry in an
array.

I agree with this. NULL should be considered a valid substitute for a
value of any type.

--
Andrea Faulds
http://ajf.me/

10 years ago by Robert Stoll — view source

unread

Furthermore, what about type hints like the following ones:
function foo(int[] $qualities, callable[] $callables){}

Seems like they are not supported. But might be that I am totally wrong and did not understand the code

Please forget about my question about type hint for int[], I forgot for a second that PHP does not support scalar type
hints.
However, the question about callable[] remains

10 years ago by Philip Sturgeon — view source

unread

Hey,

-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Wednesday, January 15, 2014 7:18 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Introducing "Array Of" RFC

Hey,

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

--

First of all, I really like the RFC, good idea, well done.

But about some details. I am not sure if I got the implementation right (haven't done any code contributions so far, so
I am not really familiar with the source code) but it seems that a check for NULL is implemented for the actual
parameter which is perfectly fine (done for other type hints as well) but it also checks if all members of an array are
not NULL and the check returns a failure if NULL is detected. I think that's wrong, NULL is a perfect valid entry in an
array.

Furthermore, what about type hints like the following ones:
function foo(int[] $qualities, callable[] $callables){}

Seems like they are not supported. But might be that I am totally wrong and did not understand the code

Ok, ignoring the int stuff as PHP doesn't generally do that. We don't
want to broach that topic here.

As for allowing null, this feature is currently intended as a
syntactic representation of:

foreach ($foos as $foo) {
if (! $foo instanceof Face) {
throw new Exception ('AAAGGGGGHHH!');
}
}

You are suggesting:

foreach ($foos as $foo) {
if (! is_null($foo) and ! $foo instanceof Face) {
throw new Exception ('AAAGGGGGHHH!');
}
}

How do people feel about that?

10 years ago by Kristopher — view source

unread

On Wed, Jan 15, 2014 at 3:09 PM, Philip Sturgeon pjsturgeon@gmail.comwrote:

Ok, ignoring the int stuff as PHP doesn't generally do that. We don't
want to broach that topic here.

As for allowing null, this feature is currently intended as a
syntactic representation of:

foreach ($foos as $foo) {
if (! $foo instanceof Face) {
throw new Exception ('AAAGGGGGHHH!');
}
}

You are suggesting:

foreach ($foos as $foo) {
if (! is_null($foo) and ! $foo instanceof Face) {
throw new Exception ('AAAGGGGGHHH!');
}
}

How do people feel about that?

PHP disallows passing NULL in a function like:

function foo(MyClass $obj) {}

Unless you explicitly allow it to be null:

function foo(MyClass $obj = null) { }

The first instance will throw an error:

PHP Catchable fatal error: Argument 1 passed to foo() must be an instance
of MyClass, null given

I think this implementation (MyClass[]) should be consistent this when
passing null.

10 years ago by Marco Pivetta — view source

unread

I think this implementation (MyClass[]) should be consistent this when
passing null.

Even without the argument of consistency, the new syntax would be pretty
much useless if NULL was allowed, since every method would have start
with a call to array_filter.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

10 years ago by Robert Stoll — view source

unread

-----Original Message-----
From: Marco Pivetta [mailto:ocramius@gmail.com]
Sent: Wednesday, January 15, 2014 9:25 PM
To: Kristopher
Cc: Philip Sturgeon; Robert Stoll; internals@lists.php.net
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC

I think this implementation (MyClass[]) should be consistent this when
passing null.

Even without the argument of consistency, the new syntax would be pretty
much useless if NULL was allowed, since every method would have start
with a call to array_filter.

Marco Pivetta

You could also think in a different way. NULL is basically a valid entry in an array. If you apply the restriction as implemented in the pull request then one cannot use the new syntax for arrays which allow NULL, that seems odd to me as well. Especially since class/interface-types are reference types and I regard NULL as something equal to a null-pointer.
Furthermore, if one does not want to support NULL in an array currently, then one probably already uses an own collection implementation which already triggers and error, throws an exception respectively, when one tries to add NULL to the collection.

It seems the pull request does not yet support multidimensional arrays (e.g. Foo[][]) but if we would stick to the restriction now then the consequence should be that this restriction also applies to multi-dimensional arrays. In my opinion, we would spoil valid use cases this way for RFC and for future ones (in the case multi-dimensional arrays will be introduced, other concepts could be affected as well).

Thus I would suggest to remove this check and provide a further SPL data structure implementation instead which does not allow null as entry if this feature is really needed. Seems more appropriate to me than making a restriction in the language itself.

10 years ago by Philip Sturgeon — view source

unread

-----Original Message-----
From: Marco Pivetta [mailto:ocramius@gmail.com]
Sent: Wednesday, January 15, 2014 9:25 PM
To: Kristopher
Cc: Philip Sturgeon; Robert Stoll; internals@lists.php.net
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC

I think this implementation (MyClass[]) should be consistent this when
passing null.

Even without the argument of consistency, the new syntax would be pretty
much useless if NULL was allowed, since every method would have start
with a call to array_filter.

Marco Pivetta

You could also think in a different way. NULL is basically a valid entry in an array. If you apply the restriction as implemented in the pull request then one cannot use the new syntax for arrays which allow NULL, that seems odd to me as well. Especially since class/interface-types are reference types and I regard NULL as something equal to a null-pointer.
Furthermore, if one does not want to support NULL in an array currently, then one probably already uses an own collection implementation which already triggers and error, throws an exception respectively, when one tries to add NULL to the collection.

It seems the pull request does not yet support multidimensional arrays (e.g. Foo[][]) but if we would stick to the restriction now then the consequence should be that this restriction also applies to multi-dimensional arrays. In my opinion, we would spoil valid use cases this way for RFC and for future ones (in the case multi-dimensional arrays will be introduced, other concepts could be affected as well).

Thus I would suggest to remove this check and provide a further SPL data structure implementation instead which does not allow null as entry if this feature is really needed. Seems more appropriate to me than making a restriction in the language itself.

I would assume that the majority of people will be using this syntax
to ensure the types of objects.

In English:

"I would like everything in this array to be Foo."

That is much more programatically useful in my opinion than:

"I would like everything in this array to be Foo or maybe null."

If we go with the latter then I still have no idea what is in this
variable, and have to do a whole bunch of checking or
array_filter()ing, otherwise I am doing this:

$possibleNullValue->getInfo(); // BOOM!

Even if there are use-cases for allowing them I would suggest that
there are probably more use-cases for denying them.

10 years ago by Robert Stoll — view source

unread

-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Wednesday, January 15, 2014 10:25 PM
To: Robert Stoll
Cc: Marco Pivetta; Kristopher; internals@lists.php.net
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC

-----Original Message-----
From: Marco Pivetta [mailto:ocramius@gmail.com]
Sent: Wednesday, January 15, 2014 9:25 PM
To: Kristopher
Cc: Philip Sturgeon; Robert Stoll; internals@lists.php.net
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC

I think this implementation (MyClass[]) should be consistent this when
passing null.

Even without the argument of consistency, the new syntax would be pretty
much useless if NULL was allowed, since every method would have start
with a call to array_filter.

Marco Pivetta

You could also think in a different way. NULL is basically a valid entry in an array. If you apply the restriction
as
implemented in the pull request then one cannot use the new syntax for arrays which allow NULL, that seems odd to me
as
well. Especially since class/interface-types are reference types and I regard NULL as something equal to a
null-pointer.
Furthermore, if one does not want to support NULL in an array currently, then one probably already uses an own
collection implementation which already triggers and error, throws an exception respectively, when one tries to add
NULL
to the collection.

It seems the pull request does not yet support multidimensional arrays (e.g. Foo[][]) but if we would stick to the
restriction now then the consequence should be that this restriction also applies to multi-dimensional arrays. In my
opinion,
we would spoil valid use cases this way for RFC and for future ones (in the case multi-dimensional arrays will be
introduced,
other concepts could be affected as well).

Thus I would suggest to remove this check and provide a further SPL data structure implementation instead which does
not allow null as entry if this feature is really needed. Seems more appropriate to me than making a restriction in
the
language itself.

I would assume that the majority of people will be using this syntax
to ensure the types of objects.

In English:

"I would like everything in this array to be Foo."

That is much more programatically useful in my opinion than:

"I would like everything in this array to be Foo or maybe null."

If we go with the latter then I still have no idea what is in this
variable, and have to do a whole bunch of checking or
array_filter()ing, otherwise I am doing this:

$possibleNullValue->getInfo(); // BOOM!

Even if there are use-cases for allowing them I would suggest that
there are probably more use-cases for denying them.

--

Fair enough, the example with the English sentence makes pretty much sense from an average user's point of view and thus
most PHP users would probably agree with you (don't take it wrong, I don't imply you are average or something similar).
However, this should not be a decision based on whether many people are preferring it this way or the other way round in
my opinion, since the restriction is going to make it impossible to use it for the use cases where NULL is a valid
entry.
So, we should ask ourselves, do we really want to exclude a whole bunch of valid use cases or should we decline the
restriction and put more effort in providing alternatives for non-null -containing collections.

See, if we do not introduce the restriction and provide a non-null-containing collection then all use cases can be
supported. That is the way to go IMO.
Or do you have another idea how one can specify that the array can contain null?
And please consider, if you should suggest "function foo(Foo[] $foo=null)" implies that $foo can also contain NULL then
we have another vague concept in PHP which has a double meaning -> $foo can be NULL and entries in $foo can be NULL. But
maybe one does not want to allow NULL for $foo but only for members of $foo.

10 years ago by Crypto Compress — view source

unread

Hello,

since there is an option for nullable type-hinted variables, it may be
usefull to explicitly allow null values in a type-hinted array too.

e.g.: function foo(Bar[null] = null)

to consider:

null is not an object
null is not "nothing"
null is not "not defined"
null is not a/any type (even documentation states so)

Java: only reference types are nullable
c#: only if explicitly defined
sql: only if explicitly defined

cryptocompress

10 years ago by Andrea Faulds — view source

unread

e.g.: function foo(Bar[null] = null)

I'd prefer the ? syntax for nullables that C# has. I'm imagining
something like this:

function foo(Bar? $a) {} // $a is Bar/null
function foo(Bar?[] $a) {} // $a is array of Bars/nulls
function foo(Bar[]? $a) {} // $a is array of Bars, or null
function foo(Bar?[]? $a) {} // $a is array of Bars/nulls, or null

--
Andrea Faulds
http://ajf.me/

10 years ago by Robert Stoll — view source

unread

-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Thursday, January 16, 2014 12:54 AM
To: Crypto Compress; internals@lists.php.net
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC

e.g.: function foo(Bar[null] = null)

I'd prefer the ? syntax for nullables that C# has. I'm imagining
something like this:

function foo(Bar? $a) {} // $a is Bar/null
function foo(Bar?[] $a) {} // $a is array of Bars/nulls
function foo(Bar[]? $a) {} // $a is array of Bars, or null
function foo(Bar?[]? $a) {} // $a is array of Bars/nulls, or null

--
Andrea Faulds
http://ajf.me/

--

I like Andrea's proposal, this way we can support all scenarios.
It is possible to define that NULL is a valid entry in an array and we would stick to the same decision as for actual
parameters, namely that one has to define explicitly that null is a valid entry. This would make me happy and I suppose
also Philip.

Just as side notice, this syntax would also give the chance for PHP to get rid of the double meaning of "=null" in a
later version. I am talking about the following case:
function foo(Foo $a=null, $b=1){}
Where one might not want to specify that $a is optional but cannot do it differently at the moment - with the additional
? it could change :)

10 years ago by Martin Keckeis — view source

unread

2014/1/16 Robert Stoll php@tutteli.ch

-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Thursday, January 16, 2014 12:54 AM
To: Crypto Compress; internals@lists.php.net
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC

e.g.: function foo(Bar[null] = null)

I'd prefer the ? syntax for nullables that C# has. I'm imagining
something like this:

function foo(Bar? $a) {} // $a is Bar/null
function foo(Bar?[] $a) {} // $a is array of Bars/nulls
function foo(Bar[]? $a) {} // $a is array of Bars, or null
function foo(Bar?[]? $a) {} // $a is array of Bars/nulls, or null

--
Andrea Faulds
http://ajf.me/

--

I like Andrea's proposal, this way we can support all scenarios.
It is possible to define that NULL is a valid entry in an array and we
would stick to the same decision as for actual
parameters, namely that one has to define explicitly that null is a valid
entry. This would make me happy and I suppose
also Philip.

Just as side notice, this syntax would also give the chance for PHP to get
rid of the double meaning of "=null" in a
later version. I am talking about the following case:
function foo(Foo $a=null, $b=1){}
Where one might not want to specify that $a is optional but cannot do it
differently at the moment - with the additional
? it could change :)

--

1 for the RFC

But if i'm not completely wrong, there is performance decrease instead of
increase in your tests?
https://gist.github.com/krakjoe/8444591

[joe@fiji php-src]$ sapi/cli/php isTest.php 10000
objects: 10000
arrayof: 0.00645113
instanceof: 0.00560713

10 years ago by php@tutteli.ch — view source

unread

1 for the RFC

But if i'm not completely wrong, there is performance decrease instead of
increase in your tests?
https://gist.github.com/krakjoe/8444591

[joe@fiji php-src]$ sapi/cli/php isTest.php 10000
objects: 10000
arrayof: 0.00645113
instanceof: 0.00560713

I gave the RFC a few more thoughts and came to the conclusion that it
does not fit to PHP (due to the performance penalties involved).
The syntax merely hide an ugly design. If you would write the same in
normal PHP then probably everyone would agree that it is bad design.
Following an example (doesn't really make sense but outlines the bad design)

function foo(Foo[] $foos){
if(count($foos) > 0){
$a = array_pop($foos);
//do something
foo($foos);
}
}

Is equivalent to

function foo(array $arr){
foreach($arr as $v){
if(!($v instanceof Foo)){
//trigger_error
}
}
if(count($foos) > 0){
$a = array_pop($foos);
//do something
foo($foos);
}
}

The check adds runtime complexity to the function for each call which
is obviously not necessary (once would be good enough). And I doubt
that users would actually make sure that the check is only performed
once and even if you would argue that one should write it as follows:

function bar(Foo[] $foos){
foo($foos);
}
function foo(array $foos){
if(count($foos) > 0){
$a = array_pop($foos);
//do something
foo($foos);
}
}

Then it is still bad design compared to a collection which actually
does the check during the addition of elements.
Although, I like the effort to make PHP somewhat more type safe I am
-1 for this RFC, the implementation respectively. If we want typed
arrays then the array needs to carry the type to be efficient.

10 years ago by Matthieu Napoli — view source

unread

Le 16/01/2014 11:01, php@tutteli.ch a écrit :

1 for the RFC

But if i'm not completely wrong, there is performance decrease instead of
increase in your tests?
https://gist.github.com/krakjoe/8444591

[joe@fiji php-src]$ sapi/cli/php isTest.php 10000
objects: 10000
arrayof: 0.00645113
instanceof: 0.00560713

I gave the RFC a few more thoughts and came to the conclusion that it
does not fit to PHP (due to the performance penalties involved).

The performance penalty is the same as if you were type-checking yourself.

And on the gist linked, we can see that the results vary a lot (not
enough iterations probably), it's easy to take only the worst one. Here,
I'll take the one where the numbers are inversed to "prove" my point:

[joe@fiji php-src]$ sapi/cli/php isTest.php 1000
objects: 1000
arrayof: 0.00080991
instanceof: 0.00086308

The syntax merely hide an ugly design. If you would write the same in
normal PHP then probably everyone would agree that it is bad design.

How is type checking a bad design?

Between:

function (array $foos) {
foreach ($foos as $foo) {
if (! $foo instanceof Foo) {
throw new InvalidArgumentException("...");
}
$foo->bar();
}
}

and:

function (array $foos) {
foreach ($foos as $foo) {
$foo->bar(); // BOOM, fatal error if not correct object given
}
}

which one is worse?

It's the same problem than this:

function ($foo) {
$foo->bar(); // fatal error if not correct object given
}

and this:

function (Foo $foo) {
$foo->bar();
}

Following an example (doesn't really make sense but outlines the bad
design)

function foo(Foo[] $foos){
if(count($foos) > 0){
$a = array_pop($foos);
//do something
foo($foos);
}
}

Is equivalent to

function foo(array $arr){
foreach($arr as $v){
if(!($v instanceof Foo)){
//trigger_error
}
}
if(count($foos) > 0){
$a = array_pop($foos);
//do something
foo($foos);
}
}

The check adds runtime complexity to the function for each call which is
obviously not necessary (once would be good enough). And I doubt that
users would actually make sure that the check is only performed once and
even if you would argue that one should write it as follows:

function bar(Foo[] $foos){
foo($foos);
}
function foo(array $foos){
if(count($foos) > 0){
$a = array_pop($foos);
//do something
foo($foos);
}
}

Then it is still bad design compared to a collection which actually does
the check during the addition of elements.
Although, I like the effort to make PHP somewhat more type safe I am -1
for this RFC, the implementation respectively. If we want typed arrays
then the array needs to carry the type to be efficient.

Matthieu

10 years ago by Yasuo Ohgaki — view source

unread

Hi all,

On Thu, Jan 16, 2014 at 7:49 PM, Matthieu Napoli matthieu@mnapoli.frwrote:

The syntax merely hide an ugly design. If you would write the same in

normal PHP then probably everyone would agree that it is bad design.

How is type checking a bad design?

Type checking is not bad.

Alternatively, DbC (design by contract) may be useful.
Cleaner and could be faster.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Chris Wright — view source

unread

The performance penalty is the same as if you were type-checking yourself.

(Sorry if I'm stepping on your toes here Joe, since it was you who
pointed this out to me):

This is not completely true. With arrayof, there are two iterations of
the passed value - one in C and one in PHP, vs only one iteration in
the foreach/instanceof approach.

However:

as you point out, the performance penalty for the check is
negligible if it even exists
if you don't use the syntax there is no penalty whatsoever

so for me this is a complete non-issue. The concise syntax and strong
semantic possibilities this brings far outweigh a few microseconds of
slowdown.

Thanks, Chris

10 years ago by Martin Keckeis — view source

unread

2014/1/16 Matthieu Napoli matthieu@mnapoli.fr

Le 16/01/2014 11:01, php@tutteli.ch a écrit :

1 for the RFC

But if i'm not completely wrong, there is performance decrease instead of
increase in your tests?
https://gist.github.com/krakjoe/8444591

[joe@fiji php-src]$ sapi/cli/php isTest.php 10000
objects: 10000
arrayof: 0.00645113
instanceof: 0.00560713

I gave the RFC a few more thoughts and came to the conclusion that it
does not fit to PHP (due to the performance penalties involved).

The performance penalty is the same as if you were type-checking yourself.

And on the gist linked, we can see that the results vary a lot (not enough
iterations probably), it's easy to take only the worst one. Here, I'll take
the one where the numbers are inversed to "prove" my point:

[joe@fiji php-src]$ sapi/cli/php isTest.php 1000
objects: 1000
arrayof: 0.00080991
instanceof: 0.00086308

Yes i saw the good result too. Just wondered why native PHP was slower
sometimes...

10 years ago by Robert Stoll — view source

unread

How is type checking a bad design?

Between:

function (array $foos) {
foreach ($foos as $foo) {
if (! $foo instanceof Foo) {
throw new InvalidArgumentException("...");
}
$foo->bar();
}
}

and:

function (array $foos) {
foreach ($foos as $foo) {
$foo->bar(); // BOOM, fatal error if not correct object given
}
}

which one is worse?

You got me wrong, I don't think that type checking as such is bad but type checking in the way the RFC promotes it is bad design IMO. If I expect an array with members of a certain type (regardless if including null or not) then I would not write any of the above code because this is exactly the bad design I was writing about.
Wouldn't you agree with me that it would be better to type check the entries when they are added rather than during each function call?
Imagine function foo(Foo[] $foos){} which calls bar and baz which in turn call several other functions which all have the same type hint Foo[].
The result would be that you have increased your runtime complexity by the factor of function calls. That's really ugly and I don't think that the language itself should promote such bad design. If you go further and support multi-dimensional arrays the same way then you would add a complexity of n*m for each function call with such a type hint.

However, I like the basic idea of the RFC, namely typed arrays. I think a better implementation would be to introduce that an array holds (visible only internally - could be exposed to userland later) the defined type and performs the necessary checks during addition and therefore the runtime complexity for the type hint checks would no longer be linear but constant. Yet, it is probably better to introduce another internal data structure for this purpose in order that the type hint "array" does not suffer from the additional checks.
An alternative approach, without changing the language, would be to provide an additional SPL data structure instead which performs the type check during the addition of an entry.

Nevertheless, the implementation of the RFC as such is not useless. We could introduce a function is_arrayOf(array $arr, $type, $nullable=false) which could perform the check as implemented in the pull request (including the nullable option). And I suppose you can come up with valid uses cases where such a check makes actually sense and worth the new function.

10 years ago by Julien Pauli — view source

unread

How is type checking a bad design?

Between:

function (array $foos) {
foreach ($foos as $foo) {
if (! $foo instanceof Foo) {
throw new InvalidArgumentException("...");
}
$foo->bar();
}
}

and:

function (array $foos) {
foreach ($foos as $foo) {
$foo->bar(); // BOOM, fatal error if not correct object given
}
}

which one is worse?

You got me wrong, I don't think that type checking as such is bad but type checking in the way the RFC promotes it is bad design IMO. If I expect an array with members of a certain type (regardless if including null or not) then I would not write any of the above code because this is exactly the bad design I was writing about.
Wouldn't you agree with me that it would be better to type check the entries when they are added rather than during each function call?
Imagine function foo(Foo[] $foos){} which calls bar and baz which in turn call several other functions which all have the same type hint Foo[].
The result would be that you have increased your runtime complexity by the factor of function calls. That's really ugly and I don't think that the language itself should promote such bad design. If you go further and support multi-dimensional arrays the same way then you would add a complexity of n*m for each function call with such a type hint.

I'm absolutely +1 with such a statement.

However, I like the basic idea of the RFC, namely typed arrays. I think a better implementation would be to introduce that an array holds (visible only internally - could be exposed to userland later) the defined type and performs the necessary checks during addition and therefore the runtime complexity for the type hint checks would no longer be linear but constant. Yet, it is probably better to introduce another internal data structure for this purpose in order that the type hint "array" does not suffer from the additional checks.
An alternative approach, without changing the language, would be to provide an additional SPL data structure instead which performs the type check during the addition of an entry.

Yes, yes and yes again. +1

This RFC shows that we lack "array of" as a whole structure in PHP,
like Java has Vectors. We already talked about this in the past.
I'm in favor of designing a new "typed array" structure , instead of
adding a new syntax that checks things at runtime of every function
call, mainly by iterating over the array at runtime.
I dont think we can accept such a penalty, particulary in the case of
nested function calls with the same signature, all requiring the
engine to iterate for type checking.

Julien.P

10 years ago by Chris Wright — view source

unread

I'm in favor of designing a new "typed array" structure , instead of
adding a new syntax that checks things at runtime of every function
call, mainly by iterating over the array at runtime.

This, while useful, doesn't solve the same problem as this RFC is solving.
You wouldn't be able to type hint for the type contained within the
structure without some form of new syntax.

What if we did both? So that the new syntax actually expects an
SplTypedArray (or whatever you want to call it) and if an instance of this
structure is passed the class entry attached to the structure can be used
as an O(1) shortcut, but if an array is passed it is run through
SplTypedArray::fromArray(), allowing users to pass an array and take the
performance hit if they want to.

Thanks, Chris

10 years ago by Jannik Zschiesche — view source

unread

Hi,

Am Mittwoch, 15. Januar 2014 um 23:00 schrieb Robert Stoll:

Fair enough, the example with the English sentence makes pretty much sense from an average user's point of view and thus
most PHP users would probably agree with you (don't take it wrong, I don't imply you are average or something similar).
However, this should not be a decision based on whether many people are preferring it this way or the other way round in
my opinion, since the restriction is going to make it impossible to use it for the use cases where NULL is a valid
entry.
So, we should ask ourselves, do we really want to exclude a whole bunch of valid use cases or should we decline the
restriction and put more effort in providing alternatives for non-null -containing collections.

See, if we do not introduce the restriction and provide a non-null-containing collection then all use cases can be
supported. That is the way to go IMO.
Or do you have another idea how one can specify that the array can contain null?
And please consider, if you should suggest "function foo(Foo[] $foo=null)" implies that $foo can also contain NULL then
we have another vague concept in PHP which has a double meaning -> $foo can be NULL and entries in $foo can be NULL. But
maybe one does not want to allow NULL for $foo but only for members of $foo.

if you pass an array which mixes both objects and null and you want to work on the objects, you still have to do the checks yourself:

function f (A[] $list)
{
foreach ($list as $entry)
{
if (!is_null($entry))
{
$entry->doSth();
}
}
}

But in this case you could just omit the type hint and check it internally:

function f ($list)
{
foreach ($list as $entry)
{
if (!is_null($entry) && ($entry instanceof A))
{
$entry->doSth();
}
}
}

The thought of this proposal is that the complete checking is done with just the type hint.
And allowing null would make this obsolete.

Also, you would then have the duplicated runtime impact:
you need to check the array twice:

check for null & A (type hint)
check for A

instead of just one.

Cheers
Jannik

10 years ago by Robert Stoll — view source

unread

if you pass an array which mixes both objects and null and you want to work on the objects, you still have to do the checks
yourself:

I agree, in this case it would be useful if Foo[] excludes members which are NULL. I guess I did not make it clear enough what I tried to point out.
A new feature should not just work for some use cases because the majority of people would use it this way but also for other use cases as long as they are valid.
So my point was that the RFC has to consider both cases, once excluding NULL and once with NULL as valid entry. As long as it doesn't it is incomplete IMO.
Andrea made a nice suggestion for the syntax and I would go for it:

function foo(Bar? $a) {} // $a is Bar/null
function foo(Bar?[] $a) {} // $a is array of Bars/nulls
function foo(Bar[]? $a) {} // $a is array of Bars, or null
function foo(Bar?[]? $a) {} // $a is array of Bars/nulls, or null

10 years ago by Lars Strojny — view source

unread

Hi Marco, everyone,

[...]

Even without the argument of consistency, the new syntax would be pretty
much useless if NULL was allowed, since every method would have start
with a call to array_filter.

Very much true. Allowing null would introduce a huge hole for null pointer errors.

cu,
Lars

10 years ago by Lazare Inepologlou — view source

unread

2014/1/15 Philip Sturgeon pjsturgeon@gmail.com

Hey,

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

Hello,

this is a nice proposal.

I hope that it is not limited to arrays only... All tranversables should be
acceptable (as they are acceptable for variadiac functions). Otherwise this
will lead to unnecessary (and costly) convertions.

Lazare INEPOLOGLOU
Ingénieur Logiciel

10 years ago by johannes@schlueters.de — view source

unread

I hope that it is not limited to arrays only... All tranversables
should be acceptable (as they are acceptable for variadiac functions).
Otherwise this will lead to unnecessary (and costly) convertions.

those can't be checked.

johannes

10 years ago by Nikita Popov — view source

unread

On Wed, Jan 15, 2014 at 8:49 PM, Lazare Inepologlou linepogl@gmail.comwrote:

2014/1/15 Philip Sturgeon pjsturgeon@gmail.com

Hey,

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

Hello,

this is a nice proposal.

I hope that it is not limited to arrays only... All tranversables should be
acceptable (as they are acceptable for variadiac functions). Otherwise this
will lead to unnecessary (and costly) convertions.

An array is not just traversable - it is also array accessible and
countable, as well as passable-to-array-functions. Allowing to pass
Traversables to an array typehint violates the type constraint.

Nikita

10 years ago by Philip Sturgeon — view source

unread

2014/1/15 Philip Sturgeon pjsturgeon@gmail.com

Hey,

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

Hello,

this is a nice proposal.

I hope that it is not limited to arrays only... All tranversables should be
acceptable (as they are acceptable for variadiac functions). Otherwise this
will lead to unnecessary (and costly) convertions.

Lazare INEPOLOGLOU
Ingénieur Logiciel

Currently function (array Foo) is ONLY arrays, not number of
interfaces will change that.

This RFC keeps to the same logic, but a later RFC could (and IMO
absolutely should) address this. I would suggest that this is a
different issue, and should be kept separate.

10 years ago by Lars Strojny — view source

unread

Hi Philip,

[...]

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

Very nice proposal. One thing I noticed by reading the code (and the tests9 is that it bails out at the first offender. Given I hint for Foo[], and pass [new Foo(), new Bar(), new Baz()] it will only inform me about Bar violating Foo. I would like to have a more descriptive error message that contains both Bar and Baz.

cu,
Lars

10 years ago by Nikita Nefedov — view source

unread

Hi Philip,

[...]

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

Very nice proposal. One thing I noticed by reading the code (and the
tests9 is that it bails out at the first offender. Given I hint for
Foo[], and pass [new Foo(), new Bar(), new Baz()] it will only inform me
about Bar violating Foo.

So will calling foo(""); where foo's definition is foo(Asd $asd, Qwe $qwe);
I, for one, don't see a problem here.

10 years ago by Chris Wright — view source

unread

Given I hint for Foo[], and pass [new Foo(), new Bar(), new Baz()] it will
only inform me about Bar violating Foo. I would like to have a more descriptive
error message that contains both Bar and Baz.

While I see where you're coming from with this, it's non-trial to
implement this in a sane way, both in code and to handle every
possible scenario in a logical way. Suppose I pass an array or 10000
objects which instances of 10000 different classes which do not
satisfy the type hint? I guess you'd want to do something like

<= 3 offenders - give their class names and indices

3 offenders - give an error along the lines "passed array elements are completely wrong" (or maybe report first three and append a "and other errors")

...but IMO the complexity this would add is not worth the effort. From
a consistency point of view it should just use the same error logic as
the shiny new variadics feature - which also bails out at the first
offender.

Thanks, Chris

10 years ago by Lester Caine — view source

unread

Philip Sturgeon wrote:

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

I'm quite happy to put my hands up and say that despite having been programming
since the early 70's some of these 'essential facilities' are simply going over
my head. I've programmed with 'strict' languages and had to work around their
restrictions in the past, so the 'loose' format of PHP used to be a pleasure. So
all of these 'improvements' to keep to nibble away at the that freedom is a
pain. My IDE provides all of the 'type-hinting' that I need and a lot more
besides, totally outside the final code base. Many of the e_strict rules cause
problems resulting in a lot of duplication of code, adding facilities which
create more hinting/type checks still seems backwards.

This may just be my misunderstanding the OO basis people are working on, and
many of my 'objects' are persisted directly in the database, so the array of
elements is simply a record from the database. That record may have a type field
so that the resulting array is a mixture of types of object, but all of the same
base class. As with other additions made, I don't understand where this
'improved type-hinting' fits into the general development of PHP? How much code
will actually benefit from this addition, and how much will simply ignore it?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

10 years ago by Sara Golemon — view source

unread

https://wiki.php.net/rfc/arrayof

I'm going to fowl up this conversation by describing what HHVM's Hack
syntax does for this. Partly to encourage PHP to do the same, partly
to just lay out the edge cases we thought about on the way to
developing the syntax we landed with.

Generics Syntax - Allows creation of typed classes which repeat
common functionality with specific implementations
class Foo<T> {
protected T $foo;

public function getFoo(): T {
return $this->foo;
}

pubilc function setFoo(T $foo) {
$this->foo = $foo;
}
}

$f = new Foo<Bar>();
$f->setFoo(new Bar());
$b = $f->getFoo();

Typed arrays - Arrays are a special primitive which can be typed as
implicitly or explicitly numerically indexed, or associative, and to
specific types:
array<Tv> or array<Tk,Tv>

function foo(array<Bar> $numIdxArrayOfBar, array<int,Baz>
$numIdxArrayOfBaz, array<string,$Bong> $assocArrayOfBong) { ... }

Since the value type is unconstrained, it can be a generic type as
well, so a numerically indexed array of associative arrays of strings
would look like array<array<string,string>> and so on.

Nullable types - Any type preceeded by a question mark may be that
type or null:
function foo(?Bar $barOrNull, Baz $bar, ?Blong $blongOrNull) {...}
Soft types - Any type preceeded by an at sign is hinted as that
type, but not checked:
function foo(@Bar $IHopeYoureABarObject) {...}

Within the scope of this RFC, I want to encourage
array<Tv>/array<Tk,Tv> syntax (with nullable/soft modifiers) as I
think they cover every edge case presented by this discussion so far.
It also covers elements not handled by the proposed syntax (index
types). The syntax will be familiar to developers coming from C++ and
it leaves room to entertain generics in general.

-Sara

10 years ago by Robert Stoll — view source

unread

Hey Sara,

Typed arrays - Arrays are a special primitive which can be typed as
implicitly or explicitly numerically indexed, or associative, and to
specific types:
array<Tv> or array<Tk,Tv>

Out of curiosity, does HHVM support both use cases: NULL as a valid member and NULL as an error?
If so, how does the syntax differ?

10 years ago by Sara Golemon — view source

unread

Typed arrays - Arrays are a special primitive which can be typed as
implicitly or explicitly numerically indexed, or associative, and to
specific types:
array<Tv> or array<Tk,Tv>

Out of curiosity, does HHVM support both use cases: NULL as a valid member and NULL as an error?
If so, how does the syntax differ?

That's captured via Nullable types.

array<Foo> is an array of Foo objects (nulls not allowed).
array<?Foo> is an array of (Foo Objects or NULL)

-Sara

10 years ago by Yasuo Ohgaki — view source

unread

Hi all,

https://wiki.php.net/rfc/arrayof

I'm going to fowl up this conversation by describing what HHVM's Hack
syntax does for this. Partly to encourage PHP to do the same, partly
to just lay out the edge cases we thought about on the way to
developing the syntax we landed with.

Generics Syntax - Allows creation of typed classes which repeat
common functionality with specific implementations
class Foo<T> {
protected T $foo;

public function getFoo(): T {
return $this->foo;
}

pubilc function setFoo(T $foo) {
$this->foo = $foo;
}
}

$f = new Foo<Bar>();
$f->setFoo(new Bar());
$b = $f->getFoo();

Typed arrays - Arrays are a special primitive which can be typed as
implicitly or explicitly numerically indexed, or associative, and to
specific types:
array<Tv> or array<Tk,Tv>

function foo(array<Bar> $numIdxArrayOfBar, array<int,Baz>
$numIdxArrayOfBaz, array<string,$Bong> $assocArrayOfBong) { ... }

Since the value type is unconstrained, it can be a generic type as
well, so a numerically indexed array of associative arrays of strings
would look like array<array<string,string>> and so on.

Nullable types - Any type preceeded by a question mark may be that
type or null:
function foo(?Bar $barOrNull, Baz $bar, ?Blong $blongOrNull) {...}

Soft types - Any type preceeded by an at sign is hinted as that
type, but not checked:
function foo(@Bar $IHopeYoureABarObject) {...}

Within the scope of this RFC, I want to encourage
array<Tv>/array<Tk,Tv> syntax (with nullable/soft modifiers) as I
think they cover every edge case presented by this discussion so far.
It also covers elements not handled by the proposed syntax (index
types). The syntax will be familiar to developers coming from C++ and
it leaves room to entertain generics in general.

I prefer generics syntax.
It's rather common syntax and has more abilities.
It's better to have common syntax with HHVM, too.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Andrea Faulds — view source

unread

https://wiki.php.net/rfc/arrayof

I'm going to fowl up this conversation by describing what HHVM's Hack
syntax does for this. Partly to encourage PHP to do the same, partly
to just lay out the edge cases we thought about on the way to
developing the syntax we landed with.

Generics Syntax - Allows creation of typed classes which repeat
common functionality with specific implementations
class Foo<T> {
protected T $foo;

public function getFoo(): T {
return $this->foo;
}

pubilc function setFoo(T $foo) {
$this->foo = $foo;
}
}

$f = new Foo<Bar>();
$f->setFoo(new Bar());
$b = $f->getFoo();

Typed arrays - Arrays are a special primitive which can be typed as
implicitly or explicitly numerically indexed, or associative, and to
specific types:
array<Tv> or array<Tk,Tv>

function foo(array<Bar> $numIdxArrayOfBar, array<int,Baz>
$numIdxArrayOfBaz, array<string,$Bong> $assocArrayOfBong) { ... }

Since the value type is unconstrained, it can be a generic type as
well, so a numerically indexed array of associative arrays of strings
would look like array<array<string,string>> and so on.

Nullable types - Any type preceeded by a question mark may be that
type or null:
function foo(?Bar $barOrNull, Baz $bar, ?Blong $blongOrNull) {...}

Soft types - Any type preceeded by an at sign is hinted as that
type, but not checked:
function foo(@Bar $IHopeYoureABarObject) {...}

Within the scope of this RFC, I want to encourage
array<Tv>/array<Tk,Tv> syntax (with nullable/soft modifiers) as I
think they cover every edge case presented by this discussion so far.
It also covers elements not handled by the proposed syntax (index
types). The syntax will be familiar to developers coming from C++ and
it leaves room to entertain generics in general.

-Sara

After a little thought, I think I'd rather we use the HHVM syntax here.
Having "Array" for an untyped array but "Bar[]" for a typed one is
silly. "Array" and "Array<Bar>" make more sense. Being able to type keys
would be nice, too.

However, I have but one little issue with the HHVM syntax. Why is the ?
before the type name? I much prefer the C#-style Bar? to this confusing
?Bar. I suppose this is only a minor issue, though.

--
Andrea Faulds
http://ajf.me/

10 years ago by Sara Golemon — view source

unread

However, I have but one little issue with the HHVM syntax. Why is the ?
before the type name? I much prefer the C#-style Bar? to this confusing
?Bar. I suppose this is only a minor issue, though.

Two reasons come to mind, both essentially aesthetic:

Symbol crowding: function foo(array? &$bar) { }
bar by ref expects array, but may take null (which is perfectly common
for a by-ref variable). Trouble is, '? &$' is starting to look
perlish.
Generic expansion:
Prefix: function foo(?array<Bar<?int>> $baz)...
Suffix: function foo(array<Bar<int?>>? $bar)...

Both proclaim a nullable array of non-nullable Bar objects of nullable
type int. The prefix version makes it much more obvious which '?'
goes with which portion of the type structure.

function foo(array?<Bar<int?>> $baz)... sounds tempting, but some
shift/reduce conflicts start to emerge out of that stacking of tokens.
Resolvable, of course, but complicating the parser rules over a bit
of aesthetics like that.... You can't see it, but I've got my frownie
face on right now.

-Sara

P.S. - I'm not voting for or against anything at this point either.
Just offering input during discussion phase, as we're all meant to. :)

10 years ago by Joe Watkins — view source

unread

However, I have but one little issue with the HHVM syntax. Why is the ?
before the type name? I much prefer the C#-style Bar? to this confusing
?Bar. I suppose this is only a minor issue, though.

Two reasons come to mind, both essentially aesthetic:

Symbol crowding: function foo(array? &$bar) { }
bar by ref expects array, but may take null (which is perfectly common
for a by-ref variable). Trouble is, '? &$' is starting to look
perlish.

Generic expansion:
Prefix: function foo(?array<Bar<?int>> $baz)...
Suffix: function foo(array<Bar<int?>>? $bar)...

Both proclaim a nullable array of non-nullable Bar objects of nullable
type int. The prefix version makes it much more obvious which '?'
goes with which portion of the type structure.

function foo(array?<Bar<int?>> $baz)... sounds tempting, but some
shift/reduce conflicts start to emerge out of that stacking of tokens.
Resolvable, of course, but complicating the parser rules over a bit
of aesthetics like that.... You can't see it, but I've got my frownie
face on right now.

-Sara

P.S. - I'm not voting for or against anything at this point either.
Just offering input during discussion phase, as we're all meant to. :)

Sara,

In the original internals thread about generics, you mention that the

HHVM team were going to donate their effort and patch to PHP so we could
have generics in PHP .... so ... how did that work out, is there a patch
(even a half finished one) ??

I'm a bit disappointed that this has been turned into a conversation

about something I see as completely different.

I wasn't looking to introduce a paradigm, and think it would be quite

terrible to use the syntax for generics for this; I only want to hint
for generics when I can program with generics, and even if I wrote the
patch next week, the original conversation made it seem like it would
never be merged anyway ...

Was there some technical difficulty that stopped the work on generics

when it was first brought up, or did you just realise that it would
never get through ??

Original conversation about generics:

http://php.markmail.org/message/fhqgkzyui3cpantg?q=net%2Ephp%2Elists%2Einternals+generics+order:relevance&page=1

Cheers
Joe

10 years ago by Sara Golemon — view source

unread

    Was there some technical difficulty that stopped the work on
generics when it was first brought up, or did you just realize that it would
never get through ??

A little from column A, a little from column B.

None of the technical challenges were insurmountable, but the
temperature for Generics felt tepid at the time (not nearly a 2/3
majority), so it was back-burnered for more productive stuff. Reckon
the mood has changed in the past year or so?

-Sara

10 years ago by Joe Watkins — view source

unread

     Was there some technical difficulty that stopped the work on
generics when it was first brought up, or did you just realize that it would
never get through ??
A little from column A, a little from column B.

None of the technical challenges were insurmountable, but the
temperature for Generics felt tepid at the time (not nearly a 2/3
majority), so it was back-burnered for more productive stuff. Reckon
the mood has changed in the past year or so?

-Sara

I'm not really sure that it has, and if it has, it's only because people
view it as an overhead free way of achieving what we set out to achieve
here, even though its not really, the actual type hint would be ... I
digress ... I don't really think anyone is thinking it through ...

When you think about it, we couldn't just introduce generics right now,
we have an incomplete type hinting system and it's terribly inconsistent
for new HashMap<int, string>() to be valid but not have the ability to
hint for int or string elsewhere.

It could be done, but it seems ... horrible ... I really think scalar
hints have to be supported before generics, and there are so many
patches for that and even more opinions, I'm not even sure we are
capable of coming to the right decision, we haven't yet, the correct
patch for scalar hinting exists, has done for a while ...

To a lesser extent, you would want return type hints too, if nothing
other than to give the compiler every opportunity to detect
inconsistency in the actual use of generics before we get as far as
execution.

That said, I'd love it, quite happily will put time into working on any
of the things I mentioned, but I have literally no idea how to change
minds ...

Any, or all of the things I just said are not small changes, aimed at
introducing completely alien concepts, alien both to the language and
the people using PHP ... a completely new programming paradigm, that's
really not what we were going for at all here, a simple type hint was all.

I know you know all of what I just said, but for those reading ..

Cheers
Joe

10 years ago by Stas Malyshev — view source

unread

Hi!

After a little thought, I think I'd rather we use the HHVM syntax here.
Having "Array" for an untyped array but "Bar[]" for a typed one is
silly. "Array" and "Array<Bar>" make more sense. Being able to type keys
would be nice, too.

Except that there's no type "array<Bar>" in PHP, so we're just inventing
things out of the thin air that mean nothing. Just because some other
language has common syntax - which in that language means something,
since they actually have typed arrays. But in PHP it doesn't mean
anything except being pulled in to save couple of lines of code. I think
we should not do such things in PHP - if we want to have language that
makes sense and not just a hodgepodge of random syntax constructs pulled
from all over the place and hastily bolted on together - we should not
put in any syntaxes that do not make sense in the rest of the language.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Tjerk Meesters — view source

unread

Hi Phil,

On Thu, Jan 16, 2014 at 2:17 AM, Philip Sturgeon pjsturgeon@gmail.comwrote:

Hey,

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

First of all, congrats on getting your first RFC out; despite the issues
brought up so far, the idea itself is certainly interesting :)

I was curious about whether it would be possible to perform this type check
outside of the function context as well? For example:

if ($array instanceof Foo[]) { ... }

From what I could tell, this is not part of the RFC.

As an aside, for the fun of it, I thought of this arcane casting syntax:

$arr = (int[])$arr;

--

--

Tjerk

10 years ago by Chris Wright — view source

unread

When you say, SplTypedArray, do you mean single datatype array? Or would
it go so far as adding SplStructs, because to me, that would be VERY handy,
if it added some speed to parsing packets binary packets.

I just inferred a single datatype array (i.e. "members must all be
instances of the FQ class name passed as a constructor arg") from previous
comments, although I suppose some more complex extended variants are
possible. I would certainly like the simplest possible variant to be
present, but I'm not against more complex structures extending from that
base.

10 years ago by Sherif Ramadan — view source

unread

This RFC seems to purport in the way of improvement. I feel it's more of a
variation than an improvement on the status quo. We've had a number of
these RFCs over the years. I'd be much more interested to see RFCs that
introduce an actual lacking feature into the language like the exponent
operator RFC rather than all of these OOP syntax sugar RFCs that are
cropping up by the minute. I'm not trying to bash anyone's efforts, but I
really feel that these kinds of RFCs are mostly fluff that we could easily
do without.

To focus specifically on this RFC I find its use cases to be extremely
limiting and mildly beneficial. PHP arrays are very generalized so that a
developer could easily have an array of integers, floats, strings, and any
other primitive in the same storage unit. To limit the type hinting just to
user-defined objects and then limit it even further to a single dimension
means chopping the number of use cases down to an 8th then chopping that
number down by another fraction. The result is such a narrow use case that
it becomes almost useless in practice.

The idea of better type hinting in PHP is not inherently a bad one. It's
just that many of the proposed implementations seem to veer off into
fragile use cases that really shouldn't require a language change. What's
worse is that the next RFC to come after it usually makes it worse as it
tries to pull the language into an equally different set of fragile use
cases. Ultimately the user just gets confused and doesn't tend to find
these limiting syntax sugars all that useful in practice. Even though they
appear interesting in theory, they're not really so great that we couldn't
do with a pure PHP implementation that doesn't require a language change.

Having looked over the RFC and the actual patch I find that refactoring
code which relies on the function or method itself to handle type checks
(in situations where it will cause an actual broken design by contract
effect), makes the patch a worser scenario for both the developer and the
language. It doesn't actually make the code any easier to read and doesn't
make it any easier to debug. Code that already relies on PHP implemented
type checks is better off not using the new syntax. Code that uses the new
syntax tends to get trapped into too many edge cases. So I really can't see
the upside here.

10 years ago by Philip Sturgeon — view source

unread

This RFC seems to purport in the way of improvement. I feel it's more of a
variation than an improvement on the status quo. We've had a number of
these RFCs over the years. I'd be much more interested to see RFCs that
introduce an actual lacking feature into the language like the exponent
operator RFC rather than all of these OOP syntax sugar RFCs that are
cropping up by the minute. I'm not trying to bash anyone's efforts, but I
really feel that these kinds of RFCs are mostly fluff that we could easily
do without.

To focus specifically on this RFC I find its use cases to be extremely
limiting and mildly beneficial. PHP arrays are very generalized so that a
developer could easily have an array of integers, floats, strings, and any
other primitive in the same storage unit. To limit the type hinting just to
user-defined objects and then limit it even further to a single dimension
means chopping the number of use cases down to an 8th then chopping that
number down by another fraction. The result is such a narrow use case that
it becomes almost useless in practice.

The idea of better type hinting in PHP is not inherently a bad one. It's
just that many of the proposed implementations seem to veer off into
fragile use cases that really shouldn't require a language change. What's
worse is that the next RFC to come after it usually makes it worse as it
tries to pull the language into an equally different set of fragile use
cases. Ultimately the user just gets confused and doesn't tend to find
these limiting syntax sugars all that useful in practice. Even though they
appear interesting in theory, they're not really so great that we couldn't
do with a pure PHP implementation that doesn't require a language change.

Having looked over the RFC and the actual patch I find that refactoring
code which relies on the function or method itself to handle type checks
(in situations where it will cause an actual broken design by contract
effect), makes the patch a worser scenario for both the developer and the
language. It doesn't actually make the code any easier to read and doesn't
make it any easier to debug. Code that already relies on PHP implemented
type checks is better off not using the new syntax. Code that uses the new
syntax tends to get trapped into too many edge cases. So I really can't see
the upside here.

I'm a little stunned by this response. By no means is this RFC fluff,
and simply because you do not personally see a use case does not mean
that they do not exist.

Currently I am working on a HTTP Message PSR, where we would like an
array of instances of the HeaderValueInterface to be sent through to a
method. Currently we have to type-hint against "array" and hope the
user knows what they are supposed to send through with documentation.
Interfaces are meant to be a contractual obligation, not guesswork.

That might seem like an edge case, but this happens all the time.
PyroCMS wants an array of Widgets, or ModuleDetails, or anything.
Boilerplate code for these occasions is always required and its a pain
in the ass having to write it every time.

To me it is confusing that there is a separation in the "usefulness"
between type hinting a single item, or type hinting an array of items.
For the same reason I want to be certain that an argument is a Foo, I
want to know if I am being given multiple Foo's.

"PHP arrays are very generalized so that a developer could easily have
an array of integers, floats, strings, and any other primitive in the
same storage unit. To limit the type hinting just to user-defined
objects and then limit it even further to a single dimension means
chopping the number of use cases down to an 8th then chopping that
number down by another fraction. The result is such a narrow use case
that it becomes almost useless in practice."

It's wonderful that PHP allows arrays to be so vague. It's truely
useful sometimes. Sometimes its not and I want to know exactly what is
in there, as is the right of the implementor of a function or method.
When I want to know that everything is a Foo it would be great to
ensure that.

Again I say I am confused how this is a marginal requirement, this is
incredibly standard stuff.

"Ultimately the user just gets confused and doesn't tend to find these
limiting syntax sugars all that useful in practice."

Who is the user? The user implementing the type hint? If they want it,
they will use it. If they dont want it, they wont use it.

Somebody calling said function or method is going to get an error if
they dont pass in the correct data, just like any other type hint. So
again, there is not a lot of room for confusion there.

"It doesn't actually make the code any easier to read and doesn't make
it any easier to debug"

I strongly disagree with this statement.

Currently if a function is expecting Foo's you need to either read a
DocBlock, external documentation or read the code. Seeing Foo[] let's
you know that you need an array of Foo's, right there in the
declaration. That is what I consider to be readable, but I understand
you might say the square brackets could cause confusion to the user.

I know you can't google search for "[]", but the docs would be right
there on the "type-hinting documentation" so that solves that nicely.

"Code that uses the new syntax tends to get trapped into too many edge cases"

Not sure what you mean here. If I want a bag of spanners I know that
I'm getting a bag of spanners. That does not trap me, it is a safety
catch, to make sure when I put my hand in the bag it is always going
to be a spanner, and I don't accidentally pull out a bear.

I think mostly I would just like you to quantify some of your
statements, as you seem to be saying:

It is only useful to people called Jeremy on a Tuesday afternoon
It is single-handedly responsible for the death of Steve Jobs.
Explosions

I think its a nice logical improvement which syntactically offers a
replacement for looney boilerplate code, exactly like Variadics which
a LOT of people are excited about.

10 years ago by Sherif Ramadan — view source

unread

On Sun, Jan 19, 2014 at 12:13 PM, Philip Sturgeon pjsturgeon@gmail.comwrote:

It is only useful to people called Jeremy on a Tuesday afternoon

Yes, the implementation of this type hint is very limiting in nature. It's
not that I don't like the idea of an array type hint. I just don't like
this implementation. I'd much rather see something like the HHVM
implementation Sara spoke of that actually doesn't constrain the
implementation to such limiting use cases as those you have exhibited.

It is single-handedly responsible for the death of Steve Jobs.

No idea what you're talking about. I never said anything of the sort.

Explosions

What?

10 years ago by Rasmus Lerdorf — view source

unread

I think its a nice logical improvement which syntactically offers a
replacement for looney boilerplate code, exactly like Variadics which
a LOT of people are excited about.

Actually variadics solves a problem that can't be solved other ways,
namely by-ref for an unknown number of arguments. There is no userspace
boilerplate code, looney or otherwise, that can do that.

I won't argue whether the base need is great enough here. I am sure it
is to some people. I do have an issue with the idea that the right
solution is a full hash table scan on every function call. I have a
feeling that if this makes it in this is one of those features that will
be high my list for optimization/refactoring when I run across it in
code. As in, replace the per-call hash scan with a single userspace scan
that is only done once earlier in the stack. From a performance
perspective the only-done-once userspace version is extremely likely to
outperform this built-in per-call check assuming more than a trivial
amount of calls to the function in question.

-Rasmus

10 years ago by Larry Garfield — view source

unread

I think its a nice logical improvement which syntactically offers a
replacement for looney boilerplate code, exactly like Variadics which
a LOT of people are excited about.
Actually variadics solves a problem that can't be solved other ways,
namely by-ref for an unknown number of arguments. There is no userspace
boilerplate code, looney or otherwise, that can do that.

I won't argue whether the base need is great enough here. I am sure it
is to some people. I do have an issue with the idea that the right
solution is a full hash table scan on every function call. I have a
feeling that if this makes it in this is one of those features that will
be high my list for optimization/refactoring when I run across it in
code. As in, replace the per-call hash scan with a single userspace scan
that is only done once earlier in the stack. From a performance
perspective the only-done-once userspace version is extremely likely to
outperform this built-in per-call check assuming more than a trivial
amount of calls to the function in question.

-Rasmus

Which I think goes to the earlier point about it being better to do at
add-time than read-time, since add-time is O(n) and read-time is O(n*m).

Stepping back a bit, the underlying feature request, essentially, is "I
want to ensure I have a collection of X without having to write a custom
collection class every frickin' time". (Writing a FooCollection class
whose add() method only accepts Foo objects is very straightforward, but
generally needless boilerplate.) That can be checked at add time or
read-time. I think that's an entirely valid use case in modern code,
and can help lead to more self-documenting code, too.

The patch in the RFC handles that with arrays as the collection, and
run-time checking via type hints. My initial thought was "yes please!",
but from the discussion here I can see where that's sub-optimal for
performance reasons as Rasmus notes.

Generics or something in SPL would allow for simpler add-time checking,
which is what we probably want. However, if we did that then all of the
various array functions don't work. That's hardly a new problem for
PHP, of course.

So how could we add "collection of just X type of things" support to PHP
without running afoul of the "ArrayObject vs. Array" problem?

I'm not sure, but I think this is another case where "arrays as the
uber-data structure" gets in the way of more robust programming
methodologies.

--Larry Garfield

10 years ago by Patrick Schaaf — view source

unread

Regarding the N*M checking complexity, couldn't a little bit of memory
alleviate the problem?

For each array, have a "member type" pointer, initially NULL.

When the member type needs to be checked for the first time, and that
"member type" pointer is not already set, do an O(N) scan of the arrray,
testing compatibility of all members against the hinted type. Error on
mismatch, but when all members match, remember the type behind the "member
type" pointer.

When the member type needs to be checked and the "member type" pointer is
set, just compare it to the hinted type O(1).

There must be some overhead when elements are added to an array. Either
"when member type is set, forget it", or even "when member type is already
set, check compatiility of the newly added element with the member type,
and then remove member type on mismatch or keep it on match".

Finally when arrays are copied, and "member type" is already set, copy it
along with the array, Optionally some of the array functions like
array_merge might be made aware of the scheme, too.

BTW, I'm undecided regarding the need for the overall feature, from my
rather limited personal coding practise it seems to me that whenever I am
interested in member type checking I'm already looping over the array and
can easily add up-front instanceof checks to the loops with suitable
explicit error-out. Which I generally prefer over automatic errors,
especially fatal ones, because I control the error case behaviour.

But I think if such a scheme were added, the implementation described
above would solve the O(N*M) problem with acceptable overall cost.

best regards
Patrick

10 years ago by Rasmus Lerdorf — view source

unread

Regarding the N*M checking complexity, couldn't a little bit of memory
alleviate the problem?

For each array, have a "member type" pointer, initially NULL.

When the member type needs to be checked for the first time, and that
"member type" pointer is not already set, do an O(N) scan of the arrray,
testing compatibility of all members against the hinted type. Error on
mismatch, but when all members match, remember the type behind the "member
type" pointer.

When the member type needs to be checked and the "member type" pointer is
set, just compare it to the hinted type O(1).

There must be some overhead when elements are added to an array. Either
"when member type is set, forget it", or even "when member type is already
set, check compatiility of the newly added element with the member type,
and then remove member type on mismatch or keep it on match".

This means every HT becomes larger now and every time you write to a HT
you at the very least need to do one extra comparison. We use HTs
everywhere, so this would have a performance impact on every script even
if you have absolutely no intention of ever using this feature.

-Rasmus

10 years ago by Pierre Joye — view source

unread

hi,

Regarding the N*M checking complexity, couldn't a little bit of memory
alleviate the problem?

For each array, have a "member type" pointer, initially NULL.

When the member type needs to be checked for the first time, and that
"member type" pointer is not already set, do an O(N) scan of the arrray,
testing compatibility of all members against the hinted type. Error on
mismatch, but when all members match, remember the type behind the "member
type" pointer.

When the member type needs to be checked and the "member type" pointer is
set, just compare it to the hinted type O(1).

There must be some overhead when elements are added to an array. Either
"when member type is set, forget it", or even "when member type is already
set, check compatiility of the newly added element with the member type,
and then remove member type on mismatch or keep it on match".

This means every HT becomes larger now and every time you write to a HT
you at the very least need to do one extra comparison. We use HTs
everywhere, so this would have a performance impact on every script even
if you have absolutely no intention of ever using this feature.

As I like this RFC for other reasons (type hinting extension), I tend
to think that the use cases presented here can be done in a more
efficient way. Someone else mentioned "collections" and it is exactly
what it is all about. A collection could be an instance of a given
class, which stores only one class type. It prevents on usage/function
call checks and checks are done only when adding a member to the
collection.

On another note, and only as a note here as I really do not want to
hijack this thread with another topic, the more I see this kind of
RFCs the more I feel like we are heading to general or global type
hinting supports. I think it could be the right time to actually
decide what we want. It is getting critical as we keep adding stuff
about type hinting, one after another, which may lead to
inconsistencies and will prevent us to have a good type hinting
mechanism in PHP.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Lester Caine — view source

unread

Pierre Joye wrote:

As I like this RFC for other reasons (type hinting extension), I tend
to think that the use cases presented here can be done in a more
efficient way. Someone else mentioned "collections" and it is exactly
what it is all about. A collection could be an instance of a given
class, which stores only one class type. It prevents on usage/function
call checks and checks are done only when adding a member to the
collection.

To my mind this is a lot more PHP friendly? ... If I am building an array of
data then I have the option to create each element as a 'new' construct, or
simply cache the data in a manor that a single instance of the object can handle
multiple sets of data. A collection of data could potentially be managed in a
single instance?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

10 years ago by Lazare Inepologlou — view source

unread

Hello,

on 2014/1/16 Sara Golemon wrote:

Soft types - Any type preceeded by an at sign is hinted as that type,
but not checked:
function foo(@Bar $IHopeYoureABarObject) {...}

Nobody has commented so far about this feature of HHVM, which, in my
opinion is a win-win:

Clarifies the contract between the function designer and the function
user.
Makes the life easy for IDEs and static analysis tools.
No run-time penalty.

Thoughts?

--

Lazare INEPOLOGLOU
Ingénieur Logiciel

10 years ago by Nikita Nefedov — view source

unread

Regarding the N*M checking complexity, couldn't a little bit of memory
alleviate the problem?

For each array, have a "member type" pointer, initially NULL.

When the member type needs to be checked for the first time, and that
"member type" pointer is not already set, do an O(N) scan of the arrray,
testing compatibility of all members against the hinted type. Error on
mismatch, but when all members match, remember the type behind the
"member
type" pointer.

When the member type needs to be checked and the "member type" pointer
is
set, just compare it to the hinted type O(1).

There must be some overhead when elements are added to an array. Either
"when member type is set, forget it", or even "when member type is
already
set, check compatiility of the newly added element with the member type,
and then remove member type on mismatch or keep it on match".

Finally when arrays are copied, and "member type" is already set, copy it
along with the array, Optionally some of the array functions like
array_merge might be made aware of the scheme, too.

BTW, I'm undecided regarding the need for the overall feature, from my
rather limited personal coding practise it seems to me that whenever I am
interested in member type checking I'm already looping over the array and
can easily add up-front instanceof checks to the loops with suitable
explicit error-out. Which I generally prefer over automatic errors,
especially fatal ones, because I control the error case behaviour.

But I think if such a scheme were added, the implementation described
above would solve the O(N*M) problem with acceptable overall cost.

best regards
Patrick

Hi Patrick,

I had this cache-idea too, but it will fail to get you any speedup if you
check for array of interfaces (if you want to store objects of different
classes but all this classes implement one interface). And this is the
same reason why this proposal is very different from having typed array
structure (cause, as long as I know, type of the typed array is always the
end-class, objects of which will be stored in this array). So if we are
proposing to add some new Spl structure - keep that in mind.

And again, reference to an element in the array can be used to change
element of the array without affecting (and thus calling any of the
functions related to) HT.

10 years ago by Joe Watkins — view source

unread

I think its a nice logical improvement which syntactically offers a
replacement for looney boilerplate code, exactly like Variadics which
a LOT of people are excited about.

Actually variadics solves a problem that can't be solved other ways,
namely by-ref for an unknown number of arguments. There is no userspace
boilerplate code, looney or otherwise, that can do that.

I won't argue whether the base need is great enough here. I am sure it
is to some people. I do have an issue with the idea that the right
solution is a full hash table scan on every function call. I have a
feeling that if this makes it in this is one of those features that will
be high my list for optimization/refactoring when I run across it in
code. As in, replace the per-call hash scan with a single userspace scan
that is only done once earlier in the stack. From a performance
perspective the only-done-once userspace version is extremely likely to
outperform this built-in per-call check assuming more than a trivial
amount of calls to the function in question.

-Rasmus

On 01/20/2014 04:19 AM, Rasmus Lerdorf wrote:> I do have an issue with
the idea that the right

solution is a full hash table scan on every function call.

Rasmus,

The better solution here appears (to everyone else) to be generics,

which you actually said you didn't want to see anywhere near PHP, please
could you communicate your reasons for that ?

I have concerns ...

I'm concerned that type hinting isn't robust or complete enough to

compliment using generics.
I'm wary of the inherent complexity that generics carries both in it's
implementation and usage.
I'm concerned that we already have many different kinds of collection,
and they have introduced inconsistencies (Traversable != array), I don't
really see a way to add another, and such a complex one, without
introducing more, or alternatively impacting everything.
It's a bit crazy to implement a whole paradigm because we wanted a
specific kind of type hint.

Is it any of them ?? Is it something I, or any of the others thinking

about generics, don't see ??

Do you, or anyone else, anyone at all, see a way to perform the simple

type hint we set out to perform without incurring the overhead of a full
table scan ?

I don't want to set out to do anything that is bad, however, I think

the performance thing is not really a massive concern, after all it's
not very difficult for something innocent to incur a measurable overhead:

https://eval.in/91920

And we're not all going around re-factoring our code to avoid that,

because it's "normal"; people know that passing a huge array around
increases memory usage because it's documented, so I don't see the
problem with documenting how this would work such that those that need
to avoid the overhead, can.

Also, variadics incur the same overhead:

http://lxr.php.net/xref/PHP_5_6/Zend/zend_vm_def.h#3448

The idea to change the hashtable wouldn't work anyway (for the OP of

the idea): you can have a reference to a variable that is a member of an
array and change it's type without executing any opcodes related to
hashtable manipulation.

Cheers
Joe

10 years ago by Robert Stoll — view source

unread

Hey Lazare

-----Original Message-----
From: Lazare Inepologlou [mailto:linepogl@gmail.com]
Sent: Monday, January 20, 2014 10:54 AM
Cc: internals
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC

Hello,

on 2014/1/16 Sara Golemon wrote:

Soft types - Any type preceeded by an at sign is hinted as that type,
but not checked:
function foo(@Bar $IHopeYoureABarObject) {...}

Nobody has commented so far about this feature of HHVM, which, in my
opinion is a win-win:

Clarifies the contract between the function designer and the function
user.

Makes the life easy for IDEs and static analysis tools.

No run-time penalty.

Thoughts?

I think it suits PHP very well but that would definitely be a different RFC.
And btw. "soft" type hints would not work for typed arrays (since this can only be checked during runtime

10 years ago by Robert Stoll — view source

unread

Hey Joe,

I don't want to set out to do anything that is bad, however, I think
the performance thing is not really a massive concern, after all it's
not very difficult for something innocent to incur a measurable overhead:

https://eval.in/91920

It can be fairly fast for one call only, but imagine you have those type hints all over the place.
I really don't think it is a good idea to introduce something which we both now is far from ideal. Yet, I like the idea
behind this RFC and think we should think it over and come up with a better implementation.
Your last comment was actually thought-provoking

The idea to change the hashtable wouldn't work anyway (for the OP of
the idea): you can have a reference to a variable that is a member of an
array and change it's type without executing any opcodes related to
hashtable manipulation.

So I sat down and coded an example in PHP. Maybe it can help this RFC to go further. You can find it here:
https://github.com/robstoll/phputils/blob/master/TypedArray.php

Seems like the implementation is robust enough for the dirty reference hack (as mentioned by you) by chance. Yet, one
could still inject invalid types via Reflection. It's not possible to prohibit that as far as I know.

Brief overview of the implementation

works for all types (bool, int, float, string, array, resource, callable, and class/interface)
initialisation in two different ways
$foos = new TypedArray(Types::T_CLASS_OR_INTERFACE, "Foo");
$bars = TypedArray::createFromArray(Types::T_INT, [1,2,3, 'a'=5, 'a'=>9]);
type hinting can be used as follows:
/**
* @param TypedArray<int> $arr
*/
function foo(TypedArray $arr){
$arr->checkIsSameType(Types::T_CLASS_OR_INTERFACE, "Foo");
}

I have not yet implemented Iterator as interface but that could be added easily

This implementation has of course drawbacks compared to the RFC:

it is not obvious what type TypedArray contains just from reading the signature (needs the additional documentation)
needs one extra line of code to check if actually the given TypedArray is of the correct type

And advantages:

is already possible with the current PHP version
type hint check O(1)
add element check O(n)
one can still pass a normal array with the initialise syntax (does more or less the same as your implementation):
foo(TypedArray::createFromArray(Types::T_INT, $arr);

If we would substitute the one additional line with some syntactic sugar then we would have already a nice
implementation IMO.

Cheers,
Robert

10 years ago by Philip Sturgeon — view source

unread

Hey,

So I have not been as active in this thread as I would have liked, but
life has a tendency to happen, and it's been happening a lot.

I would just like to cover multiple topics that have popped up, in a
bid to get things back on track.

Scalar Type Hints

A lot of people obviously feel strongly that scalar type hints are
lacking here, and that while we are discussing type hints now woul-d
be a good time to talk about that. It isn't.

There is an RFC for scalars and I would love to discuss it another time.

https://wiki.php.net/rfc/scalar_type_hinting_with_cast

This "array of" RFC will be made better by scalar types happening, but
they do not have to happen first so let's not worry about them now.

Generics

As Joe has pointed out, this RFC has nothing to do with generics. They
are a whole different kettle of fish.

Rasums hates them

http://comments.gmane.org/gmane.comp.php.devel/76495

I hear a lot of people saying "PHP is turning into Java" every time
anything vaguely OOP happens (which is frustrating, and... factually
inaccurate) but adding generics would be INCREDIBLY Java-esque.

http://en.wikipedia.org/wiki/Generics_in_Java

Those who are interested in it should discuss it, but I do not know
why we are talking about them here. Maybe a new RFC and a new thread
for Generics can occur, but they are not alternatives to the same
solution.

Use-cases

If you don't see the use, maybe ask about the use, don't assume there
is no use. I will happily repeat this on every single RFC thread in
the future, because it happens every single time.

"Type-checking is not PHP"

PHP is a loosely typed language. It allows arrays to contain a mixture
of content. It is very vague. GREAT.

Type-hints are lovely for when you do not want to be vague.

A plain-old function declaration:

"Give me a bag of stuff, and I'll try using everything like it's a
spanner, but it could be a banana and... well I guess my wing-nuts
will get covered in banana gunk, but whatever, YAY WEAK TYPING."

or

"Give me a bag of stuff and I'll fish around in there trying to
find spanners, and ignore everything else"

This RFC optionally allows developers to say:

"Give me a bag of spanners, and break if they put anything else in there."

Optional, opt-in, simple, logical, useful.

Performance

This adds overhead when used. Like anything, doing more stuff takes
longer. Check.

The overhead is small, and the use-cases where I see this stuff
happening makes it unlikely for usage to be nested in such a way that
this would run multiple times.

That said it is known that the typing system needs an overhaul. Joe
has said that while this does add a trivial overhead, it can easily be
taken care of in future versions with a general drive-by on types.

It's great to see people discussing caches and other performance
improvements, it certainly does not seem impossible to speed this up a
little, but its hardly slow enough to impact anything unless you have
hundreds of these things handling thousands of records. Regardless, if
you are actually doing that then you need to stop and think about your
actions.

Enforcing OOP

Not the case. As has been said, this is equally useful for scalar type
hinting - when that gets done. You can type-hint anything, not just
interfaces. Even currently while only array, callable and OOP stuff is
hintable, this optional feature does not enforce OOP any more than
current type hinting.

Doesn't Handle Traversable

Right now the typing system cannot handle hint for both "foo(array
$bar)" and foo(Traversable $bar)", so it is purely a consistency thing
that makes this RFC not try to attack that either. The overhaul of the
typing system mentioned in the Performance section could approach
this, but this has nothing to do with the RFC in question and should
be considered off topic. I did explain that on the RFC itself.

"Just use collections"

Something that I have seen before in these discussions is this
conversational approach:

"Why add a feature to do this in a nice, neat, logical fashion, when
you could just throw loads of code at it?!"

This time it is happening with the suggesting of using Collections,
instead of defining the content at a declaration level.

If I want a bag of spanners, then I can absolutely define
"SpannerCollection" and require that on the type-hint level. Sure.

Personally I hate the idea of forcing the implementor of a method (who
may not be the same as the developer of said method) to change their
code on the outside, purely so I can have the convenience of knowing
the contents of the argument on the inside.

I have the overhead of autoloading, finding, populating and generally
f**king around with that collection, when all I want or need is the
ability to be certain that the argument only contains spanners, and
nothing else.

Suggesting that throwing more code at this is a viable solution is
madness, and this specific example is just suggesting a weak form of
generics should be used. Again, this is not generics.

Syntax

There have been a lot of people suggesting various types of syntax. As
Joe said, using generics syntax for not generics would be a travesty,
and an overcomplication of what should be a simple feature.

For those who hate OOP, array of would be a lovely way to ask for an
array of callables. Trying to make generics happen is a great way to
force not only new syntax, but a brand new OOP paradigm that will be
new for EVERYONE, so ignoring that syntax and letting our functional
and OOP folks have a nice thing shouldn't be considered a negative.

One we decide that this is not generics, we can discuss syntax much easier.

So.

function (Foo[] $foo) - No nulls.

This is something I hope we can all agree on. It is by no means
confusing, but I would be happy to run a poll and get NetTuts to tweet
it, to see if the average user is confused by this syntax. I've
tweeted about it and had 1 out of 50ish replies saying they weren't
sure. The confusion of 2% is something that can easily be fixed with
documentation and time.

Again, I'll be blogging about 5.6 features on NetTuts so those same
beginner level users will know all about it, and our documentation
will explain it for everyone else, meaning a 2% sub-section of users
will be EASY to fix.

Allowing Nulls

Some folks are concerned that forcing this feature to not consider
null as a valid array entry is somehow a loss to the feature. We can
potentially fix this with MOAR SYNTAX. I offer 3 options here:

function (Foo[]? $foo)

Maybe. Not sure we even care about this, and gets a little confusing
with &Foo[]? but it could be considered.

function (Foo|null[] $foo)

Fits in line with DocBlock syntax, could allow multiple types, but
folks would assume that function (Foo|null $foo) is also ok.

My suggestion:

Do nothing

We implement this feature, as is, then we have a a follow-up for
allowing type-hinting on multiples:

The new RFC at the same time would implement

function (Foo|Bar $foo)
function (Foo|null[] $foo)
function (Foo|Bar[] $foo) or... function (Foo[]|Bar[] $foo) I guess?

Being able to say "I would like a spanner or a monkey-wrench" is a
perfectly valid use-case, just as "I would like a spanner or an 'I owe
you'" is another valid use-case. But to shove nulls in with something
that specifically expects a spanner is clearly a really weird thing to
do.

Either way, there are a LOT of topics being discussed in this thread
that are not super relevant to what is actually being suggested.

I'd really like it if we could discuss just this feature, and keep the
generics, OOP arguments, anti-type-checking, and "bemoaning of
edge-case performance issues on type system that needs some love
anyway" conversations for other threads.

Thanks! :)

10 years ago by Sara Golemon — view source

unread

Short version: "This RFC is not about Scalar Type Hints or Generics"

But it is.

"ArrayOf", whatever form it takes, is incomplete without scalar
specializations. Is implementing half-a-feature (arrayof without
scalars) good enough? Maybe, but that doesn't mean we shouldn't be
having that discussion.

There have been a lot of people suggesting various types of syntax. As
Joe said, using generics syntax for not generics would be a travesty,
and an overcomplication of what should be a simple feature.

ArrayOf is not a separate topic from Generics, it is by definition a
narrowly-scoped form of generics. "ArrayOf Foo" is a "Foo"
specialization of the array generic (even if it's not labeled as such
due to not having other types of generics). "This is an array, but
it's an array just for Foos". Can arrayof be implemented in a way
which hides this heritage? Sure, but should it?

I'd really like it if we could discuss just this feature, and keep the
generics, OOP arguments, anti-type-checking, and "bemoaning of
edge-case performance issues on type system that needs some love
anyway" conversations for other threads.

Just reinforce my points above, I disagree with this paragraph.
Looking at specific cases while ignoring the larger picture of the
language's design is what gets us into ugly corners (inconsistently
named functions, parameter ordering, multiple autoloader mechanisms,
etc...)

Ignoring elements which fit closely together is a short-sighted mistake.

-Sara

10 years ago by Andrea Faulds — view source

unread

ArrayOf is not a separate topic from Generics, it is by definition a
narrowly-scoped form of generics. "ArrayOf Foo" is a "Foo"
specialization of the array generic (even if it's not labeled as such
due to not having other types of generics). "This is an array, but
it's an array just for Foos". Can arrayof be implemented in a way
which hides this heritage? Sure, but should it?

This is a quite good point. If we're introducing limited-scope Generics
here, what's wrong with using Generics syntax, especially since it will
be familiar to C#, C++ and Java users?

Andrea Faulds
http://ajf.me/

10 years ago by Crypto Compress — view source

unread

Hi,

somewhat off topic, sorry. Yet, generics are not the same as purposed
syntax:

protected void Foo(int[] foo) {}
protected void Foo(Dictionary<int, string> foo) {
protected void Foo(Dictionary<int, string>[] foo) {

cryptocompress

10 years ago by Andrea Faulds — view source

unread

Syntax

There have been a lot of people suggesting various types of syntax. As
Joe said, using generics syntax for not generics would be a travesty,
and an overcomplication of what should be a simple feature.

Using generics-like syntax is more consistent with what we have already,
though. Having "Array" for an array yet "Bar[]" for an Array of bar is
confusing, especially since you'd then also logically have "Array[]". Why?

Using the generics syntax does not require adding generics. It simply
allows a better syntax which is consistent with the existing syntax. I'd
much rather have "Array", "Array<Bar>" and "Array<Array>" here than
"Array", "Bar[]" and "Array[]".

It's also compatible with HHVM, which is a plus.

I don't agree that this would be "an overcomplication of what should be
a simple feature.". It would not at all. This syntax is simpler, more
consistent and more logical than that originally proposed.

For those who hate OOP, array of would be a lovely way to ask for an
array of callables. Trying to make generics happen is a great way to
force not only new syntax, but a brand new OOP paradigm that will be
new for EVERYONE, so ignoring that syntax and letting our functional
and OOP folks have a nice thing shouldn't be considered a negative.

Again, generics-esque syntax doesn't mean adding generics.

It also means that, if generics were added in future, we could use
generics here - and they'd implement the same functionality in a better
way. :)

This is something I hope we can all agree on. It is by no means
confusing, but I would be happy to run a poll and get NetTuts to tweet
it, to see if the average user is confused by this syntax. I've
tweeted about it and had 1 out of 50ish replies saying they weren't
sure. The confusion of 2% is something that can easily be fixed with
documentation and time.

Again, I'll be blogging about 5.6 features on NetTuts so those same
beginner level users will know all about it, and our documentation
will explain it for everyone else, meaning a 2% sub-section of users
will be EASY to fix.

Why should we use a poll of some random tutorial site? This is a
developer mailing list!

--
Andrea Faulds
http://ajf.me/

10 years ago by Nikita Nefedov — view source

unread

Hi Philip,

On Mon, 20 Jan 2014 22:43:41 +0400, Philip Sturgeon pjsturgeon@gmail.com
wrote:

Generics

As Joe has pointed out, this RFC has nothing to do with generics. They
are a whole different kettle of fish.

Rasums hates them

http://comments.gmane.org/gmane.comp.php.devel/76495

This is Rasmus's concern, I don't think it should be a reason for denying
it. I'm sorry for a little rough words but your know PHP is now
open-source and all that stuff...

I hear a lot of people saying "PHP is turning into Java" every time
anything vaguely OOP happens (which is frustrating, and... factually
inaccurate) but adding generics would be INCREDIBLY Java-esque.

http://en.wikipedia.org/wiki/Generics_in_Java

Why do you give a f*ck? I mean, maybe it's something Java-ish, but so
what? It's useful, it will make our lives (as a PHP developers) a little
better. So why not? I, for one, have a project right now, where we have a
ton of typed collections. And generics is the thing that would made our
lives easier. I believe we are not the only ones...

If don't like the syntax, or you don't like the idea, you can just not use
it.

Those who are interested in it should discuss it, but I do not know
why we are talking about them here. Maybe a new RFC and a new thread
for Generics can occur, but they are not alternatives to the same
solution.

We are talking about it here (at least I'm thinking about it) because
arrayof is pretty exotic feature. A lot of people here are proposing to
add typed array structure, but it will differ from arrayof... While with
arrayof you can typehint for interface, a typed-array can only hold
records of given class. So the semantics are differ. But with generics you
can achieve the same goal as with arrayof (you can typehint for interface.
I know Java enforces you to pass an end-class, but I don't see a reason to
make it as in Java. I would make it possible to pass in generic binding an
interface, it's pretty straightforward as I see, OOP-ish and goes along
with SOLID) but without the overhead of checking everytime you get an
array of something...

"Type-checking is not PHP"

PHP is a loosely typed language. It allows arrays to contain a mixture
of content. It is very vague. GREAT.

Type-hints are lovely for when you do not want to be vague.

A plain-old function declaration:

"Give me a bag of stuff, and I'll try using everything like it's a
spanner, but it could be a banana and... well I guess my wing-nuts
will get covered in banana gunk, but whatever, YAY WEAK TYPING."

or

"Give me a bag of stuff and I'll fish around in there trying to
find spanners, and ignore everything else"

This RFC optionally allows developers to say:

"Give me a bag of spanners, and break if they put anything else in
there."

Optional, opt-in, simple, logical, useful.

PHP is a multi-paradigm language. It won't enforce you to use some
concrete paradigm, even if we do implement generics...

Syntax

There have been a lot of people suggesting various types of syntax. As
Joe said, using generics syntax for not generics would be a travesty,
and an overcomplication of what should be a simple feature.

For those who hate OOP, array of would be a lovely way to ask for an
array of callables. Trying to make generics happen is a great way to
force not only new syntax, but a brand new OOP paradigm that will be
new for EVERYONE, so ignoring that syntax and letting our functional
and OOP folks have a nice thing shouldn't be considered a negative.

I would love to get generics as long as typed arrays. And when I say typed
arrays I mean array which can hold only the elements of said class (not an
interface). It's not just semantics, it's also optimization that can be
done when you know that array will hold only elements of the said type.
(You know how much memory element will take. It'll make a room for
possible optimizations)

Sorry for some sharp words...

10 years ago by Stas Malyshev — view source

unread

Hi!

This RFC optionally allows developers to say:

"Give me a bag of spanners, and break if they put anything else in there."

Note that neither generics nor array strict typing gives you that.
Neither of them can control what is being put into the bag. The only
thing you can do is to look in the bag and reject what has been put
there post-factum (actually, with generics you can't do even that -
generics parametrize you types, but you still have to have the
typechecks somewhere, so from type checking point generics change
nothing) - i.e. the check happens not when something is put in the bag
but when you get the bag and you have to examine that bag (every single
time you touch it) and pull out each element of it and ensure it is
still a spanner. If you put the bag down, next time you touch it you
have to pull out every single thing out of the bag and check if it is a
spanner again. Is it really the bag you want to deal with? I wouldn't
really want to own such bag, I'm not OCD enough for that :)

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Sara Golemon — view source

unread

Note that neither generics nor array strict typing gives you that.
Neither of them can control what is being put into the bag. The only
thing you can do is to look in the bag and reject what has been put
there post-factum (actually, with generics you can't do even that -
generics parametrize you types, but you still have to have the
typechecks somewhere, so from type checking point generics change
nothing) - i.e. the check happens not when something is put in the bag
but when you get the bag and you have to examine that bag (every single
time you touch it) and pull out each element of it and ensure it is
still a spanner. If you put the bag down, next time you touch it you
have to pull out every single thing out of the bag and check if it is a
spanner again. Is it really the bag you want to deal with? I wouldn't
really want to own such bag, I'm not OCD enough for that :)

Well, arrayof using generics-like syntax doesn't give you entrance
type checking, but actual generics would. Or, to map it into current
PHP terms:

private $spanners = [];
public function __offsetset($key, $value) { if (!($value instanceof
Spanner)) throw new Exception("F-off"); $this->spanners[] = $value; }

But this RFC isn't about generics, it's about arrayof typehinting and
ways to make that work for PHP. Your point about perf is absolutely
valid and one which I'd still like to hear addressed.

-Sara

10 years ago by Stas Malyshev — view source

unread

Hi!

private $spanners = [];
public function __offsetset($key, $value) { if (!($value instanceof
Spanner)) throw new Exception("F-off"); $this->spanners[] = $value; }

Right! So I don't see anything wrong with that. I'd be even OK with:

public function __offsetset($key, Spanner $value) {
$this->spanners[$key] = $value;
}

And that IMO covers 90% of use cases for Spanners[].

But, thinking more about it, if I had to choose between the two with
no other options, I'd probably be happier with ArrayOf<Spanner>
(provided that actually means just a generated class ArrayOf$Spanner and
not checking every element of the actual array). Though IMO even this
case if handled by one line of code, but at least here I can see some
use case (namely, code generation if you have thousands of ArrayOf
things and you really need to typecheck each and every one of them).
Whether we need it or not is a bit of broader discussion - which I am
leaning to "not" but we could argue about it. But at least it feels for
me more "natural" - you just generate a bunch of code (there are a
number of cans on worms in it but I ignore it for now). Checking each
element post-factum just feels wrong way to approach it. It's like
taking you car to a mechanic each time you'd like to drive somewhere
(yes, car analogy, I live in America, what do you expect?)

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Lester Caine — view source

unread

Stas Malyshev wrote:

But at least it feels for
me more "natural" - you just generate a bunch of code (there are a
number of cans on worms in it but I ignore it for now). Checking each
element post-factum just feels wrong way to approach it.

I write the code for the spanner ... which will only ever create a spanner ...
then I call it N times to create the bag of spanners perhaps with a parameter
for the size of the spanner. Why do I need something to stop me adding an
adjustable wrench to the bag? I just don't call any other code when adding to
that bag? But I can also add sockets to the bag if I want different types of nut
tools ... There is no 'extra' code, we need the code to creat the basic object
anyway?

I may want to create a bag with a fixed number of spaces for spanners, so I
create a bag of N 'NULL' spaces which I can then upgrade to a spanner object
later. These 'NULL' objects are simply sizes of spanner that we don't currently
have yet. A more practical example of this would be with my genealogical data
where we have spaces for ancestors - parents/grandparents - but these objects
have not yet been identified. They are still 'person' objects but we don't need
to create an empty person object, just an empty element in the array? We only
create a real object when we have the data to create it.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

10 years ago by Andrea Faulds — view source

unread

This is a quite good point. If we're introducing limited-scope Generics
here, what's wrong with using Generics syntax, especially since it will be
familiar to C#, C++ and Java users?

If we use the generics syntax for not-generics, then we can't EVER
implement generics properly, so that would be an incredibly bad idea.

But these are generics. If we add "proper generics" in future,
Array<int> would keep meaning the same thing, though I suppose we'd need
to allow implict casting of Arrays of ints. That's all that'd change.
This doesn't block adding proper generics, it adds a weak and limited
form of them for arrays only, which could be improved in performance
with "proper" generics later if we so wished.

--
Andrea Faulds
http://ajf.me/

10 years ago by Robert Stoll — view source

unread

I would love to get generics as long as typed arrays. And when I say typed
arrays I mean array which can hold only the elements of said class (not an
interface). It's not just semantics, it's also optimization that can be
done when you know that array will hold only elements of the said type.
(You know how much memory element will take. It'll make a room for
possible optimizations)

Hm.. I did not understand the RFC this way. It says, "allowing an array of that hinted type to be passed as an argument", so I assumed it would work with interfaces as well.
And what about sub-types?

10 years ago by Philip Sturgeon — view source

unread

I would love to get generics as long as typed arrays. And when I say typed
arrays I mean array which can hold only the elements of said class (not an
interface). It's not just semantics, it's also optimization that can be
done when you know that array will hold only elements of the said type.
(You know how much memory element will take. It'll make a room for
possible optimizations)

Hm.. I did not understand the RFC this way. It says, "allowing an array of that hinted type to be passed as an argument", so I assumed it would work with interfaces as well.
And what about sub-types?

--

The RFC supports type-hinting against anything that you can currently
type-hint against, just with the addition of [] to say "an array of
them."

10 years ago by Sara Golemon — view source

unread

Why should this RFC get put on hold forever because people cannot come
to an agreement about scalar type hints? Why would it be better,
quicker, or easier this time? :)

It shouldn't, by any measure. I'm just saying that ignoring scalars
doesn't buy us anything in understanding how typed array hints are
useful. The topic is argument type hinting, scalars are a component
of that, even if not an essential component of this RFC.

ArrayOf is not a separate topic from Generics, it is by definition a
narrowly-scoped form of generics. "ArrayOf Foo" is a "Foo"
specialization of the array generic (even if it's not labeled as such
due to not having other types of generics). "This is an array, but
it's an array just for Foos". Can arrayof be implemented in a way
which hides this heritage? Sure, but should it?

I respectfully but strongly disagree.

This feature: "I would like a bag of spanners"

Generics: "I would like a polyester bag full of spanners, and this
is how you should put those spanners into that bag."

I respectfully by strongly disagree.

ArrayOf: "I would like hammers in a bag."
Generics: "I would like a bag of hammers."

Pros

You can be very certain what you are putting in there
It's a little quicker than checking an array of content

Cons

Definitely "forcing OOP on people"
Require the user to do stuff outside of the method declaration that
they dont care about
It's a whole new topic, instead of a simple improvement.

These arguments apply to broadly-scoped Generics, but not to the
specifics of presenting arrays as a generics specialization.

It does not enforce OOP on anyone. It does not require anyone to do
anything outside of the method declaration. I'm sorry, but those
arguments are simply untrue.

I know you'd like to see generics in PHP, and while I personally don't
care too much about them you have support from Joe and others. It
would be great of generics could be done, but this is not generics.
This is "I want an array of Foo", which soon will be "I want an array
of integers". I hope to god we don't suggest that people create a
generic to ask for an array of co-odinates.

I agree, and I'm not asking for Generics. Honestly, I'm not even too
bothered whether we see generics or not, so don't tell me what my
opinions are. I'm including a discussion of generics in my comments
on ArrayOf because of their clear overlap. I'm sorry you can't see
that.

Ignoring elements which fit closely together is a short-sighted mistake.

And trying to bundle things in together which seem to vaguely overlap
is a very quick way to get stuck in the mud. :)

Yes, but that has nothing to do with the topic at hand since they fit
so well together. I can't imagine why you included such a
nonsequiter...

-Sara

10 years ago by Stas Malyshev — view source

unread

Hi!

ArrayOf: "I would like hammers in a bag."
Generics: "I would like a bag of hammers."

Generics are more like "I would like a 100lb to 120lb bag of hammers
with handles made of wood grown in equatorial Africa between 1980 and
1985, not cut down during national holidays in Brazil and provided all
workers were paid the fair wage, while the heads must be made of steel
approved by German Council of Steel Manufacturers, and the assembly must
have been performed in a country that signed the convention about the
ethical treatment of animals". You'd want arrays of arrays of foo, and
arrays that have keys of foo and values be arrays of tuples of bar and
baz, etc. etc.
I can definitely see a contract that would require hammers exactly like
that, or even with more precise list of conditions, but do we want this
in the PHP language itself (as opposed to delegating it to the
user/library code)? I personally don't really want it as a part of the
language. I think keeping language small(ish) and simple has its value.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Sara Golemon — view source

unread

ArrayOf: "I would like hammers in a bag."
Generics: "I would like a bag of hammers."

Generics are more like "I would like a 100lb to 120lb bag of hammers
with handles made of wood grown in equatorial Africa between 1980 and
1985, not cut down during national holidays in Brazil and provided all
workers were paid the fair wage, while the heads must be made of steel
approved by German Council of Steel Manufacturers, and the assembly must
have been performed in a country that signed the convention about the
ethical treatment of animals". You'd want arrays of arrays of foo, and
arrays that have keys of foo and values be arrays of tuples of bar and
baz, etc. etc.
I can definitely see a contract that would require hammers exactly like
that, or even with more precise list of conditions, but do we want this
in the PHP language itself (as opposed to delegating it to the
user/library code)? I personally don't really want it as a part of the
language. I think keeping language small(ish) and simple has its value.

I can only assume you're using sarcasm to highlight the ridiculousness
of that argument, because I know you, and you're not NEARLY that much
of an idiot.

-Sara

10 years ago by Stas Malyshev — view source

unread

Hi!

I can only assume you're using sarcasm to highlight the ridiculousness
of that argument, because I know you, and you're not NEARLY that much
of an idiot.

Thanks for you kind words (though I would really prefer to keep the
topic on PHP and not on appraisal of my mental capacities, however
excellent they may appear), but it is not ridiculous not in a little
bit. I've seen genericized code in big projects, I've seen it both in
Java and C++ (oh horrors!) and when it gets into the third level of
templates (and it will) I don't think I want to go there if I can help it.
I understand the value it may have for enormous projects with automatic
code generation and type checking tools but my opinion is that is not
the way PHP should be going towards. I think 90% of the use cases can
and should be easily done in user code, and remaining 10% should be
still done in user code, even though it would require additional effort.
Yes, those 10% would be much easier if PHP language has support for
them, but I see value in not sacrificing simplicity for the sake of 10%
(actually, I think it's more like 0.1% but that's my personal assessment
not based on any research).

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Sara Golemon — view source

unread

it is not ridiculous not in a little
bit. I've seen genericized code in big projects, I've seen it both in
Java and C++ (oh horrors!) and when it gets into the third level of
templates (and it will) I don't think I want to go there if I can help it.

And people can write horrendous looking code with PHP as it is now,
but that doesn't have anything to do with whether or not PHP can be
used to write quality software.

I called your analogy ridiculous because it doesn't take the
comparison seriously. I can write a function which requires 10,000
parameters, does that mean that we should remove functions from the
language? Come off it.

-Sara

10 years ago by Stas Malyshev — view source

unread

Hi!

I called your analogy ridiculous because it doesn't take the
comparison seriously. I can write a function which requires 10,000
parameters, does that mean that we should remove functions from the
language? Come off it.

It is all about size of the use case. In my opinion, in language like
PHP most of the generics use would be overengineering and
overcomplication of things that should be simple - like trying to
exactly define the detailed types and subtypes of a deep structure in a
wrong point - where the structure already exists and being passed around

instead of ensuring the integrity of the structure when it is being
created and updated. Or overspecifying and overdetalizing the types of
the elements of the structure in the environment where it produces no
benefit (e.g., non-compiled dynamic language environment).

I am perfectly aware that there are use cases where it legitimately
serves a useful purpose - e.g. huge projects which have rigid coding
rules, static typecheck tools and which require it to control complexity
which can not be controlled otherwise. I just doubt it is a good use
case for PHP. I feel it is just making it - yes, I know it is being said
100 times and not always appropriately, but that's exactly how I feel
here - Java with dollar signs and integer-to-string conversions.

And I do not accept the argument of "if you don't like it, you don't
have to use it". It is true, but only to a point. You can, in theory,
use C++ without templates. In practice, if you want to call yourself a
C++ programmer, you can not ignore them, not now. Language is also an
ecosystem, and I think Java-ifying PHP would take the ecosystem not in
the right direction. You, of course, may disagree and thing it is
exactly the right direction - there is always a moment where preferences
which are subjective come to play and in such a moment there's nothing
to do but agree to disagree.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Sara Golemon — view source

unread

This is a quite good point. If we're introducing limited-scope Generics
here, what's wrong with using Generics syntax, especially since it will be
familiar to C#, C++ and Java users?

If we use the generics syntax for not-generics, then we can't EVER
implement generics properly, so that would be an incredibly bad idea.

That's an excellent point, and all the better reason to discuss their
overlap NOW, rather than further down the road when we can't change
arrayof syntax.

To borrow from another message in this thread:

Dictionary<int, string>[] foo <-- Is that really what you want an
array of int->string dictionaries to look like? Really?

-Sara

10 years ago by Crypto Compress — view source

unread

Am 20.01.2014 20:55, schrieb Sara Golemon:

Dictionary<int, string>[] foo <-- Is that really what you want an
array of int->string dictionaries to look like? Really?

Yes, i like this clean separation between base/scalar types and
generics. We can have this RFC and generics. Can't see any problems
here. This is not critique of your work or generics!

Discussed performance penalty got in long time before this RFC:
http://3v4l.org/os5Gg

The only thing to solve is the nullable-issue...

cryptocompress

10 years ago by Sara Golemon — view source

unread

Dictionary<int, string>[] foo <-- Is that really what you want an
array of int->string dictionaries to look like? Really?

Yes, i like this clean separation between base/scalar types and generics. We
can have this RFC and generics. Can't see any problems here. This is not
critique of your work or generics!

Eh... Makes one of us then. I think that syntax looks horrendous.
Agree to disagree.

Discussed performance penalty got in long time before this RFC:
http://3v4l.org/os5Gg

That's not a discussion, that's a contrived benchmark, and a deeply
flawed one since it amplifies general function call overhead and
doesn't look at type-checking arbitrarily large arrays, let alone
nested arrays. That benchmark was designed to lose any perf hit in
the noise.

The only thing to solve is the nullable-issue...

Apart from performance and syntax.

-Sara

10 years ago by Stas Malyshev — view source

unread

Hi!

Dictionary<int, string>[] foo <-- Is that really what you want an
array of int->string dictionaries to look like? Really?

In every (popular) dynamic language on a planet (Perl, Python, Ruby,
Javascript, Lua, Groovy) it looks roughly like that (within syntax
variations):

foo = [Dictionary()]

I wonder why it is enough for them? Are they all missing something very
important?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Sara Golemon — view source

unread

Dictionary<int, string>[] foo <-- Is that really what you want an
array of int->string dictionaries to look like? Really?

In every (popular) dynamic language on a planet (Perl, Python, Ruby,
Javascript, Lua, Groovy) it looks roughly like that (within syntax
variations):

foo = [Dictionary()]

I wonder why it is enough for them? Are they all missing something very
important?

To quote someone who's skill and abilities I respect: "Just because
they do it some way in X, doesn't mean it belongs in PHP."

Hint, I'm talking about you.

-Sara

10 years ago by Stas Malyshev — view source

unread

Hi!

I wonder why it is enough for them? Are they all missing something very
important?

To quote someone who's skill and abilities I respect: "Just because
they do it some way in X, doesn't mean it belongs in PHP."

That is true. But this is not "just because" - I'm not arguing about any
specific syntax or even semantics. I'm talking about all of them not
even going in that general direction and still being fine. That makes me
question if the need for generics is that great and if they actually are
a good fit for a dynamic language, at least in a way that they are
presented - i.e. as type checking mechanism, not as code generation
mechanism. I could repeat the regular arguments why I think they are not
if you'd like - I did it on this list like 100 times and everybody is
tired and hating me for that already, but I could do it again on popular
request. So it's not the only argument. It is an additional argument
providing some perspective.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Sara Golemon — view source

unread

To quote someone who's skill and abilities I respect: "Just because
they do it some way in X, doesn't mean it belongs in PHP."

That is true. But this is not "just because" - I'm not arguing about any
specific syntax or even semantics. I'm talking about all of them not
even going in that general direction and still being fine. That makes me
question if the need for generics is that great and if they actually are
a good fit for a dynamic language, at least in a way that they are
presented - i.e. as type checking mechanism, not as code generation
mechanism. I could repeat the regular arguments why I think they are not
if you'd like - I did it on this list like 100 times and everybody is
tired and hating me for that already, but I could do it again on popular
request. So it's not the only argument. It is an additional argument
providing some perspective.

This is an issue that keeps coming up. Calling for typed arrays to
look like generics is not the same as calling for generics.

It's an acknowledgement that there is a fundamental shared behavior
between the two. A generic implementing ArrayAccess and Traversable
is not different FROM A USERSPACE POINT OF VIEW from a typed array
(apart from object psuedoreference semantics and the ability to check
on input). Given that they look the same FROM A USERSPACE POINT OF
VIEW, they should share common syntax.

This does not mean that we have to add (or even agree to add) generics
in order to adopt typed arrays. This does not mean the implementation
of typed arrays need share anything in common with generics should
they be someday be voted in.

This is just thinking of the consistency of the language.
This is about how the user interacts with the syntax.

-Sara

10 years ago by Crypto Compress — view source

unread

Yeah, ability to check on input and to blend syntax are the reasons for
generics to came up in this discussion. whirl whirl
Even generics can solve this, it's not part of this RFC. Nor is this RFC
somehow prevent generics. They can coexist:

Dictionary<int, string>[] foo
Array<Dictionary<int, string>> foo

Consider to vote "no" and stop derailing this RFC.

10 years ago by Andrea Faulds — view source

unread

Hi!

Dictionary<int, string>[] foo <-- Is that really what you want an
array of int->string dictionaries to look like? Really?

In every (popular) dynamic language on a planet (Perl, Python, Ruby,
Javascript, Lua, Groovy) it looks roughly like that (within syntax
variations):

foo = [Dictionary()]

I wonder why it is enough for them? Are they all missing something very
important?

You might note that what you've just provided an example of is not, in
fact, a type specifier. It is a literal.

For a similar reductio ad absurdiam, I might as well give an example
from C - a struct literal:

foo = {7, 5, create_list(), {"this is a string"}}

It serves no usefulness to the conversation here. This is about type
specifiers, not literals.

Andrea Faulds
http://ajf.me/

10 years ago by Andrea Faulds — view source

unread

Again, using generics for not-generics is a really bad idea, as we
then cannot have generics at any point in the future. Even if we find
a way to squash them both into the same syntax then it just becomes
confusing for the user.

But these are generics...

Wait, how on earth is anything more simple than ONLY adding "[]"? :)

Because inconsistency, damnit.

--
Andrea Faulds
http://ajf.me/

10 years ago by Andrea Faulds — view source

unread

No, they are not generics. They do not require setup or definition of
ANY kind, they are jsut arrays of content.

Right. Implict Array of int to Array<int> cast. These are generics.

Uses purely as an example (not as statement of love for Java), Java
does have both. They are not alternatives to the same goal.

Java arrays and PHP arrays are hardly comparable.

--
Andrea Faulds
http://ajf.me/

10 years ago by Sara Golemon — view source

unread

ArrayOf: "I would like hammers in a bag."
Generics: "I would like a bag of hammers."

I don't want to bicker analogies but yours is inaccurate. You have to
specify a specific type of bag, ask it to be constructed before being
passed to the method which checks for it, and that is not at all the
same as checking contents of an argument being passed.

And yet you bicker.

Specify a type of bag: Applies regardless. It's a bag of hammers,
then specifying has been done.
Ask it to be constructed: Applies regardless. That's was $x = array(); is.
Checking contents: The topic of the RFC is typed arrays (or arrays
containing a type, if you prefer). For that to be meaningful the
contents much be checked. They can be checked at call time,
population time, or compile time. They are however, being checked.

The two things are very different.

The two ways of looking at them are different. The metaphor is the same.

It would be like saying: "Why would you ever want to type-hint for a
callable, when you can create a CallableWrapper object, pass it a
callable in a setter, then check for the object name." Obviously that
is not a viable suggestion, and that is what is being discussed as an
alternative for this arrayof RFC by trying to replace them with
generics.

This is a full-on hijack.

Bullshit.

To borrow your expression; That's got fuck-all to do with what we've
been discussing. You're just making shit up at this point and you
need to cut that crap out.

NOBODY IS SUGGESTING REPLACING "array" WITH AN OBJECT. I don't know
how much clearer I can state that.

I see they have an overlap, and they have been discussed. I am however
pointing out (to others) that using generics in place of this feature
is not as wonderful of a solution as they seem to think, and using the
syntax is not ideal for other reasons (also discussed).

Discussed, but your position is not taken as fact.
In fact, I've taken rather the opposite conclusion since I see a
number of unaddressed problems with the original RFC. Based on those
problems not being addressed, I'm currently leaning on the side of
voting "No", despite the fact that I'd generally like to see some sort
of arrayof (whether or not it looks like a generic).

Further, posts like yours which seek to shut down relevant discussion
stand out as a very large call against the RFC. I'm sorry that you
want to shut your own RFC down, but I'm not going to make guesses at
your reasons for that.

Discussing them is one thing. Discussions are great. When that
discussion leads to the suggestion of using one instead of the other,
well... that leads us to where we are now: stuck in the mud.

Where is discussion supposed to lead if NOT to a preference for a
course of action?

-Sara

10 years ago by Joe Watkins — view source

unread

ArrayOf: "I would like hammers in a bag."
Generics: "I would like a bag of hammers."
I don't want to bicker analogies but yours is inaccurate. You have to
specify a specific type of bag, ask it to be constructed before being
passed to the method which checks for it, and that is not at all the
same as checking contents of an argument being passed.

And yet you bicker.

Specify a type of bag: Applies regardless. It's a bag of hammers,
then specifying has been done.
Ask it to be constructed: Applies regardless. That's was $x = array(); is.
Checking contents: The topic of the RFC is typed arrays (or arrays
containing a type, if you prefer). For that to be meaningful the
contents much be checked. They can be checked at call time,
population time, or compile time. They are however, being checked.

The two things are very different.

The two ways of looking at them are different. The metaphor is the same.

It would be like saying: "Why would you ever want to type-hint for a
callable, when you can create a CallableWrapper object, pass it a
callable in a setter, then check for the object name." Obviously that
is not a viable suggestion, and that is what is being discussed as an
alternative for this arrayof RFC by trying to replace them with
generics.

This is a full-on hijack.

Bullshit.

To borrow your expression; That's got fuck-all to do with what we've
been discussing. You're just making shit up at this point and you
need to cut that crap out.

NOBODY IS SUGGESTING REPLACING "array" WITH AN OBJECT. I don't know
how much clearer I can state that.

I see they have an overlap, and they have been discussed. I am however
pointing out (to others) that using generics in place of this feature
is not as wonderful of a solution as they seem to think, and using the
syntax is not ideal for other reasons (also discussed).

Discussed, but your position is not taken as fact.
In fact, I've taken rather the opposite conclusion since I see a
number of unaddressed problems with the original RFC. Based on those
problems not being addressed, I'm currently leaning on the side of
voting "No", despite the fact that I'd generally like to see some sort
of arrayof (whether or not it looks like a generic).

Further, posts like yours which seek to shut down relevant discussion
stand out as a very large call against the RFC. I'm sorry that you
want to shut your own RFC down, but I'm not going to make guesses at
your reasons for that.

Discussing them is one thing. Discussions are great. When that
discussion leads to the suggestion of using one instead of the other,
well... that leads us to where we are now: stuck in the mud.

Where is discussion supposed to lead if NOT to a preference for a
course of action?

-Sara

Sara,

 We, actually I, put a wall up between this and generics because I

thought it was the correct thing to do, I thought easier to explain to
everyone when generics do come along, and I want them to come along ....
I don't really want them to like this, but can quite easily be wrong,
and probably am ...

 Phil is not shutting down conversation but trying to keep it

focused on what he sees are the issues.

 We appreciate your involvement, of course :)

https://github.com/krakjoe/php-src/compare/arrayof-generics

 He kept them separate because I told him to, I see them as such, I

use them as such, we're both quite happy to discuss a more PHP way of
doing things ... the syntax is not all important, I was only trying to
be sensible, like I said, I can easily be wrong ...

 If we can just get back to being friendly and productive that'd be

great.

Cheers
Joe

Introducing "Array Of" RFC

I have one question, however. Though I doubt it would be a frequent usage, would { function (StdClass[][] $x) {} } work, for representing an array of arrays?

-- Lester Caine - G8HFL

--

Cheers,

-- Lester Caine - G8HFL

Scalar Type Hints

Generics

Use-cases

"Type-checking is not PHP"

Performance

Enforcing OOP

Doesn't Handle Traversable

"Just use collections"

Syntax

Allowing Nulls

This is a quite good point. If we're introducing limited-scope Generics here, what's wrong with using Generics syntax, especially since it will be familiar to C#, C++ and Java users?

Syntax

Generics

"Type-checking is not PHP"

Syntax

-- Lester Caine - G8HFL

Pros

Cons

I wonder why it is enough for them? Are they all missing something very important?

It serves no usefulness to the conversation here. This is about type specifiers, not literals.

I have one question, however. Though I doubt it would be a frequent
usage, would { function (StdClass[][] $x) {} } work, for representing an
array of arrays?

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

This is a quite good point. If we're introducing limited-scope Generics
here, what's wrong with using Generics syntax, especially since it will
be familiar to C#, C++ and Java users?

--
Lester Caine - G8HFL

I wonder why it is enough for them? Are they all missing something very
important?

It serves no usefulness to the conversation here. This is about type
specifiers, not literals.