Stas + Tjerk,
is called, it's in isset expression context somewhere upstream?
While it may be nice in theory, in practice I'm not sure it's doable -
or worth making doable.
Thanks for your input, I suspected there was a certain complexity I was
not immediately seeing.
-ralph
--
PHP Interna
Hi,
With the release of 7.0.0 beta 1 I think it's time we
introduce ChangeLog-7.php to the website.
Both ChangeLog-4.php and ChangeLog-5.php have started with the first Beta
of the major releases.
Any objections ?
Kaplan
VCS Account Approved: matttait approved by rasmus \o/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> De : Ryan Pallas [mailto:derokor...@gmail.com]
>
> With all the new typing and strict mode in PHP7, I'm wondering if there is
> any planned support for typing of properties in a future version. IE
> something like:
>
> class Foo {}
> class Bar {
>public Foo $foo;
>
>public function __c
To develop core security features, security enhancements and performance
enhancements for PHP Core (i.e. the C code for Zend and PHP Core, not PHP
extensions or PHP applications). Initially I\'ll be focusing on
integrating compiler and security level improvements to PHP binaries.
I have already
Hi
On 13 Jul 2015 14:23, "Dean Eigenmann" wrote:
>
> Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable
regarding Json to Object unserialization.
As it's been said, the first part (casting) is a no-go. It would have to be
done in a run time by scanning of opcode array which is n
On Mon, Jul 13, 2015 at 8:03 AM, Ryan Pallas wrote:
>> Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable
>> regarding Json to Object unserialization.
>>
>> I like the idea, but how do you handle complex json notations, that may
> contain arrays of objects? Say:
> {
>"id": 123
> On Jul 13, 2015, at 1:56 PM, Dean Eigenmann wrote:
>
> I have updated the RFC with a new section showing the updates
>
> Sent from my iPhone
>
>> On 13 Jul 2015, at 20:47, Benjamin Eberlei wrote:
>>
>> On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann
>> wrote:
>>
>>> Ive just opened a new
I have updated the RFC with a new section showing the updates
Sent from my iPhone
> On 13 Jul 2015, at 20:47, Benjamin Eberlei wrote:
>
> On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann
> wrote:
>
>> Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding
>> Json to Obje
On 07/13/2015 11:23 AM, Matt Tait wrote:
> Hi all,
>
> I'm Matt Tait; a security researcher at Google, and I'm quite interested in
> looking at and helping to build new security-related features within PHP;
> i.e. features that reduce the likelihood that deployments of PHP end up
> being hacked.
>
On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann
wrote:
> Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding
> Json to Object unserialization.
>
The approach with typecasting will not work, because the function
json_decode doesn't have that information.
Instead somethi
Hi all,
I'm Matt Tait; a security researcher at Google, and I'm quite interested in
looking at and helping to build new security-related features within PHP;
i.e. features that reduce the likelihood that deployments of PHP end up
being hacked.
In the short term, I'm quite interested in looking at
On Mon, Jul 13, 2015 at 1:40 AM, Rasmus Lerdorf wrote:
>
> Like I said, adding type checks to every assignment is a rather large
> change, and I doubt it can be done without some nasty performance costs.
>
> Honestly, I would rather have a speedy runtime and put the effort into a
> static analysi
Ryan,
I think the usage of this won't support multidimensional arrays.
However in the decode function,
You could specify
Foreach ($arr['permission'] as $permission) {
$this->permissions[] = (permission) json_decode($permission);
}
Sent from my iPhone
On 13 Jul 2015, at 17:03, Ryan Pallas wro
I will update the spec for it to be a function, called something like
json_decode_to($json, $class, $mapping = []);
With mapping you could then specify with array keys map to which class property.
Sent from my iPhone
> On 13 Jul 2015, at 16:59, Rowan Collins wrote:
>
> guilhermebla...@gmail.c
>
>
> Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable
>
> regarding Json to Object unserialization.
>
> I like the idea, but how do you handle complex json notations, that may
contain arrays of objects? Say:
{
"id": 123
"type": "user",
"name": "derokorian"
"permissio
guilhermebla...@gmail.com wrote on 13/07/2015 15:19:
What about JsonDeserializable? I would like to have the choice to have a
serialize-only operation.
Yeah, this would need to be a new interface, because interfaces can't
have optional methods, so changing the existing interface would
instant
I think the suggested decode function would be the best way to handle this.
On Jul 13, 2015, at 04:20 PM, "guilhermebla...@gmail.com"
wrote:
What about JsonDeserializable? I would like to have the choice to have a
serialize-only operation.
On Mon, Jul 13, 2015 at 10:13 AM, Dean Eigenmann
wro
What about JsonDeserializable? I would like to have the choice to have a
serialize-only operation.
On Mon, Jul 13, 2015 at 10:13 AM, Dean Eigenmann
wrote:
> The Additional function you have proposed seems like the easiest and best
> way to do it currently without changing the language. I was thi
The Additional function you have proposed seems like the easiest and best way
to do it currently without changing the language. I was thinking of giving the
cast syntax special meaning if used in connection with json_decode, but this
would most likely be near to impossible.
On Jul 13, 2015, at
Hi,
I like the general idea behind that proposal.
I'm not sure how you would want to implement that however (please
expand the rfc on that topic).
Do you want to give the cast syntax a special meaning if used in
connection with json_decode or add the general ability to
cast a stdClass object (as
Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding
Json to Object unserialization.
On Mon, Jul 13, 2015 at 9:35 AM, Dean Eigenmann
wrote:
> Hey,
>
> Could I please have RFC Karma for my wiki account, (user: decanus) as I
> would like to create an RFC for my concept
> https://decanus.github.io/JsonSerializable-Proposal/
>
> Thanks
>
hi,
I've granted you with rfc karma, you sho
On 13 July 2015 at 13:23, Lester Caine wrote:
> On 13/07/15 13:12, Marco Pivetta wrote:
> > It's actually the PhpDocumentor folks (and Mike van Riel in first place)
> > pushing forward PSR-5: there's nothing more "official" than that right
> now.
> > That's the current standardization path.
>
> d
On 13/07/15 13:12, Marco Pivetta wrote:
> It's actually the PhpDocumentor folks (and Mike van Riel in first place)
> pushing forward PSR-5: there's nothing more "official" than that right now.
> That's the current standardization path.
docblock annotation has been the subject of RFC's as alternati
On 7/13/2015 4:36 AM, Lester Caine wrote:
Coming from a background of 'traditional' php design, all of my code and
the libraries I use are documented via phpdoc style annotation which the
IDE picks up, and phpdocumentor1 produced a good API description. This
was also a GOOD basis to tidy up the v
On 13 July 2015 at 12:20, Lester Caine wrote:
> On 13/07/15 11:51, Marco Pivetta wrote:
> > Please refer to https://github.com/php-fig/fig-standards/pull/169
>
> This just adds another level of complication. FIG is not part of the
> core PHP standards, and some of their choices simply don't fit w
On 13/07/15 11:51, Marco Pivetta wrote:
> Please refer to https://github.com/php-fig/fig-standards/pull/169
This just adds another level of complication. FIG is not part of the
core PHP standards, and some of their choices simply don't fit with
legacy code. I suspect that some of the problems I'm
Hi Lester,
On 13 July 2015 at 11:36, Lester Caine wrote:
> On 13/07/15 08:49, Pierre Joye wrote:
> >> No, not "just" my IDE can work. IDE is just the side effect. Proper
> >> > documentation does much more than that.
> > It seems to go off topic. Docblocks are only slightly related to this
> > t
On 13/07/15 08:49, Pierre Joye wrote:
>> No, not "just" my IDE can work. IDE is just the side effect. Proper
>> > documentation does much more than that.
> It seems to go off topic. Docblocks are only slightly related to this
> thread. The same could be said about annotation (which are widely used
On Jul 13, 2015 2:08 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > Of course it's a win. Or do you like to write docblocks for every
> > single class property or method (even when the member is obvious) just
>
> Yes. What is obvious to you today may not be at all obvious to your
> coworker two yea
On 07/13/2015 12:16 AM, Robert Stoll wrote:
> Another point of discussion should be how strict a property type hint will
> be. Currently, parameter type hints are only binding for the call side but
> not within the function body.
> For instance, function foo(Foo $x){ $x = 1;} is perfectly valid.
Hey,
Could I please have RFC Karma for my wiki account, (user: decanus) as I would
like to create an RFC for my concept
https://decanus.github.io/JsonSerializable-Proposal/
Thanks
> -Ursprüngliche Nachricht-
> Von: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Gesendet: Montag, 13. Juli 2015 02:12
> An: Larry Garfield; internals@lists.php.net
> Betreff: Re: [PHP-DEV] PHP7 and types
>
> On 07/12/2015 12:37 PM, Larry Garfield wrote:
> > I don't know why we're even ta
Hi!
> Of course it's a win. Or do you like to write docblocks for every
> single class property or method (even when the member is obvious) just
Yes. What is obvious to you today may not be at all obvious to your
coworker two years later.
> to have a "@var" so your IDE can work?
No, not "just"
35 matches
Mail list logo