On Wed, Apr 22, 2020 at 11:03 PM Matthew Brown wrote:
>
> > This is the *design* process for a language, and it's important...
> Stepping back to reconsider how collections work generally, and how we can
> improve them in a graceful way that leads to a clean end-state, would be
> very valuable.
>
> This is the *design* process for a language, and it's important...
Stepping back to reconsider how collections work generally, and how we can
improve them in a graceful way that leads to a clean end-state, would be
very valuable.
Though you have much more experience with internals than I do, I
>
> Anyway, I hope this was interesting and can help inform discussion and
> perhaps provide inspiration!
>
This was very useful, and it makes me feel more strongly that list should
be an entirely separate type so that checking for packed keys is rarely
necessary.
> For simplicity's sake I haven't
> implemented a type declaration right now, just an is_list() function,
> but it could easily be extended to one
This is a crucial question – should is_list function like
is_numeric($some_string), where is_list just tells you about the keys in
the array at a
Hi Andrea,
> Since it's pretty simple, I decided to write a proof-of-concept
> implementation of such a check. For simplicity's sake I haven't
> implemented a type declaration right now, just an is_list() function,
> but it could easily be extended to one. The implementation can be found
> at
On Apr 21, 2020, at 12:49, Andrea Faulds wrote:
> I recall someone previously suggesting (not formally proposing IIRC) we could
> have a standard library is_ function to check these, but it didn't go
> anywhere.
That would be me, and I had a draft implementation for it:
Hello again everyone,
Andrea Faulds wrote:
Hello again,
Andrea Faulds wrote:
Hi,
Matthew Brown wrote:
I imagine such a "list" type would be a subtype of "array" – everywhere
that array was accepted, a list would be also, and it would have the
same
copy-on-write behaviour.
IIRC with the
On Wed, Apr 22, 2020, at 3:44 PM, Matthew Brown wrote:
> > map/filter/reduce need to be recast to work on any iterable, which would
> then include lists
> > Lists would only make sense if we're also rethinking how collections work
> generally
>
> I disagree – I think the most successful PHP
Haskell has & operator in Data.Function module which is exact equivalent of
the proposed feature.
Link:
https://hackage.haskell.org/package/base-4.8.0.0/docs/Data-Function.html#g:2
Example: https://repl.it/repls/KindLightsalmonApplicationserver
On Wed, Apr 22, 2020 at 9:09 PM Larry Garfield
> map/filter/reduce need to be recast to work on any iterable, which would
then include lists
> Lists would only make sense if we're also rethinking how collections work
generally
I disagree – I think the most successful PHP language additions have been
those that allow PHP developers to improve
On Wed, Apr 22, 2020, at 1:49 PM, Matthew Brown wrote:
> > Is it an effective subtype of array?
>
> I was thinking it should be (with the auto-conversion mentioned above), but
> I can see a compelling case to not have the auto-conversion when
> manipulating – while it would bloat the stdlib a
> Is it an effective subtype of array?
I was thinking it should be (with the auto-conversion mentioned above), but
I can see a compelling case to not have the auto-conversion when
manipulating – while it would bloat the stdlib a little (we'd need a whole
bunch of list_* functions) the separation
Hi,
as I mentioned, the first STV round ran into a tie, so there is a
current run-off between the two candidates that tied,
Gabriel and Ben, at: https://wiki.php.net/todo/php80#round_two
cheers,
Derick
--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like
Hello,
thank you for expanding on your comparison of callables to resources. I didn't
completely understand what you meant but now I do.
Speaking of "dynamic" callables - this is also one of the reasons as to why I
believe we shouldn't wait for typedefs and should allow properties to be typed
as
On Wed, Apr 22, 2020, at 3:25 AM, Guilliam Xavier wrote:
> On Tue, Apr 21, 2020 at 4:44 PM Larry Garfield wrote:
> >
> > On Mon, Apr 20, 2020, at 11:20 PM, Stanislav Malyshev wrote:
> > > Just a small pedantry note - in a comparison section, the RFC compares
> > > this syntax to function
Hello,
thank you for the comment! Yes, indeed I was raising a discussion on whether we
should allow making typed callable properties for improved language's
consistency (given that parameter/return type hints can be set to callable). As
one of the solutions, I mentioned that we could just ignore
Hi Benas,
my responses below.
śr., 22 kwi 2020 o 19:17 moliata napisał(a):
> Hello,
>
> thank you for an opinion as well! While I do fully agree that callable type
> needs to be improved with features such as typedefs, I found a couple of
> problems in your response.
>
> First of all, I
Hi internals,
Currently, it's possible to disable the json extension with `./configure
--disable-json`.
However, JSON is widely used in many use cases - web sites, logging output, and
as a data format that can be used in CLI programs
to share data with many applications and programming
Hello,
thank you for an opinion as well! While I do fully agree that callable type
needs to be improved with features such as typedefs, I found a couple of
problems in your response.
First of all, I wouldn't say that the callable type provides little-to-no
information like the resource type. A
On Tue, Apr 21, 2020, at 2:00 PM, Matthew Brown wrote:
> Before I create an RFC or attempt a reference implementation, is there any
> interest in adding (and then obviously supporting in perpetuity) a list
> type?
>
> The first line of PHP's documentation for "array" states: "An array in PHP
> is
Hello,
thank you for your opinion. In response to you mentioning that fixing this
problem would be a huge amount of work, I would like to reiterate the idea of
simply ignoring context-dependent problems for the time being. In fact, we can
observe this behavior in parameter/return type hints
On 22/04/2020 16:01, Michał Brzuchalski wrote:
I agree, a callable brings as much information as a resource type - you
know the type
but are unable to use it without additional information.
While this is true, it's somewhat orthogonal to the question Benas
raised in this thread - namely, how
Thanks for your comments!
> How would array_shift(), array_merge(array, list) ... be handled? Would
they return lists or arrays?
I think they would return lists where appropriate – Psalm & Phan already
infer some of that behaviour, adding runtime support would be an
undertaking, but not
Hi Dan,
On 22/04/2020 15:29, Dan Ackroyd wrote:
As email
is not a good format for carrying out discussions, if people want to
take part in that discussion, doing it in that repo would be better
imo.
I would be grateful if you could engage in the thread I started last
time you suggested
Hi all,
śr., 22 kwi 2020 o 16:29 Dan Ackroyd napisał(a):
> On Tue, 21 Apr 2020 at 14:08, moliata wrote:
> >
>
> > I wanted to ignite a friendly discussion whether
> > PHP should allow typed callable properties.
>
> IMO no.
>
>
I agree, a callable brings as much information as a resource type -
On Tue, 21 Apr 2020 at 14:08, moliata wrote:
>
> I wanted to ignite a friendly discussion whether
> PHP should allow typed callable properties.
IMO no.
Trying to fix the problems with callables would be a huge amount of
work, and not actually give that much benefit. Even just documenting
the
Hi Guilliam,
Thank you for the reminder, we certainly forgot to resolve that issue.
After a quick investigation, it turned out that the %e and %E specifiers
are already
locale-insensitive, so we can leave them as-is.
Furthermore, the definition of the %G specifier according to the
documentation
On Wed, Apr 22, 2020 at 10:53 AM Guilliam Xavier
wrote:
> On Tue, Apr 21, 2020 at 10:01 PM Máté Kocsis
> wrote:
> >
> > That said, we'd like to open the vote on Thursday, unless serious
> concerns
> > arise
> > in the meanwhile.
> >
> > Cheers,
> > Máté
>
> Hi, thanks for the work,
>
>
Hi internals,
I'd like to make two improvements to the printf() functionality exposed by
PHP (also affecting other variations like sprintf, vprintf, etc.) These
improvements are motivated by
https://wiki.php.net/rfc/locale_independent_float_to_string, which will
make float to string casts locale
On Tue, 21 Apr 2020 at 12:35, Benjamin Eberlei wrote:
> The discussion on this RFC was 5 weeks and the syntax suggestions until
> yesterday have all been suboptimal.
>
I appreciate the discussion period was 5 weeks, which was a generous
allowance. It's also been an unusual 5+ weeks, with life
On Tue, Apr 21, 2020 at 10:01 PM Máté Kocsis wrote:
>
> That said, we'd like to open the vote on Thursday, unless serious concerns
> arise
> in the meanwhile.
>
> Cheers,
> Máté
Hi, thanks for the work,
Shouldn't the RFC mention the open question of printf formats %e/%E
and %g/%G (and possible
On Tue, Apr 21, 2020 at 4:44 PM Larry Garfield wrote:
>
> On Mon, Apr 20, 2020, at 11:20 PM, Stanislav Malyshev wrote:
> > Just a small pedantry note - in a comparison section, the RFC compares
> > this syntax to function composition. But this is not function
> > composition. This is a syntax
32 matches
Mail list logo
