06.07.2017 07:24 "tyson andre" napisał(a):
>
> Updated https://github.com/TysonAndre/php-src/pull/1 , which is now much
shorter.
>
> In response to Nikita Popov's comments:
>
> > I'm +1 on the addition and would be fine with including it without RFC,
if
> > there are no objections on internals.
>
What's the point?
Sorry for the snarky response, but it had to be done 😂
On 6 Jul 2017 8:13 AM, "Khawer ." wrote:
In all major programming languages we access object properties and methods
using dot(.).
C#:
Abc Abc = new Abc();
Abc.method();
Java:
Abc Abc = new Abc();
Abc.method();
JavaScrip
The dot is already the string concatenation operator. This would be a horrible
migration process. The PHP team is never going to upset the developer
experience that much for a purely cosmetic change.
Also, C and C++ use the -> symbol, two major languages.
Regards
On 6 Jul 2017, 08:13 +0200, Kh
In all major programming languages we access object properties and methods
using dot(.).
C#:
Abc Abc = new Abc();
Abc.method();
Java:
Abc Abc = new Abc();
Abc.method();
JavaScript:
var apple = new function() {
this.name = "Test";
}
alert(apple.name());
Why not to make PHP similar to these
Updated https://github.com/TysonAndre/php-src/pull/1 , which is now much
shorter.
In response to Nikita Popov's comments:
> I'm +1 on the addition and would be fine with including it without RFC, if
> there are no objections on internals.
How long should I wait to see if there are objections be
Hi!
> I think that using :: on a variable that contains an object should not
> "fall back" to a static access on the object's class. Instead the
> runtime should error out.
Why should it not do what it does now? What would it achieve? I don't
see any improvement in changing that - it may break co
Hi Andrea, Sebastian
2017-07-06 1:12 GMT+02:00 Andrea Faulds :
> Hi Sebastian,
>
> Sebastian Bergmann wrote:
>>
>> Is it intentional that the DOUBLE_COLON operator can be used on a
>> variable that contains a reference to an object?
>
>
> I assume so. It wouldn't be the only place that accepts eit
Hi Zeev,
Zeev Suraski wrote:
On 5 Jul 2017, at 19:09, Lauri Kenttä wrote:
I'm just wondering if T_PAAMAYIM_NEKUDOTAYIM could finally be changed to
T_DOUBLE_COLON in, say, PHP 8?
I for one would love not repeating that discussion once over... I realize some
people aren't fond of this toke
Hi Sebastian,
Sebastian Bergmann wrote:
Is it intentional that the DOUBLE_COLON operator can be used on a
variable that contains a reference to an object?
I assume so. It wouldn't be the only place that accepts either a class
name or an object of that class.
I think that using :: on a vari
Results for project PHP master, build date 2017-07-04 19:23:13-07:00
commit: 8e0ddc8
previous commit:726f2f7
revision date: 2017-07-04 21:23:34+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hi!
> On 32-bit zend_long is a signed 32-bit int, so it can theoretically overflow,
> while sizeof is same.
Well, it's the same issue we having on representing any unsigned values,
I guess. Since int<->uint in this case is one-to-one, should be ok to
just use the negative nums, if they are used
Hi!
> No: In PHP 7 this is not possible, which is also why spl_object_hash() no
> longer includes the handlers.
Ah, I missed that part.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2017-07-05 18:47 GMT+02:00 Zeev Suraski :
> I for one would love not repeating that discussion once over... I realize
> some people aren't fond of this token, but it's at the level of harmlessness
> - and at least to some a part of the PHP folklore - that we should find
> better things to do th
2017-07-05 19:20 GMT+02:00 Fleshgrinder :
> Haven't thought about it this way, that actually makes sense.
>
> What I want to avoid is that anybody thinks that the second poll has any
> meaning if the first one is a "no". In that case the second one is
> "nothing". That is basically the point. A vot
On 05.07.2017 at 18:47, Zeev Suraski wrote:
>> On 5 Jul 2017, at 19:09, Lauri Kenttä wrote:
>> I'm just wondering if T_PAAMAYIM_NEKUDOTAYIM could finally be
changed to T_DOUBLE_COLON in, say, PHP 8?> > I for one would love not
repeating that discussion once over... I realize some people are
On 05.07.2017 at 18:47, Zeev Suraski wrote:
>> On 5 Jul 2017, at 19:09, Lauri Kenttä wrote:
>> I'm just wondering if T_PAAMAYIM_NEKUDOTAYIM could finally be
changed to T_DOUBLE_COLON in, say, PHP 8?> > I for one would love not
repeating that discussion once over... I realize some people are
On 7/4/2017 11:24 PM, Christoph M. Becker wrote:
> Hmm, one might dislike having the coding standards amended in this
> regard, but still may have a preference on how it would be changed, if
> the change will be accepted.
>
Haven't thought about it this way, that actually makes sense.
What I wan
> On 5 Jul 2017, at 19:09, Lauri Kenttä wrote:
>
>> On 2017-07-05 18:24, Rowan Collins wrote:
>>> On 5 July 2017 13:28:29 BST, "Johannes Schlüter"
>>> wrote:
On Mi, 2017-07-05 at 11:24 +0100, Rowan Collins wrote:
Firstly, I'm not sure where you got the names you've put in
ALL_CA
On Wed, Jul 5, 2017 at 2:34 PM, Anatol Belski wrote:
> Hi Jakub,
>
> > -Original Message-
> > From: jakub@gmail.com [mailto:jakub@gmail.com] On Behalf Of
> Jakub
> > Zelenka
> > Sent: Wednesday, July 5, 2017 3:24 PM
> > To: Niklas Keller
> > Cc: Anatol Belski ; Sara Golemon ;
> P
On 2017-07-05 18:24, Rowan Collins wrote:
On 5 July 2017 13:28:29 BST, "Johannes Schlüter"
wrote:
On Mi, 2017-07-05 at 11:24 +0100, Rowan Collins wrote:
Firstly, I'm not sure where you got the names you've put in
ALL_CAPS from, but they're not the official names of the operators
anywhere I've
On 5 July 2017 13:28:29 BST, "Johannes Schlüter" wrote:
>On Mi, 2017-07-05 at 11:24 +0100, Rowan Collins wrote:
>> Firstly, I'm not sure where you got the names you've put in
>> ALL_CAPS from, but they're not the official names of the operators
>> anywhere I've seen. The double-colon is technical
Results for project PHP master, build date 2017-07-03 19:23:07-07:00
commit: 726f2f7
previous commit:f066f59
revision date: 2017-07-03 23:21:38+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
>
> Ok, so you strive to create a completely new RFC with a solution based on
> today's situation. I think you still don't see my point. Say there's
> insecure_allow_sha1_signature, which is a stream context. Then
>
> - in 7.0 and 7.1
> - if absent, insecure_allow_sha1_signature = true
> - if p
Hi Jakub,
> -Original Message-
> From: jakub@gmail.com [mailto:jakub@gmail.com] On Behalf Of Jakub
> Zelenka
> Sent: Wednesday, July 5, 2017 3:24 PM
> To: Niklas Keller
> Cc: Anatol Belski ; Sara Golemon ; PHP
> Internals
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certific
Hi Davey,
> -Original Message-
> From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey
> Shafik
> Sent: Tuesday, July 4, 2017 8:53 AM
> To: Niklas Keller
> Cc: Sara Golemon ; Anatol Belski ;
> Jakub Zelenka ; PHP Internals
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust
Hi,
> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Wednesday, July 5, 2017 9:43 AM
> To: Anatol Belski
> Cc: Sara Golemon ; Jakub Zelenka ; PHP
> Internals
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
>
> > But the RFC is what
Hi,
On Tue, Jul 4, 2017 at 10:13 PM, Niklas Keller wrote:
> But the RFC is what you wrote about some days ago. Anything I told is
>> based on the RFC and the previous conversations. My understanding was, that
>> you were intended to push the exact RFC to vote. If you tell now there's no
>> appro
On Mi, 2017-07-05 at 11:24 +0100, Rowan Collins wrote:
> Firstly, I'm not sure where you got the names you've put in
> ALL_CAPS from, but they're not the official names of the operators
> anywhere I've seen. The double-colon is technically the "Scope
> Resolution Operator", or internally T_PAAMAYI
On 3 July 2017 16:58:16 BST, Andreas Hennings wrote:
>My motivation was to be able to use iterators and readers
>interchangeably.
>Readers are easier to implement as classes.
>Iterators have the benefit of the generator syntax.
>The idea is to have a library where some stuff is implemented as
>rea
On 5 July 2017 at 08:08, Sebastian Bergmann wrote:
> As the deprecation / strict standards notices suggest,
>
> What do you think?
It's been deprecated for years.
An RFC to remove it would be appropriate to target PHP 8. I think
nobody remembered to propose it for PHP 7.
cheers
Dan
--
PHP Int
On 5 July 2017 08:08:48 BST, Sebastian Bergmann wrote:
>Is it intentional that the DOUBLE_COLON operator can be used on a
>variable that contains a reference to an object?
>
>class C
>{
> public function m()
> {
> print '*';
> }
>}
>
>$c = new C;
>$c::m();
>
>Until yesterday I
Hi,
> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Wednesday, July 5, 2017 5:28 AM
> To: tyson andre ; internals@lists.php.net
> Subject: Re: [PHP-DEV] Exposing object handles to userland
>
> Hi!
>
> > - Can two objects can have the same object id
>
On Wed, Jul 5, 2017 at 2:01 AM, tyson andre
wrote:
> There was a proposal back in 2015 to implement
> a function spl_object_id(object $o) : int`,
> which directly returns the object handle
> (similar to `spl_object_hash`, but as an integer, not a string).
> I'm interested in finishing implementin
>
> > But the RFC is what you wrote about some days ago. Anything I told
> is
> > based on the RFC and the previous conversations. My understanding was,
> that
> > you were intended to push the exact RFC to vote. If you tell now there's
> no
> > approach and the RFC has to be ignored, then it
Is it intentional that the DOUBLE_COLON operator can be used on a
variable that contains a reference to an object?
Until yesterday I thought that only the OBJECT_OPERATOR (->) can be used
on a variable that contains an object. https://3v4l.org/59Xap proved me
wrong.
As the deprecation / stri
35 matches
Mail list logo
