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 the name __toScalar, while today we'd only be using
it for this,
On Oct 27, 2014, at 1:36 AM, Stas Malyshev smalys...@gmail.com 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
Am 27.10.2014 02:37 schrieb Stas Malyshev smalys...@gmail.com:
I would like to present to your attention an RFC about using object as
keys:
https://wiki.php.net/rfc/objkey
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
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 use the
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
Am 27.10.2014 08:09 schrieb Stas Malyshev smalys...@sugarcrm.com:
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
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 your
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 support.
I
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
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 MIME
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 in
On 27/10/14 04:08, Will Fitch wrote:
On Oct 26, 2014, at 9:43 PM, Stas Malyshev smalys...@gmail.com
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 with
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 value
On 27 Oct 2014, at 06:36, Stas Malyshev smalys...@gmail.com 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
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
Hi Sebastian,
On 27 October 2014 09:38, Sebastian Bergmann sebast...@php.net 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
On 27 Oct 2014, at 09:38, Sebastian Bergmann sebast...@php.net 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
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
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
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 26 October 2014 19:55, Marc Bennewitz php@mabe.berlin wrote:
On 12.10.2014 12:10, Nikita Popov wrote:
On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll p...@tutteli.ch wrote:
Hey,
I just stumbled over a method call of a non-static method with self and
was asking myself again,
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.
Should we
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
2014-10-27 16:54 GMT+01:00 Levi Morrison le...@php.net:
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
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
On 2014-10-26, Bob Weinand bobw...@hotmail.com wrote:
Am 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk:
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
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
On Mon, Oct 27, 2014 at 2:37 AM, Stas Malyshev smalys...@gmail.com 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,
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
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 smalys...@sugarcrm.com
wrote:
Hi!
I'd like to have a vote on
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
On 27 Oct 2014, at 18:31, Dmitry Stogov dmi...@zend.com 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
On Mon, Oct 27, 2014 at 10:25 PM, Andrea Faulds a...@ajf.me wrote:
On 27 Oct 2014, at 18:31, Dmitry Stogov dmi...@zend.com 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
On 27 Oct 2014, at 19:47, Dmitry Stogov dmi...@zend.com 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
On 26 Oct 2014, at 19:16, Rowan Collins rowan.coll...@gmail.com 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
On 27 Oct 2014, at 08:03, Stas Malyshev smalys...@sugarcrm.com 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
On 27 Oct 2014, at 20:38, Andrea Faulds a...@ajf.me wrote:
On 27 Oct 2014, at 08:03, Stas Malyshev smalys...@sugarcrm.com 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:
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 a...@ajf.me wrote:
On 27 Oct 2014, at 19:47, Dmitry Stogov dmi...@zend.com wrote:
Oh. I meant static
On 27 October 2014 18:29, Sebastian Bergmann sebast...@php.net 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.
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 28 October 2014 05:32, Stas Malyshev smalys...@sugarcrm.com 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
On 27 October 2014 18:11:48 GMT, Stas Malyshev smalys...@gmail.com 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
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.
--
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 ahar...@php.net wrote:
On 27 October 2014 18:29, Sebastian Bergmann sebast...@php.net wrote:
On 10/27/2014 10:45 AM, Peter Cowburn wrote:
The closest we have, at the
44 matches
Mail list logo
