On Fri, Mar 15, 2019, at 10:56 PM, Kenneth Ellis McCall wrote:
> Kenneth Ellis McCall wrote:
> > Hey all,
> >
> > I'm looking to get feedback on a RFC I want to propose.
> >
> > PHP RFC: Addition of the 'struct' data type.
> >
>
> Hey all,
>
> Hopefully this addresses the questions you had in
Hello,
On Sat, 16 Mar 2019 at 03:57, Morgan Breden wrote:
>
> >If you want to go further, dropping the PHP tag altogether would be nice,
> since it would prevent context switching between PHP/HTML/JS/whatever.
> >That would force Wordpress to update their whole
> code base. >:{)>
>
> I wholehearte
On Sat, 16 Mar 2019 at 03:44, Kenneth Ellis McCall
wrote:
> G. P. B. wrote:
> > currently going through the PHP doc to remove mentions of PHP 4
> > and stumbled upon the short_open_tag ini directive [1] which only affects
> > the availability of ` > From my understanding, the ` directive,
> > so
>If you want to go further, dropping the PHP tag altogether would be nice,
since it would prevent context switching between PHP/HTML/JS/whatever.
>That would force Wordpress to update their whole
code base. >:{)>
I wholeheartedly support this initiative but I do not see it going through
without a
Kenneth Ellis McCall wrote:
Hey all,
I'm looking to get feedback on a RFC I want to propose.
PHP RFC: Addition of the 'struct' data type.
Hey all,
Hopefully this addresses the questions you had in someway, even if it's
not a direct answer and might propose other things. Also sorry for the
G. P. B. wrote:
currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only affects
the availability of `
I would like to see that. "Question mark equals what?".
If you want to go further, dropping the PHP tag altogether woul
Hi,
New Windows builds are available here
https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190315/ . Anyone
interested, especially usage with Apache, are encouraged to test hard :)
Thanks
Anatol
> -Original Message-
> From: Dmitry Stogov
> Sent: Friday, March 15, 2
On Fri, March 15, 2019 at 4:45 AM Josh Di Fabio wrote:
> I'd certainly be on board with the fn() syntax, but the backslash
> syntax has definitely grown on me. To me, all of the examples in
> Theodore's email are very readable and I find that the backslash makes
> it very easy to identify arrow f
Den fre. 15. mar. 2019 kl. 19.53 skrev Levi Morrison :
> Four thoughts:
>
> 1. I cannot think of *any* reason to separate them. If you want to
> make sure you are indexing a string, *do a type check*, not bake `{}`
> into only working on strings.
> 2. While Kalle says pretty much every codebase
On Fri, 15 Mar 2019 at 17:53, Levi Morrison wrote:
> 1. I cannot think of *any* reason to separate them. If you want to
> make sure you are indexing a string, *do a type check*, not bake `{}`
> into only working on strings.
>
I think it's more common to do the opposite: think you're working o
On Fri, Mar 15, 2019 at 10:31 AM Kalle Sommer Nielsen wrote:
>
> Den fre. 15. mar. 2019 kl. 17.06 skrev Nikita Popov :
> > I'm okay with this. This syntax has already been deprecated once, though it
> > was reverted for reasons I don't remember.
> >
> > There are some people using this syntax to d
On Fri, Mar 15, 2019 at 11:11 AM Nikita Popov wrote:
>
> On Fri, Mar 15, 2019 at 4:26 PM Nikita Popov wrote:
>>
>> On Fri, Mar 15, 2019 at 4:16 PM Levi Morrison wrote:
>>>
>>> Personally, I think pass by-value with copy-on-write semantics like
>>> arrays is the sweet spot. Mutability is fine if
On Fri, Mar 15, 2019 at 4:26 PM Nikita Popov wrote:
> On Fri, Mar 15, 2019 at 4:16 PM Levi Morrison wrote:
>
>> Personally, I think pass by-value with copy-on-write semantics like
>> arrays is the sweet spot. Mutability is fine if it is localized.
>>
>
> If we introduce something like this, I th
Den fre. 15. mar. 2019 kl. 17.06 skrev Nikita Popov :
> I'm okay with this. This syntax has already been deprecated once, though it
> was reverted for reasons I don't remember.
>
> There are some people using this syntax to distinguish between array and
> string access. It's a nice thought, but as
On Fri, 15 Mar 2019 at 17:03, Rowan Collins wrote:
> On Fri, 15 Mar 2019 at 15:56, G. P. B. wrote:
>
> > However, I'm not sure of the behavior if someone sets this behavior
> within
> > a file/class
> > does this only affect this specific instance or is it globally?
> >
>
> Not all settings can
On Fri, 15 Mar 2019 at 15:56, G. P. B. wrote:
> However, I'm not sure of the behavior if someone sets this behavior within
> a file/class
> does this only affect this specific instance or is it globally?
>
Not all settings can be altered with ini_set; this one is listed at
http://php.net/manual/
Just gonna do general reply instead of pointing at specific points.
But as it has been pointed out using short tags makes the code less
portable,
which IMO isn't ideal.
I personally don't tinker with INI settings withing PHP with `ini_set` as
IMHO if you
need to change them it should be done in t
On Fri, 15 Mar 2019 at 15:26, Nikita Popov wrote:
> If we introduce something like this, I think it is very important that it
> does not use the same property access syntax as ordinary objects, which are
> not copy-on-write. I do not want to be second guessing whether $x->y = $z
> is going to cop
On Fri, Mar 15, 2019 at 4:16 PM Levi Morrison wrote:
> Personally, I think pass by-value with copy-on-write semantics like
> arrays is the sweet spot. Mutability is fine if it is localized.
>
If we introduce something like this, I think it is very important that it
does not use the same property
On Fri, 15 Mar 2019 at 15:16, Levi Morrison wrote:
> We could also add an object literal
> syntax for creating ad-hoc stdClass objects like so: `$obj = { x: 1,
> y: 1}`. This has an ambiguity, but I believe I have solved the issue
> without too much trouble once before.
>
Minor side-note, but I
Personally, I think pass by-value with copy-on-write semantics like
arrays is the sweet spot. Mutability is fine if it is localized.
I think having a no-constructor construction syntax is also a good
idea. I've discussed it with a few people, but don't can't remember if
it's ever been brought up o
On Fri, Mar 15, 2019 at 10:53 AM Dmitry Stogov wrote:
> Hi Internals,
>
> https://wiki.php.net/rfc/jit
>
> Now JIT also supports ZTS (checked on Linux and Windows).
> Please, test and report problems.
>
> So, complains about JIT compatibility matrix are satisfied.
> It should be some incompatibil
On Fri, Mar 15, 2019 at 2:39 PM Andrey O Gromov wrote:
> Reasons to deprecate curly braces syntax::
> 1. Two ways to do the same thing.
> 2. It is very rarely used nowadays.
> 3. It is almost not documented. There is only two short “NOTE” about
> it.
> 4. Also, this syntax has
On 15/03/2019 14:39, Andrey O Gromov wrote:
> Reasons to deprecate curly braces syntax::
> 1. Two ways to do the same thing.
> 2. It is very rarely used nowadays.
> 3. It is almost not documented. There is only two short “NOTE” about
> it.
> 4. Also, this syntax has reduced fun
Reasons to deprecate curly braces syntax::
1. Two ways to do the same thing.
2. It is very rarely used nowadays.
3. It is almost not documented. There is only two short “NOTE” about
it.
4. Also, this syntax has reduced functionality. You can't use it for
pushing element into a
On Fri, 15 Mar 2019 at 09:54, Nikita Popov wrote:
> 2. Readonly properties: Without requiring an entire object to be immutable,
> we can add support for readonly properties. This may be either a standalone
> feature, or part of / based on a more general property accessors proposal.
>
This is re
On Fri, Mar 15, 2019 at 10:54 AM Nikita Popov wrote:
> On Fri, Mar 15, 2019 at 4:49 AM Kenneth Ellis McCall
> wrote:
>
> > Hey all,
> >
> > I'm looking to get feedback on a RFC I want to propose.
> >
> > PHP RFC: Addition of the 'struct' data type.
> >
> > Introduction:
> > PHP has many data typ
On 15/03/2019 04:49, Kenneth Ellis McCall wrote:
> Hey all,
>
> I'm looking to get feedback on a RFC I want to propose.
>
> PHP RFC: Addition of the 'struct' data type.
>
> Introduction:
> PHP has many data types, but does not offer something that is the
> equivalent to the C struct data type.
>
On Fri, 15 Mar 2019 at 10:10, Nikita Popov wrote:
> It might be worth giving some consideration to the possibility of
> introducing this syntax already in this RFC. The main problem with punting
> this off for later is that it may be necessary to refactor closures between
> the short and the long
On 15/03/2019 09:54, Nikita Popov wrote:
could then become something like
// declaration
class AnotherStruct {
readonly string $firstName;
readonly string $lastName;
readonly ?int $age = null;
}
// initialization (syntax up to bikeshedding)
new AnotherStruct {
$firstName => '
On Fri, Mar 15, 2019 at 10:31 AM Rowan Collins
wrote:
> On Fri, 15 Mar 2019 at 09:01, Alexandru Pătrănescu
> wrote:
>
> > My question would be: whatever syntax we are going to use that has arrow
> > syntax, let's say *$f = \($x) => $x * 2;* are we going to also support
> the
> > arrow block vers
On Thu, Mar 14, 2019 at 3:04 PM Mathieu Rochette
wrote:
>
> Hi,
>
> it's nice to see this going on again :)
>
> while reading the rfc I was wondering, why do we need the "static"
> keyword, couldn't static function be detected automatically ?
>
I've added a note regarding this in
https://wiki.ph
On Fri, Mar 15, 2019 at 4:49 AM Kenneth Ellis McCall
wrote:
> Hey all,
>
> I'm looking to get feedback on a RFC I want to propose.
>
> PHP RFC: Addition of the 'struct' data type.
>
> Introduction:
> PHP has many data types, but does not offer something that is the
> equivalent to the C struct da
Hi Internals,
https://wiki.php.net/rfc/jit
Now JIT also supports ZTS (checked on Linux and Windows).
Please, test and report problems.
So, complains about JIT compatibility matrix are satisfied.
It should be some incompatibilities with ZTS on Mac, but this easily
fixable.
I'll spend some addit
On Fri, 15 Mar 2019 at 03:48, Kenneth Ellis McCall
wrote:
> PHP has many data types, but does not offer something that is the
> equivalent to the C struct data type.
>
> The purpose of this RFC is to propose a data type of 'struct', which
> would be a strictly typed, immutable data structure that
On Thu, Mar 14, 2019 at 7:42 PM Theodore Brown wrote:
>
> On Thu, March 14, 2019 10:41 AM Nikita Popov wrote:
>
> > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> >
> > > Hi internals,
> > >
> > > Motivated by the recent list comprehensions RFC, I think it's time we took
> > > another loo
On Fri, 15 Mar 2019 at 09:01, Alexandru Pătrănescu
wrote:
> My question would be: whatever syntax we are going to use that has arrow
> syntax, let's say *$f = \($x) => $x * 2;* are we going to also support the
> arrow block version?:
> *$f = \($x) => {*
> *// more operations that will have be
Hi,
To start with, I personally understand why a prefix character is needed
before parenthesis to make the parser simpler. I would like another simpler
option but will have to investigate more on this.
My question would be: whatever syntax we are going to use that has arrow
syntax, let's say *$f
38 matches
Mail list logo