Yes!
Though I don't necessarily think they need to be genericised (e.g.
list) in the language itself – just having those alternate
datatypes would, I think, be a boon to the language itself – with list (a
subtype of array) more useful to me than dict.
On Sat, 18 Apr 2020 at 10:51, Sebastian Berg
Am 21.01.2020 um 22:21 schrieb Matthew Brown:
What if we left the array type alone, and instead focussed on "list"
type and "dict", "dict" types?
That would allow a clear break from previous behaviour, and would allow you
to introduce other changes (e.g. removing string -> int coercion for
numer
Given this orientation, can we also have this debated once more?
https://wiki.php.net/rfc/callable-types
Right now, I am using 7.4.2 in production and in my next book and I cannot
explain how it feels good to have those types but along with the loosely
typed freedom. That's the killer advantage o
On 25/01/2020 00:12, Mike Schinkel wrote:
So saying "use a static analyzer" is IMO just pointing out an overall
weakness that PHP can't automatically do static analysis on its own.
I'd just like to repeat that you and Rasmus are in agreement here. He
didn't say "PHP doesn't need to change bec
> On Jan 24, 2020, at 3:47 PM, Rowan Tommins wrote:
>
> I imagine the reason static analysers are generally run as a separate step
> rather than just before execution is because then you _really_ don't care
> about performance, and it's more convenient to get the results on demand,
> rather th
> On Jan 24, 2020, at 14:27, Mike Schinkel wrote:
>
> Thus far we have discussed that implementation of type checking for arrays
> would be too costly from a performance perspective and that there is no good
> solution that is not extremely complicated to implement.
>
> Given that, can we co
On 24/01/2020 19:27, Mike Schinkel wrote:
ALLOW the use of a syntax for typed arrays — whether it be type[] or [type] — but only
validate that it is an array and that the "type" is in fact a type, but don't
actually validate that each element is the correct type.
I don't really see much poin
On 24/01/2020 19:22, Mike Schinkel wrote:
Really expensive checks like this belong at the static analysis stage. And yes,
it would be amazing to have a static analyzer built into PHP, which is
basically what you are asking for here,
Expensive checks would not be a problem if they could be run
Thus far we have discussed that implementation of type checking for arrays
would be too costly from a performance perspective and that there is no good
solution that is not extremely complicated to implement.
Given that, can we consider an alternative?
ALLOW the use of a syntax for typed arra
> On Jan 23, 2020, at 3:04 AM, Rasmus Lerdorf wrote:
> You are getting into static analysis territory here with that. There are
> already static analysis tools that do exactly this type of array type
> checking during development. For example, there are three type mistakes in
> this code:
>
On Sun, Jan 19, 2020 at 4:53 PM Mike Schinkel wrote:
> Also, Rowan Collins mentioned that checks in Go can be disabled for
> runtime checking; maybe we could support an option that disables said
> checking so that production sites could run w/o checks but we could run
> checks in development, tes
>
> On Jan 21, 2020 at 5:37 PM, mailto:rowan.coll...@gmail.com)>
> wrote:
>
>
>
> On 20/01/2020 00:53, Mike Schinkel wrote:
> > One approach mentioned by Andrea Faulds was to extend the hashtable (ref:
> > your article[1]) and count types as assigned just like we cu
On 20/01/2020 00:53, Mike Schinkel wrote:
One approach mentioned by Andrea Faulds was to extend the hashtable (ref: your
article[1]) and count types as assigned just like we currently count references. So a
10,240 element array of ints could have an internal tracker showing that the array
con
>
> What if we left the array type alone, and instead focussed on "list"
> type and "dict", "dict" types?
> That would allow a clear break from previous behaviour, and would allow you
> to introduce other changes (e.g. removing string -> int coercion for
> numeric string keys).
Can't agree mo
> As far as I know, the only viable way to do that is to make the array
> intrinsically typed, which means that types are validated when elements are
> inserted into the array, not when it is passed across a function boundary.
> In other words, array generics.
>
What if we left the array type alon
> On Jan 19, 2020, at 8:42 PM, John Bafford wrote:
> As a thought, perhaps the syntax '[Type]' for an array of Type. That way, you
> could write ?[int], or [?int], or even ?[?int] and there would be no
> ambiguity, and no need for parentheses since the array brackets would serve
> that purpose.
> On Jan 19, 2020, at 19:53, Mike Schinkel wrote:
>
> P.S. There was also the mention by Levi Morrison that the type[] syntax was
> a poor one because of ambiguity between (?int)[] or ?(int[]). I would argue
> that the latter would likely occur orders of magnitude more often than the
> fo
Hi Nikita,
> On Jan 18, 2020, at 5:05 AM, Nikita Popov wrote:
> Did you read through the previous discussions on this topic?
> https://externals.io/message/100946 in particular comes to mind.
Thanks for this link. It was very insightful.
> The primary concern about the previous typed array prop
On Fri, Jan 17, 2020 at 8:51 AM Aran Reeks wrote:
> Hi Internals,
>
> I'd like to kick off a conversation to capture everyone else's thoughts on
> tweaking / improving typed properties for arrays (for a PHP 8.x release).
>
> With all the work done lately to greatly improve the type support in PHP
> I have a PR that reduces the [minimum capacity of a packed array from 8] to
> 2, noticeably decreasing memory -
> the largest blockers were getting a realistic idea of whether commonly used
> applications
> would see a decrease or increase in runtime, and needing code review.
Sorry, I forgot
> I'm unsure of exactly how this might work so defer to an Internals export,
> but having previously read @Nikita Popov 's great
> post on PHP's arrays, I did wonder if by knowing the data type within an
> array and that it'd conform to a strict structure, could the array itself
> be stored in an a
Hi Mike,
Thanks for your support, and yes, you're correct, I did mean to structure
the type prior to the [].
I'm unsure of exactly how this might work so defer to an Internals export,
but having previously read @Nikita Popov 's great
post on PHP's arrays, I did wonder if by knowing the data type
> On Jan 17, 2020, at 2:50 AM, Aran Reeks wrote:
> That said, there's a common use case that keeps me going back to them which
> I think would be a good thing for PHP to try and solve as a language
> feature - better typing of arrays to type their properties.
I for one would be a big +1 for thi
On Fri, Jan 17, 2020, at 7:53 AM, Robert Hickman wrote:
> > So essentially we are talking about generics. I think it's the best time to
> > do so... Maybe our wishes come true soon? ;)
> >
>
> Given that the general trend is towards making PHP more statically
> typed and very java/C# like, why not
On Fri, Jan 17, 2020, 2:54 PM Robert Hickman wrote:
> > So essentially we are talking about generics. I think it's the best time
> to
> > do so... Maybe our wishes come true soon? ;)
> >
>
> Given that the general trend is towards making PHP more statically
> typed and very java/C# like, why not
> So essentially we are talking about generics. I think it's the best time to
> do so... Maybe our wishes come true soon? ;)
>
Given that the general trend is towards making PHP more statically
typed and very java/C# like, why not just ditch PHP and use one of the
aforementioned languages?
--
PH
Hi,
So essentially we are talking about generics. I think it's the best time to
do so... Maybe our wishes come true soon? ;)
Cheers,
Máté
Hello all
It's a much-requested feature for years and years. My first thought was "we
need generics, not this" but than I took 5 minutes to actually think about it.
While the same, and much more, can be achieved with generics, it's a difficult
feature to implement. There have been several RFCs
Am 17.01.2020 um 08:50 schrieb Aran Reeks:
@returns []int
int[] etc. is common-place, but I have never seen []int.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Internals,
I'd like to kick off a conversation to capture everyone else's thoughts on
tweaking / improving typed properties for arrays (for a PHP 8.x release).
With all the work done lately to greatly improve the type support in PHP
(which is amazing by the way), I'm finding for the most part,
30 matches
Mail list logo