wrote in message news:3cfc0130-e530-64ed-36e8-372b04481...@rhsoft.net...
Am 04.06.2017 um 11:10 schrieb Tony Marston:
If there was never a standard to begin with then there should be proper
justification for introducing one now, and I'm afraid that "to be
consistent" is not a valid argument.
2017-06-04 11:22 GMT+02:00 Niklas Keller :
> 2017-05-29 22:29 GMT+02:00 Anatol Belski :
>
>> Hi Niklas,
>>
>> > -Original Message-
>> > From: Niklas Keller [mailto:m...@kelunik.com]
>> > Sent: Monday, May 29, 2017 10:14 PM
>> > To: Anatol Belski
>> > Cc: Nikita Popov ; PHP Internals
>> >
Am 05.06.2017 um 10:14 schrieb Tony Marston:
wrote in message news:3cfc0130-e530-64ed-36e8-372b04481...@rhsoft.net...
Am 04.06.2017 um 11:10 schrieb Tony Marston:
If there was never a standard to begin with then there should be
proper justification for introducing one now, and I'm afraid t
Den 2017-06-01 kl. 18:58, skrev Theodore Brown:
On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:
Based on the discussion there are a few different syntax choices
people liked. Overall it's a feature that people seem to want but
everyone seems to prefer a different syntax choice.
1.
On 5 June 2017 09:14:47 BST, Tony Marston wrote:
>Seriously, can you explain in words of one syllable the precise
>benefits of
>such a consistency?
I will try:
- When we write code, we need to know how to spell the names of things. If the
things all have names that look the same, it is less
Of the proposed options, I'd prefer the double fat-arrow ==>
However, I remain of the opinion that all of those syntaxes are
work-arounds to ambiguity concerns for cases that likely don't actually
occur in real-world codebases.
I don't understand the motivation to design or optimize based on some
On Tue, May 30, 2017 at 12:27 AM, Sara Golemon wrote:
> https://wiki.php.net/rfc/release-md5-deprecation
>
> Primary discussion points: Deprecate or Remove? Deprecate for how long?
>
No response from my post last week, bumping at a different time of day
to get response.
-Sara
--
PHP Internals -
2017-06-05 16:42 GMT+02:00 Sara Golemon :
> On Tue, May 30, 2017 at 12:27 AM, Sara Golemon wrote:
> > https://wiki.php.net/rfc/release-md5-deprecation
> >
> > Primary discussion points: Deprecate or Remove? Deprecate for how long?
> >
> No response from my post last week, bumping at a different t
On Mon, Jun 5, 2017 at 11:06 AM, Niklas Keller wrote:
> 2017-06-05 16:42 GMT+02:00 Sara Golemon :
>>
>> On Tue, May 30, 2017 at 12:27 AM, Sara Golemon wrote:
>> > https://wiki.php.net/rfc/release-md5-deprecation
>> >
>> > Primary discussion points: Deprecate or Remove? Deprecate for how long?
>>
On 06/05/2017 09:19 AM, Rasmus Schultz wrote:
Of the proposed options, I'd prefer the double fat-arrow ==>
However, I remain of the opinion that all of those syntaxes are
work-arounds to ambiguity concerns for cases that likely don't actually
occur in real-world codebases.
I don't understand th
On 6/5/2017 6:17 PM, Larry Garfield wrote:
> 3 > 4 > 1.
>
> 2 is not even worth considering and I'd almost prefer not having arrow
> functions if their syntax is going to be that self-defeating.
>
> I also see no reason to include both by-value and by-reference binding
> Arrow functions are for
Hi,
PCS provides a fast and easy mechanism to mix C and PHP code in PHP
extensions (more about PCS at http://pcs.tekwire.net). Thanks to the PHP
7 performance improvement and the inclusion of opcache in the core, a
lot of existing non-performance-critical extension code may now be
converted t
On 5 June 2017 18:17:06 BST, Fleshgrinder wrote:
>Could someone explain me again what the problem with the simple
>fat-arrow and normal parenthesis is? Cannot find it anymore (too many
>messages in too many thread I guess). I would guess that it has to do
>with the arbitrary look-ahead that is req
On 6/5/2017 7:55 PM, Rowan Collins wrote:
> I think it's not just a case of implementation problems, it's actually
> ambiguous with current syntax:
>
> $foo = array( ($x) => 42 );
>
> Sure, those inner brackets are redundant, so it's not likely to break much
> actual code, but it's kind of weir
Den 2017-06-05 kl. 19:55, skrev Rowan Collins:
On 5 June 2017 18:17:06 BST, Fleshgrinder wrote:
Could someone explain me again what the problem with the simple
fat-arrow and normal parenthesis is? Cannot find it anymore (too many
messages in too many thread I guess). I would guess that it has
On 05/30/2017 02:48 PM, Fleshgrinder wrote:
Nice to see that I'm not the only who thinks that proper documentation
is a good thing. I already mentioned that it is not super important to
me personally to actually generate the docs from the code base. However,
there is also nothing bad about doing
Am 05.06.2017 um 20:16 schrieb Jefferson Gonzalez:
I do not remember all the details, since this was 5 years ago as I wrote
before, but what I do remember is some of the core developers not
wanting to saturate the core code with comments, and that the best
documentation was reading the actual
Ugh, you're right, that's totally unreadable... the => is far too ambiguous
with array syntax, I agree.
How about just a thin arrow?
(params) -> expr
If the parens around params were required, it's not ambiguous with the
trailing -- operator, is it?
$foo->bar(($baz) -> $baz + 1);
Consi
On 06/01/2017 03:04 PM, Fleshgrinder wrote:
Hey guys!
Just finished the very brief Doxygen RFC. Please let me know if you
require more information in it, I feel that it is sufficient as is,
since documenting is not rocket science (writing useful documentation
definitely is, but we cannot vote on
On 6/5/2017 8:36 PM, Rasmus Schultz wrote:
> Ugh, you're right, that's totally unreadable... the => is far too ambiguous
> with array syntax, I agree.
>
> How about just a thin arrow?
>
> (params) -> expr
>
> If the parens around params were required, it's not ambiguous with the
> trailing -
> That's not a terrible idea. I'll script something up to download,
> verify gpg if it's available (verify existing m5 if it's not), and
> generate a sha256 from it resulting in a diff to
> web-php/include/releases.inc . Can do that irrespective of whether or
> not we stop adding md5s.
We also go
Hey Jefferson!
On 6/5/2017 8:40 PM, Jefferson Gonzalez wrote:
> First, thanks for taking the initiative to do this!
>
:)
On 6/5/2017 8:40 PM, Jefferson Gonzalez wrote:
> Second, the rfc doesn't touch the ability of grouping that doxygen
> provides which could be really useful in order to naviga
On Jun 5, 2017 12:53 PM, "Fleshgrinder" wrote:
On 6/5/2017 8:36 PM, Rasmus Schultz wrote:
> Ugh, you're right, that's totally unreadable... the => is far too
ambiguous
> with array syntax, I agree.
>
> How about just a thin arrow?
>
> (params) -> expr
>
> If the parens around params were requ
Hi François
2017-06-05 19:46 GMT+02:00 François Laupretre :
> Hi,
>
> PCS provides a fast and easy mechanism to mix C and PHP code in PHP
> extensions (more about PCS at http://pcs.tekwire.net). Thanks to the PHP 7
> performance improvement and the inclusion of opcache in the core, a lot of
> exis
On 6/5/2017 9:03 PM, Ryan Pallas wrote:
> However, ($obj) -> $var is valid variable property syntax.
>
Gosh, we really have support for everything. :D That one is even very
important for stuff like `(new A)->f()`.
How about ~> which I at least cannot think of any place it is used at
all. ~ in bi
On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote:
> On 6/5/2017 9:03 PM, Ryan Pallas wrote:
> > However, ($obj) -> $var is valid variable property syntax.
> >
>
> Gosh, we really have support for everything. :D That one is even very
> important for stuff like `(new A)->f()`.
>
> How about ~> wh
On 6/5/2017 7:46 PM, François Laupretre wrote:
> So, please give me your thoughts. Suggestions of potential candidates to
> be rewritten from C to PHP are welcome too.
>
> Regards
>
> François
>
Hi François!
I really, really like this. It would allow us to write most of the stuff
in PHP, espec
On Mon, Jun 5, 2017 at 2:56 PM, Kalle Sommer Nielsen wrote:
>> That's not a terrible idea. I'll script something up to download,
>> verify gpg if it's available (verify existing m5 if it's not), and
>> generate a sha256 from it resulting in a diff to
>> web-php/include/releases.inc . Can do that
On 05/06/2017 20:09, Fleshgrinder wrote:
How about ~> which I at least cannot think of any place it is used at
all. ~ in binary negation and the only place we use it (I checked the
language parser this time to make sure).
We've come full circle: that was actually the syntax proposed in Bob
Wei
Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:
On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote:
On 6/5/2017 9:03 PM, Ryan Pallas wrote:
However, ($obj) -> $var is valid variable property syntax.
Gosh, we really have support for everything. :D That one is even very
important for stuff like
Results for project PHP master, build date 2017-06-04 19:23:38-07:00
commit: 8baf12b
previous commit:a86c87d
revision date: 2017-06-04 18:22:02+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
>
> On 6 Jun 2017, at 03:18, Björn Larsson wrote:
>
> Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:
>
>> On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote:
>>
>>> On 6/5/2017 9:03 PM, Ryan Pallas wrote:
However, ($obj) -> $var is valid variable property syntax.
>>> Gosh, we really
Le 30/05/2017 à 06:27, Sara Golemon a écrit :
> https://wiki.php.net/rfc/release-md5-deprecation
>
> Primary discussion points: Deprecate or Remove? Deprecate for how long?
>
+1 for dropping md5 checksums for 7.2 releases
And I don't think adding sha256 for old releases (which are unsecure)
wor
Le 05/06/2017 à 19:46, François Laupretre a écrit :
> Hi,
>
> PCS provides a fast and easy mechanism to mix C and PHP code in PHP
> extensions (more about PCS at http://pcs.tekwire.net). Thanks to the PHP
> 7 performance improvement and the inclusion of opcache in the core, a
> lot of existing non
34 matches
Mail list logo
