# Introducing "Array Of" RFC - Thread: https://externals.io/message/71192 - Original archive: https://news-web.php.net/php.internals/71192 - Started by Andrey Andreev on 2014-01-16T20:14:08+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/71192.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #71192 — Andrey Andreev — 2014-01-16T20:14:08+00:00 URL: https://externals.io/message/71192#71192 Am I the only one who finds both proposed syntaxes somewhat confusing? The originally proposed 'Bar[]' simply looks strange. HHVM's introduces even more "special characters" (<, >, ?) to parse, looks a bit like a regular expression and it was even already mentioned that it's "imported" from C++ ... PHP is not C++, and why should it be? So, how about this: Array[Bar] $a - $a is array containing only instances of Bar Array[Bar|null] $a - $a is array containing Bar instances or nulls Array[Bar] $a = null - $a is either null or array containing only instances of Bar Array[Bar|null] $a = null - above, but the array can contain nulls It's easily readable and everybody should be able to recognize what this thing does even without prior knowledge. Hell, why not Array[Foo|Bar|stdClass|whocares] ? Or even (at a later stage): Array[]["key1", "key2"] ... which would hint for a numeric index array containing associative arrays that in turn must have the defined keys. This is indeed a bit crazy, but possible to add in the future without BC breaks. You could even shove scalar typehints in there as soon as they are implemented. Cheers. Andrey. --- ## #71193 — Andrea Faulds — 2014-01-16T20:20:35+00:00 URL: https://externals.io/message/71192#71193 · In reply to: #71192 > Am I the only one who finds both proposed syntaxes somewhat confusing? > > The originally proposed 'Bar[]' simply looks strange. It is, however, familiar to C, C++, C# and Java users. > So, how about this: > > Array[Bar] $a - $a is array containing only instances of Bar > Array[Bar|null] $a - $a is array containing Bar instances or nulls > Array[Bar] $a = null - $a is either null or array containing only > instances of Bar > Array[Bar|null] $a = null - above, but the array can contain nulls That doesn't make much sense as a syntax, IMO. It looks like "Bar" is the index of the Array here. Surely it could use angle brackets, which would be familiar to people who've dealt with generics (C++, C#, Java users): Array $a > It's easily readable and everybody should be able to recognize what this > thing does even without prior knowledge. It's not clear to me at all at first glance. Is that a Bar-indexed array? > Or even (at a later stage): > > Array[]["key1", "key2"] > > ... which would hint for a numeric index array containing associative > arrays that in turn must have the defined keys. This is indeed a bit crazy, > but possible to add in the future without BC breaks. You could even shove > scalar typehints in there as soon as they are implemented. ...that's even less intuitive to me. -- Andrea Faulds http://ajf.me/ --- ## #71194 — Andrey Andreev — 2014-01-16T20:28:05+00:00 URL: https://externals.io/message/71192#71194 · In reply to: #71193 Okay, so for contents and [Bar] for keys, although AFAIK you can't use objects as array keys. These were all random thoughts, I haven't though about it all in depth. Still, I believe it's more intuitive than both previous proposals. > > > > > > […] > > It is, however, familiar to C, C++, C# and Java users. > > > So, how about this: > > […] > > That doesn't make much sense as a syntax, IMO. It looks like "Bar" is the > index of the Array here. Surely it could use angle brackets, which would be > familiar to people who've dealt with generics (C++, C#, Java users): > > Array $a > > > It's easily readable and everybody should be able to recognize what this > > […] > > It's not clear to me at all at first glance. Is that a Bar-indexed array? > > > Or even (at a later stage): > > […] > > ...that's even less intuitive to me. > -- > Andrea Faulds > http://ajf.me/ --- ## #71195 — Sara Golemon — 2014-01-16T20:43:34+00:00 URL: https://externals.io/message/71192#71195 · In reply to: #71194 One last comment in favor of the HHVM syntax: We're written (and will very soon be releasing, I promise) a static analysis tool which looks at your entire code base and determines types for every local variable in use and tells you (without having to run the program) where you have type issues. This means two things: 1) No need to do runtime checks (Which impact performance) 2) No need to get to 100% code-coverage to guarantee type safety. And the type-checker can run in the background re-evaluating the files as they're updated for instant notification. If PHP were to follow HHVM's syntax, we'd get the type-checker as a freebie. (If and when we took on return and scalar type hints as well) -Sara --- ## #71199 — Stas Malyshev — 2014-01-16T23:05:43+00:00 URL: https://externals.io/message/71192#71199 · In reply to: #71192 Hi! > It's easily readable and everybody should be able to recognize what this > thing does even without prior knowledge. > > Hell, why not Array[Foo|Bar|stdClass|whocares] ? > > Or even (at a later stage): > > Array[]["key1", "key2"] I don't think inventing another language to specify types inside PHP is a good idea. If somebody is really into type calculus, there are many academic languages to play with. In practice, such byzantine constructs rarely make developer's work easier on tasks that PHP is commonly applied to. If you want a language that can run code to check if your array conforms to arbitrary set of rules, what's wrong with PHP language? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #71200 — Stas Malyshev — 2014-01-16T23:07:52+00:00 URL: https://externals.io/message/71192#71200 · In reply to: #71195 Hi! > If PHP were to follow HHVM's syntax, we'd get the type-checker as a > freebie. (If and when we took on return and scalar type hints as > well) I'm pretty sure if such tool were open source, it would not be hard to patch it to follow any syntax, provided underlying sematics is the same. It probably parses the code into some kind of internal representation anyway, so by slightly changing that parser you will be able to accommodate any syntax. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #71202 — Alexander M — 2014-01-17T08:00:24+00:00 URL: https://externals.io/message/71192#71202 · In reply to: #71200 What I find interesting is that the title of the RFC is "Array Of", proposing a type hint for an "array of Foo". In my opinion the proposed syntax however reads more as "Foos in an array"? Foo[] => Foo in/as an array array => array of Foo I personally like the idea of array because it seems to leave more room for improvements and additions over time (nesting array>, k/v typehints array). Best, Alexander --- ## #71205 — Andrey Andreev — 2014-01-17T09:33:32+00:00 URL: https://externals.io/message/71192#71205 On Fri, Jan 17, 2014 at 1:05 AM, Stas Malyshev wrote: > Hi! > > > […] > > I don't think inventing another language to specify types inside PHP is > a good idea. If somebody is really into type calculus, there are many > academic languages to play with. In practice, such byzantine constructs > rarely make developer's work easier on tasks that PHP is commonly > applied to. If you want a language that can run code to check if your > array conforms to arbitrary set of rules, what's wrong with PHP language? > Maybe I wasn't clear enough about it, but I did note several times that what you quoted is not in the current scope of the RFC we're discussing. I was trying to explain how this syntax would be forward-compatible and instead of commenting on my main point, you take this single part out of context and somehow manage to twist it like I was saying something against PHP - not cool. Anyway, I'm not attempting to invent another language (or rather, a "sub-language") for type hinting. In fact, I was trying to make it more similar to PHP's current syntax. Array typehints currently are written via the 'Array' keyword, hence why I find the originally proposed 'className[]' to be a bit bizzare. The '|' character is indeed new into this, but it is close enough to the || "or" operator that everybody is familiar with and a comma wouldn't really hint at "or" at first glance. Cheers, Andrey. --- ## #71277 — Andrey Andreev — 2014-01-19T19:07:49+00:00 URL: https://externals.io/message/71192#71277 · In reply to: #71205 > 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 an RFC, not a vote. I personally wasn't trying to reject this feature while proposing an alternative syntax, and my guess is that Sara Golemon didn't either. The goal is to improve on it. Cheers, Andrey. --- ## #71363 — Andrey Andreev — 2014-01-20T22:00:39+00:00 URL: https://externals.io/message/71192#71363 · In reply to: #71277 Please excuse my lack of knowledge, but if I understand this correctly, this is how generics would work ... using arrays, ignore the syntax and details such as child classes, interfaces, etc.: $fruits = Array; - declare that $fruits is an array that can only contain instances of class Fruit function eat(Array $apples) - function eat() will only accept arrays that are declared in the same way as $fruits above If that is so, then I deffinately see how this RFC is similar to generics and how generics would give us higher performance. But I also see how it is different and how it serves for another (yet indeed similar) purpose. I wouldn't rule out either feature, but if that is what you people want, why don't you vote on: a) array of; b) generics; c) both and be done with it. I surely do understand why Phil Sturgeon got so heated about the discussion going nowhere - at least 3 separate topics are being discussed here and everybody has an opinion on all of them separately. This isn't productive. --- ## #71364 — Stas Malyshev — 2014-01-20T22:05:56+00:00 URL: https://externals.io/message/71192#71364 · In reply to: #71363 Hi! > Please excuse my lack of knowledge, but if I understand this correctly, > this is how generics would work ... using arrays, ignore the syntax and > details such as child classes, interfaces, etc.: > > $fruits = Array; - declare that $fruits is an array that can only > contain instances of class Fruit > function eat(Array $apples) - function eat() will only accept > arrays that are declared in the same way as $fruits above There's two ways to understand "will only accept": 1. There's a class/type which I call ArrayOfFruit for simplicity. eat() checks if $apples is instance of ArrayOfFruit. Some magic inside ArrayOfFruit ensures ArrayOfFruit always contains only Fruit. 2. eat() goes over $apples which is a regular array, and checks if every element in it is instanceof Fruit. First way is essentially templates, second is not. So far I've seen most advocacy in this RFC to go towards the second way. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #71367 — Andrea Faulds — 2014-01-20T22:33:21+00:00 URL: https://externals.io/message/71192#71367 · In reply to: #71364 > Hi! > > > […] > > There's two ways to understand "will only accept": > > 1. There's a class/type which I call ArrayOfFruit for simplicity. eat() > checks if $apples is instance of ArrayOfFruit. Some magic inside > ArrayOfFruit ensures ArrayOfFruit always contains only Fruit. > 2. eat() goes over $apples which is a regular array, and checks if every > element in it is instanceof Fruit. > > First way is essentially templates, second is not. So far I've seen most > advocacy in this RFC to go towards the second way. > Myself, I want 2 now with syntax that will eventually work for 1 too in the future. Soft generics. Array could implicitly cast to Array so long as all its members are fruit, in future. But for now, it will only be 2. This adds an incentive to add generics: better performance by not requiring a runtime check when an Array is passed an not an Array of Fruit. -- Andrea Faulds http://ajf.me/ --- ## #71368 — Philip Sturgeon — 2014-01-20T22:39:22+00:00 URL: https://externals.io/message/71192#71368 · In reply to: #71363 > Please excuse my lack of knowledge, but if I understand this correctly, > this is how generics would work ... using arrays, ignore the syntax and > details such as child classes, interfaces, etc.: > > $fruits = Array; - declare that $fruits is an array that can only > contain instances of class Fruit > function eat(Array $apples) - function eat() will only accept > arrays that are declared in the same way as $fruits above > > If that is so, then I deffinately see how this RFC is similar to generics > and how generics would give us higher performance. But I also see how it is > different and how it serves for another (yet indeed similar) purpose. > > I wouldn't rule out either feature, but if that is what you people want, > why don't you vote on: > > a) array of; b) generics; c) both > > and be done with it. I surely do understand why Phil Sturgeon got so heated > about the discussion going nowhere - at least 3 separate topics are being > discussed here and everybody has an opinion on all of them separately. This > isn't productive. The conversation certainly escalated, but not through my doing. I didn't say the conversation was going nowhere, I said much of it was not discussing relevant points. This was down to confusion on some points, only one of which was generics. There are two things being discussed as one by many, which is causing confusion for me and probably for others too. 1. Generics, instead of Array Of 2. Generics syntax for Array Of With some people suggesting generics (not Sara) and some suggesting just taking the syntax and using it for array of instead to add "weak generics kinda" then we are crossing threads a little. A vote would certainly help to work out which way people would like to go. Some bullet points. Generics are fine. Generics later are fine. Generics now would require a big recode, so that would be PHP 6 - not now. Array of is simple, and could be done instead. Array of and generics can both live in peace. Both could use the same syntax - and we can talk about that, but that can potentially confuse the user. Discussion on that is fine. As long as we are clear about what is being discussed and proposed, because there are a lot of routes: 1. Array of as is, no generics (for now...?) 2. Array of and generics, different syntax 3. Array of and generics, same syntax 4. No array of, let Generics do all of the work If 4 is picked then it wont be done until a major version. 2 or 3 would need more discussion and delay things a bunch, 1 would get things going. I don't want to stifle discussion, but you can see why it would be beneficial to avoid a contentious subject which is not completely the same thing. --- ## #72844 — Philip Sturgeon — 2014-02-27T21:11:40+00:00 URL: https://externals.io/message/71192#72844 · In reply to: #71368 From the survey I posted ( http://grokbase.com/p/php/php-internals/141rva4cf7/php-dev-vote-array-of-v-generics ) the most popular option seemed to be "C) I want both". While I am not just blindly suggesting we copy Java, they do have both features with different syntax, so the idea for this RFC is going to be: keep on trucking with the array of syntax and we put it to a vote. If people do not like the RFC as it is then we can revisit the syntax, but as people are interested in both features it just makes sense to assume this syntax is up for the job. The only open question remaining is: Should null be an acceptable value inside the array, or can it only contain items of the type specified? The following equivalent code will explain the difference: A) foreach ($foos as $foo) { if (! $foo instanceof Face) { throw new Exception ('AAAGGGGGHHH!'); } } or B) foreach ($foos as $foo) { if (! is_null($foo) and ! $foo instanceof Face) { throw new Exception ('AAAGGGGGHHH!'); } } Logic suggests to me that A makes more sense, as if you ask specifically for an array of "Face" and want to act on it like every single item is an instance of "Face", then letting null's slip into there just adds more boilerplate and introduces a second - and totally uneccessary - array traversal to find them or remove them. So, should we allow nulls in an arrayof-style type hint? --- ## #72845 — Marco Pivetta — 2014-02-27T21:34:20+00:00 URL: https://externals.io/message/71192#72845 · In reply to: #72844 > So, should we allow nulls in an arrayof-style type hint? > > `null` has its own type, which is mismatching the type required by the array-of syntax when requesting, for example, `Foo[]`. If `null` was allowed in the array, as a user, I'd still be forced to `array_filter()` on every call, so it would defeat the new feature completely. Cheers, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #72846 — Andrea Faulds — 2014-02-27T21:34:37+00:00 URL: https://externals.io/message/71192#72846 · In reply to: #72844 > So, should we allow nulls in an arrayof-style type hint? I previously suggested using the C#-style ? to specify nullability. Why can’t we do that? -- Andrea Faulds http://ajf.me/ --- ## #72848 — Larry Garfield — 2014-02-27T22:28:19+00:00 URL: https://externals.io/message/71192#72848 · In reply to: #72845 > > > > […] > `null` has its own type, which is mismatching the type required by the > array-of syntax when requesting, for example, `Foo[]`. > > If `null` was allowed in the array, as a user, I'd still be forced to > `array_filter()` on every call, so it would defeat the new feature > completely. ^^ My general stance. (Unless an "allow both" syntax is possible; if not, the above.) --Larry Garfield --- ## #72853 — Crypto Compress — 2014-02-28T08:11:20+00:00 URL: https://externals.io/message/71192#72853 · In reply to: #72845 Hello List, > So, should we allow nulls in an arrayof-style type hint? No. Null values (optional values) should be allowed within an nullable-arrayof-style type hint. Compare: function foo(Bar $baz = null) and: function foo(Bar $baz) This is not the same syntax and null is not a type. cryptocompress --- ## #72854 — Chris Wright — 2014-02-28T09:04:23+00:00 URL: https://externals.io/message/71192#72854 · In reply to: #72853 On 28 February 2014 08:11, Crypto Compress wrote: > Hello List, > > > > […] > > > No. Null values (optional values) should be allowed within an > nullable-arrayof-style type hint. > > Compare: function foo(Bar $baz = null) > and: function foo(Bar $baz) > > This is not the same syntax and null is not a type. > Are you suggesting the following? function foo(Bar[] $bars) // required to pass an array of Bar objects function foo(Bar[] $bars = null) // required to pass an array of Bar or null members ...because if so, how do I specify an optional array of Bar objects? And how do I specify an optional array of Bar or null? The whole concept of allowing null members seems to completely defeat the purpose of the ArrayOf hint for me. I can understand wanting to make the parameter optional, but I cannot see a use case for null members from the point of view of the caller. I never null out members of an array, I only omit them from the declaration or remove the member from the array via e.g. unset() or stack operations (pop(), shift() etc). YMMV of course, but for me allowing null members just makes the callee's life more difficult and does not gain anything. --- ## #72857 — Lazare Inepologlou — 2014-02-28T09:29:29+00:00 URL: https://externals.io/message/71192#72857 · In reply to: #72853 2014-02-28 9:11 GMT+01:00 Crypto Compress : > Hello List, > > So, should we allow nulls in an arrayof-style type hint? > > […] > > No. Null values (optional values) should be allowed within an > nullable-arrayof-style type hint. > > Compare: function foo(Bar $baz = null) > and: function foo(Bar $baz) > > This is not the same syntax and null is not a type. > > I do not really understand your point here but I want to shout out that null is definitely a type having only one possible value. This is one thing that PHP got right in contrast to Java, C# etc. Lazare INEPOLOGLOU Ingénieur Logiciel > > cryptocompress --- ## #72858 — Crypto Compress — 2014-02-28T09:57:19+00:00 URL: https://externals.io/message/71192#72858 · In reply to: #72854 > Are you suggesting the following? > > function foo(Bar[] $bars) // required to pass an array of Bar objects > function foo(Bar[] $bars = null) // required to pass an array of Bar > or null members No. This is ambiguous, as you imply. I prefer c# syntax. > ...because if so, how do I specify an optional array of Bar objects? > And how do I specify an optional array of Bar or null? > > The whole concept of allowing null members seems to completely defeat > the purpose of the ArrayOf hint for me. I can understand wanting to > make the parameter optional, but I cannot see a use case for null > members from the point of view of the caller. I never null out members > of an array, I only omit them from the declaration or remove the > member from the array via e.g. unset() or stack operations (pop(), > shift() etc). YMMV of course, but for me allowing null members just > makes the callee's life more difficult and does not gain anything. Have to agree, there is not too much value in this. ;) Usecase: No need to write a mock for third and seventh array element. In fact i can't think of other usecases. It's only a simple logical extension of "function (A $a = null)". --- ## #72859 — Crypto Compress — 2014-02-28T10:01:36+00:00 URL: https://externals.io/message/71192#72859 · In reply to: #72857 > I do not really understand your point here but I want to shout out > that null is definitely a type having only one possible value. This is > one thing that PHP got right in contrast to Java, C# etc. class Foo { private Bar $bar; // What type is $bar with "undefiend" value here? } In PHP there is no type system, so it might seem as this is of type "null". It is not. --- ## #72860 — Lester Caine — 2014-02-28T11:32:43+00:00 URL: https://externals.io/message/71192#72860 · In reply to: #72854 Chris Wright wrote: > YMMV of course, but for me allowing null members just > makes the callee's life more difficult and does not gain anything. Practical example ... Object is a genealogical record. The initial tree has blank parent and grandparent objects, with each subsequent layer adding more 'null' entries. Now it may be that the preferred method of working is to create 'empty' objects for each of these, but with the number of entries doubling with each generation, 'null' is the fastest option since it does not require any processing at create time. A null entry just flags an empty branch and one only has to track those branches where there are populated objects. -- 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 --- ## #72861 — Philip Sturgeon — 2014-02-28T13:53:50+00:00 URL: https://externals.io/message/71192#72861 · In reply to: #72854 > > > > > […] > > `null` has its own type, which is mismatching the type required by the > array-of syntax when requesting, for example, `Foo[]`. > > If `null` was allowed in the array, as a user, I'd still be forced to > `array_filter()` on every call, so it would defeat the new feature > completely. > > Cheers, > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > I completely agree with you and the other folks saying: "Allowing nulls would defeat the new feature completely". Personally I would not see myself using the "Foo or null", and if I wanted to in the future I could very easily just not type hint the array. > > > > So, should we allow nulls in an arrayof-style type hint? > > > I previously suggested using the C#-style ? to specify nullability. Why > can't we do that? > > -- > Andrea Faulds > http://ajf.me/ We could potentially add in the ? syntax later on, if people seemed to want the feature enough? Just to make sure we are on the same page here, nullable arrays are fine. Arrays with nulls inside are not. Both of these are acceptable: function foo(Bar[] $baz) // accepts [new Bar, new Bar] function foo(Bar[] $baz = null) // accepts [new Bar, new Bar] or null Some people are suggesting the following alternatives. 1. Let nulls in there regardless of default var hinting: function foo(Bar[] $baz) // accepts [new Bar, null, new Bar, null] function foo(Bar[] $baz = null) // accepts [new Bar, null, new Bar, null] or null This is what many describe as a completely useless version of the feature, as array_filter would need to be run to ensure you're only working with objects of a certain type (which is 90% of the use-case for this RFC). Or, 2. Offer optional syntax for arrays containing nulls function foo(Bar[]? $baz) // accepts [new Bar, null, new Bar, null] function foo(Bar[]? $baz = null) // accepts [new Bar, null, new Bar, null] or null Pro: Keeps nulls out of the array by default, offers a way to say "Bar or null" Con: Potentially syntax soup. --- ## #72862 — Robert Stoll — 2014-02-28T14:25:49+00:00 URL: https://externals.io/message/71192#72862 · In reply to: #72861 > -----Original Message----- > From: Philip Sturgeon [mailto:pjsturgeon@gmail.com] > Sent: Friday, February 28, 2014 2:54 PM > To: PHP Developers Mailing List > Subject: Re: [PHP-DEV] Introducing "Array Of" RFC > > > > […] > > I completely agree with you and the other folks saying: "Allowing > nulls would defeat the new feature completely". Personally I would not > see myself using the "Foo or null", and if I wanted to in the future I > could very easily just not type hint the array. > > > > > […] > > We could potentially add in the ? syntax later on, if people seemed to > want the feature enough? > Just to make sure we are on the same page here, nullable arrays are > fine. Arrays with nulls inside are not. > > Both of these are acceptable: > > function foo(Bar[] $baz) // accepts [new Bar, new Bar] > function foo(Bar[] $baz = null) // accepts [new Bar, new Bar] or null > > Some people are suggesting the following alternatives. > > 1. Let nulls in there regardless of default var hinting: > > function foo(Bar[] $baz) // accepts [new Bar, null, new Bar, null] > function foo(Bar[] $baz = null) // accepts [new Bar, null, new > Bar, null] or null > > This is what many describe as a completely useless version of the > feature, as array_filter would need to be run to ensure you're only > working with objects of a certain type (which is 90% of the use-case > for this RFC). > > Or, 2. Offer optional syntax for arrays containing nulls > > function foo(Bar[]? $baz) // accepts [new Bar, null, new Bar, null] > function foo(Bar[]? $baz = null) // accepts [new Bar, null, new > Bar, null] or null > > Pro: Keeps nulls out of the array by default, offers a way to say "Bar or null" > Con: Potentially syntax soup. > > -- > > I brought up that null in an array is a valid use case at the beginning of this discussion and that the RFC should deal with such use cases - otherwise it is incomplete. I still claim it is incomplete if this topic is not addressed but I am happy if option 2 is implemented later on. --- Next page: https://externals.io/message/71192.md?page=2