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 suga
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, 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 an
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 i
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,
>
> Shouldn't
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 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 pr
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 -
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 somet
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 impossibl
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
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 alread
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 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 re
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 languages
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 wouldn'
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 t
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 compositi
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
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 Xdebu
> 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 w
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 litt
> 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 t
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
wrote
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 langua
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 m
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:
https://github.com/php/
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 http
> 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 given
>
> 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.
> 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 t
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.
>
On Wed, 22 Apr 2020 at 15:25, Nikita Popov wrote:
> 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_
33 matches
Mail list logo
