On 10/28/2014 03:35 AM, Trevor Suarez wrote:
> Great job on this Adam. You whipped this up pretty quickly and it looks
> good!
I second that emotion: great work, Adam! Thank you for your work!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsu
Great job on this Adam. You whipped this up pretty quickly and it looks
good!
On Mon Oct 27 2014 at 5:21:30 PM Adam Harvey wrote:
> On 27 October 2014 18:29, Sebastian Bergmann wrote:
> > On 10/27/2014 10:45 AM, Peter Cowburn wrote:
> >> The closest we have, at the moment, is probably http://ph
Hi!
> Suggestion on improving the API: Why bother with three values?
>
> If there’s no parameter, use current behaviour. If there’s an array,
> it’s allowed classes. If that array is empty, obviously there are no
> allowed classes.
You are right, empty array probably would do the same thing.
--
On 27 October 2014 18:11:48 GMT, Stas Malyshev wrote:
>Hi!
>> As others noted, it also prevents a full-fledged objects-as-key
>> implementation in the future.
>You do realize to have such implementation we'd need to rewrite our
>hash
>layer completely and also introduce the concept of immutable ob
On 28 October 2014 05:32, Stas Malyshev wrote:
> The page looks good, but we've moved 5.4 to security-only on 18 Sep 2014
> (5.4.33), and it'll be supported for 1 year starting that date.
Good catch — I meant to put in a more generic ability to override the
support dates in include/branches.inc,
Hi!
> It hasn't propagated to all the mirrors yet, but we now have
> http://us2.php.net/supported-versions.php, as suggested. I used the
The page looks good, but we've moved 5.4 to security-only on 18 Sep 2014
(5.4.33), and it'll be supported for 1 year starting that date.
--
Stanislav Malyshev
On 27 October 2014 18:29, Sebastian Bergmann wrote:
> On 10/27/2014 10:45 AM, Peter Cowburn wrote:
>> The closest we have, at the moment, is probably http://php.net/eol.php
>> which details the versions which are no longer supported.
>
> We need the inverse of that :)
>
>> Good question.
>
> Sho
if there are no conceptual and implantation problems with static readonly
properties, it's better to implement them in the same patch.
On Mon, Oct 27, 2014 at 11:15 PM, Andrea Faulds wrote:
>
> > On 27 Oct 2014, at 19:47, Dmitry Stogov wrote:
> >
> > Oh. I meant static properties, of course. (z
> On 27 Oct 2014, at 20:38, Andrea Faulds wrote:
>
>
>> On 27 Oct 2014, at 08:03, Stas Malyshev wrote:
>>
>> I'd like to have a vote on unserialize() improvement proposal outlined here:
>> https://wiki.php.net/rfc/secure_unserialize
>
> Suggestion on improving the API: Why bother with three
> On 27 Oct 2014, at 08:03, Stas Malyshev wrote:
>
> I'd like to have a vote on unserialize() improvement proposal outlined here:
> https://wiki.php.net/rfc/secure_unserialize
Suggestion on improving the API: Why bother with three values?
If there’s no parameter, use current behaviour. If ther
> On 26 Oct 2014, at 19:16, Rowan Collins wrote:
>
> I just had a thought on both the naming and future-proofing concerns of this
> proposal: what about pre-emptively reserving the skeleton of the syntax
> needed for accessors, without actually implementing them?
I’ve been thinking about this
> On 27 Oct 2014, at 19:47, Dmitry Stogov wrote:
>
> Oh. I meant static properties, of course. (zend_compile.c line 4219)
So did I in the second paragraph. Static property get and set currently goes
through the same function… but really the reason they’re disallowed is me not
getting round to
On Mon, Oct 27, 2014 at 10:25 PM, Andrea Faulds wrote:
>
> > On 27 Oct 2014, at 18:31, Dmitry Stogov wrote:
> >
> > Hi Andrea,
> >
> > I don't have strong opinion about this proposal.
> > It doesn't make any harm to the engine, and it really may speed-up code
> especially written for read-only p
> On 27 Oct 2014, at 18:31, Dmitry Stogov wrote:
>
> Hi Andrea,
>
> I don't have strong opinion about this proposal.
> It doesn't make any harm to the engine, and it really may speed-up code
> especially written for read-only properties.
> On the other hand you introduce new orthogonal to priv
Hi Andrea,
I don't have strong opinion about this proposal.
It doesn't make any harm to the engine, and it really may speed-up code
especially written for read-only properties.
On the other hand you introduce new orthogonal to private/protected/public
visibility rule,
and I'm not sure if this comp
Hi Stas,
I'm not sure if this new argument to unserialize() is intuitive.
May be better to use separate functions - unserialize_filtered() or
something similar.
Thanks. Dmitry.
On Mon, Oct 27, 2014 at 11:03 AM, Stas Malyshev
wrote:
> Hi!
>
> I'd like to have a vote on unserialize() improvement
Hi!
> As others noted, it also prevents a full-fledged objects-as-key
> implementation in the future.
You do realize to have such implementation we'd need to rewrite our hash
layer completely and also introduce the concept of immutable object,
otherwise changing the object would make the hash compl
On Mon, Oct 27, 2014 at 2:37 AM, Stas Malyshev wrote:
> Hi!
>
> I would like to present to your attention an RFC about using object as
> keys:
>
> https://wiki.php.net/rfc/objkey
>
>
I think it should be made clear that what the target of your RFC is not to
support objects as keys, what you prop
Hi!
> Is the resulting value intended always to return the same object
> independent of what has been done to the object in the mean time?
That's on you to decide. If you have immutable value object, then yes.
If you have mutable value object (which usually isn't a good idea, but
who knows) then n
On 2014-10-26, Bob Weinand wrote:
>> Am 26.10.2014 um 17:23 schrieb Lester Caine :
>>
>> On 26/10/14 15:41, Bob Weinand wrote:
>>> Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
>>> They just initially requested it because they didn’t knew any better
>>> protocol. That’s
On Mon, 2014-10-27 at 09:35 +0100, Michael Wallner wrote:
> Actually, I see spl_object_hash($this) the 90% implementation of
> __hash(), so how about making it the default for any object?
I agree - it might be a good default.
To Will's question: It is not sufficient for all cases. Having a custom
2014-10-27 16:54 GMT+01:00 Levi Morrison :
> > I would like to present to your attention an RFC about using object as
> keys:
> >
> > https://wiki.php.net/rfc/objkey
>
> A few points I have against this proposal, as I understand it:
>
> - It does not store the object, only the result of `__hash
> I would like to present to your attention an RFC about using object as keys:
>
> https://wiki.php.net/rfc/objkey
A few points I have against this proposal, as I understand it:
- It does not store the object, only the result of `__hash`.
Without the actual object this is not helpful for any u
On 10/27/2014 11:29 AM, Sebastian Bergmann wrote:
> On 10/27/2014 10:45 AM, Peter Cowburn wrote:
>> The closest we have, at the moment, is probably http://php.net/eol.php
>> which details the versions which are no longer supported.
>
> We need the inverse of that :)
>
>> Good question.
>
> Sho
On 26 October 2014 19:55, Marc Bennewitz wrote:
>
> On 12.10.2014 12:10, Nikita Popov wrote:
> > On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll wrote:
> >
> >> Hey,
> >>
> >>
> >>
> >> I just stumbled over a method call of a non-static method with self and
> >> was asking myself again, why does
On 10/27/2014 10:48 AM, Andrea Faulds wrote:
> We should copy it.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 10/27/2014 10:45 AM, Peter Cowburn wrote:
> The closest we have, at the moment, is probably http://php.net/eol.php
> which details the versions which are no longer supported.
We need the inverse of that :)
> Good question.
Should we start http://php.net/supported-versions.php then?
--
PHP
Hello, internals!
> The name __hash is not final, I am open to using __toKey instead or any
> reasonable alternative, we may also include a couple of options in the
> vote if that will be a point of disagreement.
I like this idea with custom hash implementation because spl_object_hash()
is not re
> On 27 Oct 2014, at 09:38, Sebastian Bergmann wrote:
>
> Do we have a page that lists the versions of PHP that are currently
> supported and when their support expires? If not, why not?
>
> What I am looking for is basically a page that lists the information
> shown in the examples used in htt
Hi Sebastian,
On 27 October 2014 09:38, Sebastian Bergmann wrote:
> Hi!
>
> Do we have a page that lists the versions of PHP that are currently
> supported and when their support expires?
The closest we have, at the moment, is probably http://php.net/eol.php
which details the versions which
Hi!
Do we have a page that lists the versions of PHP that are currently
supported and when their support expires? If not, why not?
What I am looking for is basically a page that lists the information
shown in the examples used in https://wiki.php.net/rfc/releaseprocess
Thanks!
Sebastian
-
> On 27 Oct 2014, at 06:36, Stas Malyshev wrote:
>
> Hi!
>
>> It seems __toScalar might be a good name, this is what the method
>> actually does, the engine then coerces to a type suitable for use as a
>> key, but you can return a double. It might be more forward thinking
>> therefore to use th
On 27/10/14 01:37, Stas Malyshev wrote:
> The name __hash is not final, I am open to using __toKey instead or any
> reasonable alternative, we may also include a couple of options in the
> vote if that will be a point of disagreement.
I don't think it's clear from the RFC ...
Is the resulting valu
On 27/10/14 04:08, Will Fitch wrote:
>
>> On Oct 26, 2014, at 9:43 PM, Stas Malyshev
>> wrote:
>>
>> Hi!
>>
>>> I’m trying to wrap my head around a real-world use-case with
>>> this. We have spl_object_hash, which effectively provides a
>>> unique hash for
>>
>> This hash has nothing to do wit
On 27/10/14 08:09, Stas Malyshev wrote:
> Hi!
>
>> I don't like this, mainly because it blocks a future direct use and storage
>> of objects as keys in an array, i.e. what SplObjectStorage does.
>
> It does not. It just allows the objects to control how they are seen
> when they are used as keys
On 26/10/14 22:21, Stas Malyshev wrote:
> Hi!
>
>> The only way to do this in PHP now is write a userland function that parses
>> multipart form data, which is non-trivial. I had written one, but would
>
> It is true that PUT data need to be parsed, however it is not true you
> have to implement
Hi!
I'd like to have a vote on unserialize() improvement proposal outlined here:
https://wiki.php.net/rfc/secure_unserialize
soon-ish, but since discussion on it has been more than a year ago I'd
like to give it some prior notice and some time to re-consider. I still
think it is a good improvemen
On Mon, 2014-10-27 at 00:41 -0700, Stas Malyshev wrote:
> Hi!
>
> > Once your proposal is in the language, you will never, in the future, be
> > able to add real support for objects as keys, because the semantics is
> > blocked.
>
> This implies this support is not "real" and we want some other s
Hi!
> Once your proposal is in the language, you will never, in the future, be
> able to add real support for objects as keys, because the semantics is
> blocked.
This implies this support is not "real" and we want some other support.
I don't think I agree with either.
> I do understand where yo
Am 27.10.2014 08:09 schrieb "Stas Malyshev" :
>
> > I don't like this, mainly because it blocks a future direct use and
storage
> > of objects as keys in an array, i.e. what SplObjectStorage does.
>
> It does not. It just allows the objects to control how they are seen
> when they are used as keys
Hi!
> I don't like this, mainly because it blocks a future direct use and storage
> of objects as keys in an array, i.e. what SplObjectStorage does.
It does not. It just allows the objects to control how they are seen
when they are used as keys in regular PHP arrays. That does not prevent
SplObje
On Sun, 2014-10-26 at 23:36 -0700, Stas Malyshev wrote:
> Hi!
>
> > It seems __toScalar might be a good name, this is what the method
> > actually does, the engine then coerces to a type suitable for use as a
> > key, but you can return a double. It might be more forward thinking
> > therefore to
42 matches
Mail list logo
