Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC, either
people will like it or they won't, there isn't a lot more to say here than
what's in the RFC so please have a read.
https://wiki.php.net/rfc/additional-splat-usage
Thanks, Chris
I'd like to open discussion a relatively simple and clear-cut RFC, either
people will like it or they won't, there isn't a lot more to say here than
what's in the RFC so please have a read.
Sounds good to me! It’s something I’d thought would be good for completeness’s sake when splats were added. Glad to see this.
Andrea Faulds
http://ajf.me/
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC, either
people will like it or they won't, there isn't a lot more to say here than
what's in the RFC so please have a read.https://wiki.php.net/rfc/additional-splat-usage
Thanks, Chris
I remember asking Nikita about whether this was possible during the
original splat RFC. Sticking to my guns, I think this makes sense.
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC,
either
people will like it or they won't, there isn't a lot more to say here
than
what's in the RFC so please have a read.
I like the concept with list-style arrays, but find the behaviour with regards associative arrays quite confusing. There's already a difference in behaviour between array_merge and + in this regard, and having a third way of writing the same thing isn't great - it would apparently be legal to write $foobar = [...$foo, ...$bar]; to simply merge two existing arrays.
If anything, I think I would expect the keys of splatted arrays to be discarded, since it seems most natural to use this in a list context, but I can imagine always having to check in the manual.
--
Rowan Collins
[IMSoP]
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC,
either
people will like it or they won't, there isn't a lot more to say here
than
what's in the RFC so please have a read.I like the concept with list-style arrays, but find the behaviour with regards associative arrays quite confusing. There's already a difference in behaviour between array_merge and + in this regard, and having a third way of writing the same thing isn't great - it would apparently be legal to write $foobar = [...$foo, ...$bar]; to simply merge two existing arrays.
If anything, I think I would expect the keys of splatted arrays to be discarded, since it seems most natural to use this in a list context, but I can imagine always having to check in the manual.
I don’t think they’d be discarded. The named parameters RFC proposes that named keys be kept by ..., and I’d prefer we do that since it makes more sense anyway: [‘foo’=>’bar] and [...[’foo’=>’bar’]] should act the same, no?
Also, since arrays don’t discard duplicate keys normally, ... shouldn’t.
--
Andrea Faulds
http://ajf.me/
If anything, I think I would expect the keys of splatted arrays to be discarded, since it seems most natural to use this in a list context, but I can imagine always having to check in the manual.
I don’t think they’d be discarded. The named parameters RFC proposes that named keys be kept by ..., and I’d prefer we do that since it makes more sense anyway:
Interestingly, the current behaviour of PHP is to issue an error in this
situtation ("Catchable fatal error: Cannot unpack array with string
keys"), while HHVM simply strips off the keys and unpacks the values:
http://3v4l.org/vi7fn
However, if you present multiple arrays with integer keys, HHVM issues
an error ("Fatal error: Only the last parameter in a function call is
allowed to use ..."), while PHP happily merges them, appending and
renumbering the keys as though array_merge() had been used:
http://3v4l.org/fXE8U
[‘foo’=>’bar] and [...[’foo’=>’bar’]] should act the same, no?
By that logic, [42 => true] and [...[42 => true]] should also act the
same, but if we make it a short-hand for array_merge(), then numeric
keys will be discarded.
In fact, I think that's what concerns me about this proposal - it's
not obvious how it should behave, and different use cases lend
themselves to different answers.
--
Rowan Collins
[IMSoP]
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC,
either
people will like it or they won't, there isn't a lot more to say here
than
what's in the RFC so please have a read.I like the concept with list-style arrays, but find the behaviour with
regards associative arrays quite confusing. There's already a difference in
behaviour between array_merge and + in this regard, and having a third way
of writing the same thing isn't great - it would apparently be legal to
write $foobar = [...$foo, ...$bar]; to simply merge two existing arrays.
It would be legal and I don't see this as a problem?
This would be identical to array_merge($foo, $bar) and this is intentional,
the proposal is entirely intended to make merging literal constant arrays
and variable arrays simpler, it doesn't add yet another set of rules for
how the merge will be performed - we really don't need that.
If you wanted to discard the keys and turn two associative arrays into a
list, you could write $foobar = [...array_values($foo),
...array_values($bar)] (but I don't recommend this).
More sensible uses w.r.t. associative array merging might be creating the
array to pass to PDOStatement->execute() (this is quite a contrived
example, but I have had effectively this use case in more complex code):
function execute_statement_with_extra_params(PDOStatement $stmt, array
$params)
{
return $stmt->execute(['param1' => 1, 'param2' => 'value', ...$params]);
}
I had a similar case recently and was surprised to find that it didn't work
(i.e. I find it quite intuitive), which is the main motivation for writing
this RFC.
If anything, I think I would expect the keys of splatted arrays to be
discarded, since it seems most natural to use this in a list context, but I
can imagine always having to check in the manual.--
Rowan Collins
[IMSoP]
On 4 November 2014 18:14, Rowan Collins <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com> wrote:On 3 November 2014 22:45:11 GMT, Chris Wright <daverandom@php.net <mailto:daverandom@php.net>> wrote: >Good evening list, > >I'd like to open discussion a relatively simple and clear-cut RFC, >either >people will like it or they won't, there isn't a lot more to say here >than >what's in the RFC so please have a read. > >https://wiki.php.net/rfc/additional-splat-usage I like the concept with list-style arrays, but find the behaviour with regards associative arrays quite confusing. There's already a difference in behaviour between array_merge and + in this regard, and having a third way of writing the same thing isn't great - it would apparently be legal to write $foobar = [...$foo, ...$bar]; to simply merge two existing arrays.It would be legal and I don't see this as a problem?
This would be identical to array_merge($foo, $bar) and this is
intentional, the proposal is entirely intended to make merging literal
constant arrays and variable arrays simpler, it doesn't add yet
another set of rules for how the merge will be performed - we really
don't need that.
So, it's just an operator version of array_merge(), with no advantages
other than brevity? I'm not sure why it's any more or less applicable to
constant arrays vs variables than + or array_merge() are.
More sensible uses w.r.t. associative array merging might be creating
the array to pass to PDOStatement->execute() (this is quite a
contrived example, but I have had effectively this use case in more
complex code):function execute_statement_with_extra_params(PDOStatement $stmt, array
$params)
{
return $stmt->execute(['param1' => 1, 'param2' => 'value',
...$params]);
}
For this use case, since you're using associative arrays, the existing +
operator works just fine:
$stmt->execute(['param1' => 1, 'param2' => 'value'] + $params);
Or perhaps, since + prefers the first of each set of duplicates, rather
than the last, you might invert it to this:
$stmt->execute($params + ['param1' => 1, 'param2' => 'value']);
The inversion is a bit annoying sometimes, but the only real reason I
can think of to use array_merge() (and therefore the proposed ...
operator) is the special handling of numeric keys:
|[1, 2] + [3, 4] // evaluates to [1, 2]
array_merge([1, 2], [3, 4]); // |||evaluates to [1, 2, 3, 4]
|[...[1, 2], ...[3, 4]] // identical to array_merge() version
Since this "concatenation" behaviour is the main advantage of the new
operator, it feels a little awkward for it to work with string keys at
all. I would rather have a distinct concatenation operator:
[1, 2] . [3, 4] // evaluates to [1, 2, 3, 4]
['a' => 1] . ['a' => 2] // evaluates to [1, 2]
or if overloading . seems problematic, reuse ... as a binary operator:
[1, 2] ... [3, 4]
|
Then you'd have two operators for the two main behaviours: keep all
keys, discard duplicates; and discard all keys, keep duplicates. The
"smart" behaviour of array_merge() remains if you need it, but most of
the time you should know whether you're dealing with associative or
positional arrays, and can select the appropriate operator.
--
Rowan Collins
[IMSoP]
If anything, I think I would expect the keys of splatted arrays to be discarded, since it seems most natural to use this in a list context, but I can imagine always having to check in the manual.
I agree on this point. Duplicate keys should not overwrite each other.
[...$foo, ...$bar] should literally unpack the values as if they were
comma delimited and discard all key information.
If anything, I think I would expect the keys of splatted arrays to be
discarded, since it seems most natural to use this in a list context, but I
can imagine always having to check in the manual.I agree on this point. Duplicate keys should not overwrite each other.
[...$foo, ...$bar] should literally unpack the values as if they were
comma delimited and discard all key information.
Here's how I picture this, which is the rationale for my view on how it
should behave:
$foo = ['a' => 1, 'b' => 2, 'c' => 3];
$bar = ['c' => 4, 'd' => 5, 'e' => 6, ...$foo];
// is identical to writing
$bar = ['a' => 1, 'b' => 2, 'c' => 3, 'c' => 4, 'd' => 5, 'e' => 6];
In other words, in that scenario it's basically syntactic sugar to avoid
having to write out the "body" of the array twice, and would behave
identically as if you had done this.
Of course, if the majority opinion that this is not the correct approach,
I'm happy to admit I'm wrong :-)
If anything, I think I would expect the keys of splatted arrays to be
discarded, since it seems most natural to use this in a list context, but I
can imagine always having to check in the manual.I agree on this point. Duplicate keys should not overwrite each other.
[...$foo, ...$bar] should literally unpack the values as if they were
comma delimited and discard all key information.Here's how I picture this, which is the rationale for my view on how it
should behave:$foo = ['a' => 1, 'b' => 2, 'c' => 3];
$bar = ['c' => 4, 'd' => 5, 'e' => 6, ...$foo];
// is identical to writing
$bar = ['a' => 1, 'b' => 2, 'c' => 3, 'c' => 4, 'd' => 5, 'e' => 6];In other words, in that scenario it's basically syntactic sugar to avoid
having to write out the "body" of the array twice, and would behave
identically as if you had done this.Of course, if the majority opinion that this is not the correct approach,
I'm happy to admit I'm wrong :-)
Having performed an extremely unscientific (but I think reasonably fair and
unbiased) straw-poll of a few people today, I can tell you that the general
expectation of everyone I have spoken to about it is that it would work the
same as outlined above.
https://bugs.php.net/bug.php?id=68331
I was hoping the submitter (or one of their coworkers who commented on
it) would reach out to the list themselves to get more information
since I don't know the whole situation. I did ask them to...
Sorry, I had an email written up to send out to the list but missent
it yesterday. Thank you for taking the time to write this up though!
Story thus far:
Yasuo's session-lock-ini RFC 1 in February 2014 was (partially)
approved - the relevant change being that it adds support for lazy
writing. Optionally. There's a pull request with it that has NOT been
merged; as far as I can tell it's because there was discussion after
the vote raising problems and there was another RFC 2 (since
withdrawn) to change the first one. I also vaguely remember there
being merge problems between 5.6 and something?Unrelated and prior to all this was a commit 3 in August 2013 for
request #17860 [4] that made session writes lazy for everyone. [see
session.c] Not optionally. It went into 5.6. Apparently this caused
problems for some people as they made 68331 a few days ago. I'm not
entirely sure that the userland code couldn't be changed to deal with
the lazy writing without requiring the crazy workaround they
described, but whatever I don't know their codebase.
So for us we'd like to be able to write the session during shutdown
and that (prior to PHP 5.6) means doing it in the write() handler
that we registered. In PHP 5.6 the only reasonable alternative in
userland is to do it in the close() handler instead. This is really
hacky and there are other quirks with doing it in close instead.
We really have two issues with the lazy writing implementation:
- We can't really update the timestamp for the session cleanly
without changing where the write is happening. - Data that we want to save independent of $_SESSION doesn't cause
the session to be marked as needing saved. That means we don't
get the callback to the write() handler.
I tried explaining that session-lock-ini is not yet merged, despite
being approved and being listed under the PHP 5.6 heading at /rfc, and
that the commit in question was entirely separate, to no avail.
Meanwhile I did NAB the bug on the grounds that the change was
intentional.
I don't think anyone is arguing that it was unintentional. It
simply was a backwards incompatible change that happened before the
RFC and wasn't mentioned in the backwards incompatible list.
The bug that the commit actually addressed was from 12 years ago and
wasn't even asking for the feature that got implemented to address
the bug. That made me suspicious of the route that commit took to
get into PHP 5.6.
So what's up with the RFC and its code? Is it still happening for 5.6
(too late?) or 5.7 (I lost track if we're doing that) or 7? Any
suggestions for what I can tell the folks concerned?
It seems that PHP 5.6 is under a feature lock so I'd be very
surprised if this was allowed in for PHP 5.6. Unfortunately, the best
route may be to revert the commit from 2013 since the change seemed
like it sidestepped the entire RFC process.
Here is my original email I was going to send:
It seems like the RFC for session lazy_write passed and was intended
for PHP 5.6 but didn't quite make it into the release. Is anyone aware
of the status of the RFC and what will actually happen as it was
approved but not implemented in time? 1
Similarly, there was a commit 2 related to doing a lazy_write on
session that appears to have been committed far before the RFC was
drafted but had unintended consequences. There is an unfortunate
backwards incompatible bug in this commit that custom session handlers
are not called when the session hasn't changed so anything outside of
the normal $_SESSION state isn't handled. In addition to that, this
has caused updating session timestamps to be more difficult and
require a slight rewrite of PHP implementations (ironically not
writing in the write() call).
I have created a bug 3 for this but it got NABed due to the RFC but
it really appears to be stagnant at this point. PHP 5.6 is already
released and I feel like this has really manifested as a bug at this
point since it's actively causing issues with custom session handlers.
Mark
On Wed, Nov 5, 2014 at 6:49 PM, Mark Caudill mark.caudill@grooveshark.com
wrote:
https://bugs.php.net/bug.php?id=68331
I was hoping the submitter (or one of their coworkers who commented on
it) would reach out to the list themselves to get more information
since I don't know the whole situation. I did ask them to...Sorry, I had an email written up to send out to the list but missent
it yesterday. Thank you for taking the time to write this up though!Story thus far:
Yasuo's session-lock-ini RFC 1 in February 2014 was (partially)
approved - the relevant change being that it adds support for lazy
writing. Optionally. There's a pull request with it that has NOT been
merged; as far as I can tell it's because there was discussion after
the vote raising problems and there was another RFC 2 (since
withdrawn) to change the first one. I also vaguely remember there
being merge problems between 5.6 and something?Unrelated and prior to all this was a commit 3 in August 2013 for
request #17860 [4] that made session writes lazy for everyone. [see
session.c] Not optionally. It went into 5.6. Apparently this caused
problems for some people as they made 68331 a few days ago. I'm not
entirely sure that the userland code couldn't be changed to deal with
the lazy writing without requiring the crazy workaround they
described, but whatever I don't know their codebase.So for us we'd like to be able to write the session during shutdown
and that (prior to PHP 5.6) means doing it in the write() handler
that we registered. In PHP 5.6 the only reasonable alternative in
userland is to do it in the close() handler instead. This is really
hacky and there are other quirks with doing it in close instead.We really have two issues with the lazy writing implementation:
- We can't really update the timestamp for the session cleanly
without changing where the write is happening.- Data that we want to save independent of $_SESSION doesn't cause
the session to be marked as needing saved. That means we don't
get the callback to the write() handler.I tried explaining that session-lock-ini is not yet merged, despite
being approved and being listed under the PHP 5.6 heading at /rfc, and
that the commit in question was entirely separate, to no avail.
Meanwhile I did NAB the bug on the grounds that the change was
intentional.I don't think anyone is arguing that it was unintentional. It
simply was a backwards incompatible change that happened before the
RFC and wasn't mentioned in the backwards incompatible list.The bug that the commit actually addressed was from 12 years ago and
wasn't even asking for the feature that got implemented to address
the bug. That made me suspicious of the route that commit took to
get into PHP 5.6.So what's up with the RFC and its code? Is it still happening for 5.6
(too late?) or 5.7 (I lost track if we're doing that) or 7? Any
suggestions for what I can tell the folks concerned?It seems that PHP 5.6 is under a feature lock so I'd be very
surprised if this was allowed in for PHP 5.6. Unfortunately, the best
route may be to revert the commit from 2013 since the change seemed
like it sidestepped the entire RFC process.Here is my original email I was going to send:
It seems like the RFC for session lazy_write passed and was intended
for PHP 5.6 but didn't quite make it into the release. Is anyone aware
of the status of the RFC and what will actually happen as it was
approved but not implemented in time? 1Similarly, there was a commit 2 related to doing a lazy_write on
session that appears to have been committed far before the RFC was
drafted but had unintended consequences. There is an unfortunate
backwards incompatible bug in this commit that custom session handlers
are not called when the session hasn't changed so anything outside of
the normal $_SESSION state isn't handled. In addition to that, this
has caused updating session timestamps to be more difficult and
require a slight rewrite of PHP implementations (ironically not
writing in the write() call).I have created a bug 3 for this but it got NABed due to the RFC but
it really appears to be stagnant at this point. PHP 5.6 is already
released and I feel like this has really manifested as a bug at this
point since it's actively causing issues with custom session handlers.Mark
--
Hi,
thanks for the report.
first let me clarify a couple of things:
1, neither of https://wiki.php.net/rfc/session-lock-ini or
https://wiki.php.net/rfc/session-read_only-lazy_write made into 5.6 in
their proposed forms
2, the changes about the write short circuit (and session_gc() and
session_serializer_name()) and the lack of consensus went under the radar
originally, as it was commited to master before 5.6.
sometimes later the write short circuit one was spotted, and Yasuo was
asked to make a proper rfc about it, which lead to the creation of
session-lock-ini rfc which didn't got much attention originally, but the
option which passed was basically the same thing which was committed
before, plus an optional argument for session_start which controlled the
behavior.
this rfc was not followed up on though, and this was spotted by Andrey who
pointed out the discrepancies about the session related changes and asked
the list to reconsider the inclusion of those:
http://grokbase.com/t/php/php-internals/143brgjp9d/revert-session-serializer-name-session-gc
http://grokbase.com/t/php/php-internals/143fagz0a7/rfc-revert-extend-postpone-original-rfc-about-read-only-lazy-write-sessions
http://grokbase.com/t/php/php-internals/143r244qtr/rfc-session-start-read-only-lazy-write-take-2
a lengthy discussion broke out and Yasuo reverted the changes about
session_gc() and session_serializer_name() which was introduced without
prior discussion, and there were some more discussion about the committed
write short circuit and the accepted but not yet merged lazy_write, which
also triggered the creation of
https://wiki.php.net/rfc/session-read_only-lazy_write but in the end,
nothing was done, neither of reverting the original short circuit nor
properly exposing this to the userland session handler.
We also had a last minute blocker issue because of the write short circuit(
https://bugs.php.net/bug.php?id=67694) but I guess we were too focused on
shipping 5.6 at that point to take a step back and reconsider
reverting/refining this small performance improvement before the 5.6.0
final.
I cc'ed Julien(the other RM for 5.6), Yasuo (the original author of the
change in question) and Andrey(who was the most vocal and active person
discussing the lazy write changes with Yasuo and the author of the
https://wiki.php.net/rfc/session-read_only-lazy_write rfc), and I would
like to hear your opinion on the situation at hand.
Personally I think that we can have 3 options:
- keep everything as is, including the perf gain for those using the
default session handler and risk the potential problems for others (for
example some cache/memcache based handlers could be expecting the session
write handler to be called to not let active but unmodified sessions to be
expired/purged from the cache). (we keep a potential BC break and if you
need to work around you have to do some acrobatics) - introduce a better interface for custom handlers which allows them to
write custom logic to decide if they want to write out the session or not.
(this would still be a potential BC break for some people, but a better
upgrade path, but it would also cause introducing new features in a minor
version, which would cause for apps/libs to either depend on a minor
version or support both versions in their custom session handler). - revert the write short circuit. (this would cause a small perf loss
for most users - to the same level as it was before 5.6 -, but it would
eliminate the BC break when migrating to 5.6, and it would allow us to take
our time to have time to properly figure out the introduction of this
feature including the interaction with the custom session handlers).
I would vote for 3,
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi all,
Hi,
thanks for the report.
first let me clarify a couple of things:1, neither of https://wiki.php.net/rfc/session-lock-ini or
https://wiki.php.net/rfc/session-read_only-lazy_write made into 5.6 in their
proposed forms
2, the changes about the write short circuit (andsession_gc()and
session_serializer_name()) and the lack of consensus went under the radar
originally, as it was commited to master before 5.6.sometimes later the write short circuit one was spotted, and Yasuo was asked
to make a proper rfc about it, which lead to the creation of
session-lock-ini rfc which didn't got much attention originally, but the
option which passed was basically the same thing which was committed before,
plus an optional argument for session_start which controlled the behavior.
this rfc was not followed up on though, and this was spotted by Andrey who
pointed out the discrepancies about the session related changes and asked
the list to reconsider the inclusion of those:
http://grokbase.com/t/php/php-internals/143brgjp9d/revert-session-serializer-name-session-gc
http://grokbase.com/t/php/php-internals/143fagz0a7/rfc-revert-extend-postpone-original-rfc-about-read-only-lazy-write-sessions
http://grokbase.com/t/php/php-internals/143r244qtr/rfc-session-start-read-only-lazy-write-take-2a lengthy discussion broke out and Yasuo reverted the changes about
session_gc()and session_serializer_name() which was introduced without
prior discussion, and there were some more discussion about the committed
write short circuit and the accepted but not yet merged lazy_write, which
also triggered the creation of
https://wiki.php.net/rfc/session-read_only-lazy_write but in the end,
nothing was done, neither of reverting the original short circuit nor
properly exposing this to the userland session handler.We also had a last minute blocker issue because of the write short
circuit(https://bugs.php.net/bug.php?id=67694) but I guess we were too
focused on shipping 5.6 at that point to take a step back and reconsider
reverting/refining this small performance improvement before the 5.6.0
final.I cc'ed Julien(the other RM for 5.6), Yasuo (the original author of the
change in question) and Andrey(who was the most vocal and active person
discussing the lazy write changes with Yasuo and the author of the
https://wiki.php.net/rfc/session-read_only-lazy_write rfc), and I would like
to hear your opinion on the situation at hand.
Personally I think that we can have 3 options:
- keep everything as is, including the perf gain for those using the default
session handler and risk the potential problems for others (for example some
cache/memcache based handlers could be expecting the session write handler
to be called to not let active but unmodified sessions to be expired/purged
from the cache). (we keep a potential BC break and if you need to work
around you have to do some acrobatics)- introduce a better interface for custom handlers which allows them to write
custom logic to decide if they want to write out the session or not. (this
would still be a potential BC break for some people, but a better upgrade
path, but it would also cause introducing new features in a minor version,
which would cause for apps/libs to either depend on a minor version or
support both versions in their custom session handler).- revert the write short circuit. (this would cause a small perf loss for most
users - to the same level as it was before 5.6 -, but it would eliminate the
BC break when migrating to 5.6, and it would allow us to take our time to
have time to properly figure out the introduction of this feature including
the interaction with the custom session handlers).I would vote for 3,
Depending on the context, I'd vote for multiple of those options ...
Short-term fix for 5.6 is obviously to revert the commit. I was vocal
mostly because of principle at the time, but this issue is an example
why.
A long-term "fix" for 5.6 would be what I've done in userland recently
- continue to call SessionHandler::write() at all times, but inside
of it calltouch()instead offwrite()if there's no new data. That
way custom session handlers wouldn't be affected, but the default one
would still provide a performance boost. This is of course if we do
want to keep the feature (I do), but considering that it was voted in
a slightly different form ... I'm just being egoistic with this
suggestion.
For PHP7 though, I definately want a redesign of the session APIs and
it's on my TODO list for when I have some spare time to work on it.
Cheers,
Andrey.
Hi Andrey,
Short-term fix for 5.6 is obviously to revert the commit. I was vocal
mostly because of principle at the time, but this issue is an example
why.
Did you? I don't think so.
The reason that I didn't provide that user land "update" API is your
objection. If it is included, user had control even in this case.
A long-term "fix" for 5.6 would be what I've done in userland recently
- continue to call SessionHandler::write() at all times, but inside
of it calltouch()instead offwrite()if there's no new data. That
way custom session handlers wouldn't be affected, but the default one
would still provide a performance boost. This is of course if we do
want to keep the feature (I do), but considering that it was voted in
a slightly different form ... I'm just being egoistic with this
suggestion.
No. Providing userland update API just like C module save
handler is the way to go as I implemented at first.
Besides, the method that you described will not solve the issue reported
by the bug. There is no point that provides different API for C and PHP
written save handlers, IMO.
For PHP7 though, I definately want a redesign of the session APIs and
it's on my TODO list for when I have some spare time to work on it.
I think you have misunderstanding for session management.
One example is that you don't understand nature of browser and server
communication. It's asynchronous by it's nature, yet you insisted
syncronous operation. Without this understanding, session cannot
be managed correctly/precisely.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Yasuo,
Hi Andrey,
Short-term fix for 5.6 is obviously to revert the commit. I was vocal
mostly because of principle at the time, but this issue is an example
why.Did you? I don't think so.
You think you know better what my motivation was? (don't answer)
The reason that I didn't provide that user land "update" API is your
objection. If it is included, user had control even in this case.
But it would still be a BC break.
Also, the commit we're talking about was made way before I objected
anything, don't throw that one on me.
A long-term "fix" for 5.6 would be what I've done in userland recently
- continue to call SessionHandler::write() at all times, but inside
of it calltouch()instead offwrite()if there's no new data. That
way custom session handlers wouldn't be affected, but the default one
would still provide a performance boost. This is of course if we do
want to keep the feature (I do), but considering that it was voted in
a slightly different form ... I'm just being egoistic with this
suggestion.No. Providing userland update API just like C module save
handler is the way to go as I implemented at first.Besides, the method that you described will not solve the issue reported
by the bug. There is no point that provides different API for C and PHP
written save handlers, IMO.
You're still thinking in the context of your RFC and the patch that
was never merged.
The issue at hand is that write() is not called and the method that I
described clearly solves that issue. Whether you think that's "the way
to go" is another story.
For PHP7 though, I definately want a redesign of the session APIs and
it's on my TODO list for when I have some spare time to work on it.I think you have misunderstanding for session management.
One example is that you don't understand nature of browser and server
communication. It's asynchronous by it's nature, yet you insisted
syncronous operation. Without this understanding, session cannot
be managed correctly/precisely.
I am very well aware of how HTTP works, thank you.
Due to lack of context and for the sake of remaining on good terms,
I'll refrain myself from replying in a more elaborate manner.
Cheers,
Andrey.
On 5 November 2014 11:22, Leigh <leight@gmail.com
mailto:leight@gmail.com> wrote:On 4 November 2014 18:14, Rowan Collins <rowan.collins@gmail.com <mailto:rowan.collins@gmail.com>> wrote: > > If anything, I think I would expect the keys of splatted arrays to be discarded, since it seems most natural to use this in a list context, but I can imagine always having to check in the manual. I agree on this point. Duplicate keys should not overwrite each other. [...$foo, ...$bar] should literally unpack the values as if they were comma delimited and discard all key information.Here's how I picture this, which is the rationale for my view on how
it should behave:$foo = ['a' => 1, 'b' => 2, 'c' => 3];
$bar = ['c' => 4, 'd' => 5, 'e' => 6, ...$foo];
// is identical to writing
$bar = ['a' => 1, 'b' => 2, 'c' => 3, 'c' => 4, 'd' => 5, 'e' => 6];
Actually, it would be identical to writing:
$bar = ['c' => 4, 'd' => 5, 'e' => 6, 'a' => 1, 'b' => 2, 'c' => 3];
To keep the keys in alphabetical order and have 'c' => 4 in the result,
you would need to write:
$bar = [...$foo, 'c' => 4, 'd' => 5, 'e' => 6];
In other words, in that scenario it's basically syntactic sugar to
avoid having to write out the "body" of the array twice, and would
behave identically as if you had done this.
There is no need to write anything twice, the + operator gives a very
similar result, although it prefers the first of a set of duplicate
keys, not the last:
$foo = ['a' => 1, 'b' => 2, 'c' => 3];
$bar = $foo + ['c' => 4, 'd' => 5, 'e' => 6];
// keys in alphabetical order, keeps 'c' => 3
// http://3v4l.org/Vri8j
$foo = ['a' => 1, 'b' => 2, 'c' => 3];
|$bar = ['c' => 4, 'd' => 5, 'e' => 6] + $foo; |
// keeps 'c' => 4, but keys now not in order
http://3v4l.org/lDPou
Alternatively, array_merge() is in every way identical to what you
propose, and still requires no duplication, just a few extra keystrokes
to write the function call:
$foo = ['a' => 1, 'b' => 2, 'c' => 3];
$bar = array_merge($foo, |['c' => 4, 'd' => 5, 'e' => 6]);|
--
Rowan Collins
[IMSoP]
I always wanted to have an analog XPath to access the array elements.
Something like:
<?php
$array = ['x' => ['p' => ['a' => ['t' => ['h' => 'value']]]]];
$xpath = ['x', 'p', 'a', 't', 'h'];
$value = $array[...$xpath];
var_dump($value); // string(5) "value"
?>
This is certainly a topic for another RFC, but this functionality will be
useful in PHP.
I always wanted to have an analog XPath to access the array elements.
Something like:<?php
$array = ['x' => ['p' => ['a' => ['t' => ['h' => 'value']]]]];
$xpath = ['x', 'p', 'a', 't', 'h'];
$value = $array[...$xpath];var_dump($value); // string(5) "value"
?>
This is certainly a topic for another RFC, but this functionality will be
useful in PHP.
That would be quite confusing, we don’t allow $array[‘x’, ‘p’, ‘a’, ’t’, ‘h’] just now.
--
Andrea Faulds
http://ajf.me/
That would be quite confusing, we don’t allow $array[‘x’, ‘p’, ‘a’, ’t’,
‘h’] just now.
Andrea Faulds
Yes, I know, but it would be convenient, maybe someone will offer the best
option syntax.
I always wanted to have an analog XPath to access the array elements.
Something like:
<?php
$array = ['x' => ['p' => ['a' => ['t' => ['h' => 'value']]]]];
$xpath = ['x', 'p', 'a', 't', 'h'];
$value = $array[...$xpath];
var_dump($value); // string(5) "value"
?>
What would happen if some key from $xpath is undefined on the
multidimensional $array?
What would happen if some key from $xpath is undefined on the
multidimensional
$array?
Notice: Undefined index...
Return NULL.
I like the idea, especially list($a, $b, ...$c) = ...
Looks like Prolog's [A, B | C] = ..., unfortunately it won't provide the
same semantic and performance.
Implementation needs to be reviewed, but I think it must not affect
existing opcodes.
Thanks. Dmitry.
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC, either
people will like it or they won't, there isn't a lot more to say here than
what's in the RFC so please have a read.https://wiki.php.net/rfc/additional-splat-usage
Thanks, Chris
Hi Dmitry
I like the idea, especially list($a, $b, ...$c) = ...
Looks like Prolog's [A, B | C] = ..., unfortunately it won't provide the
same semantic and performance.
Implementation needs to be reviewed, but I think it must not affect
existing opcodes.
The list() usage is intentionally put outside the scope of this RFC,
because what would be the correct behaviour is not quite so obvious - as
Niki put it when we were discussing this initially, array_merge uses
iterator-like behaviour, but list() uses ArrayAccess, it relies on specific
indices being present, so it's not obvious what should be done with
elements that are not within the bound of what list() would attempt to
fetch. I am planning to put together another proposal for this, but it's
still at the R&D stage - if people want to discuss it on-list at this stage
I suggest starting a separate thread (I wasn't planning to until I have
clarified my own ideas).
I do need to explore the impact to to opcodes and opcache, and was planning
to come to you to discuss this shortly.
Thanks, Chris
Thanks. Dmitry.
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC, either
people will like it or they won't, there isn't a lot more to say here than
what's in the RFC so please have a read.https://wiki.php.net/rfc/additional-splat-usage
Thanks, Chris