Basically, the current function library is moved to the legacy
namespace. The default setting is import the functions of the legacy
namespace into the root namespace for BC. But with that setting
turned off all the existing functions go away to be replaced with a
designed API, instead of a
While I think having a legacy implementation is definitely worth while, it
needs to be in core. So PHP6 would introduce the new syntax, and include the
legacy functionality in as close to 100% backwards compatible way as
possible. From there, we'd only remove the legacy functionality from core
I missed the discussion on this one, the RFC examples are very simple. Does
it support aliasing array indices?
For example: (use $matches[0] as $name)
On Jul 18, 2012 3:55 PM, Laruence larue...@php.net wrote:
Hi:
Call for voting for Allow use T_AS in closure use statement,
What about expanding the syntax instead of introducing new reserved words.
use A\B {
Class1,
Class2
}
On Aug 2, 2012 5:44 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
Hi,
I don't know how to tag this kind of discussion (because it's not RFC
request).
I've interested in runkit PECL extension and think that it should be part
of the PHP core runtime.
I do think that the implementation
Sandboxing: Complicated by the fact that it only works in a threaded
build, can't transfer all types (e.g. resource, complex objects), and
can't run concurrently. Until/unless these problems can be
meaningfully solved, I wouldn't consider it a functional
implementation.
To me the thread
is disabled. I'm
wondering in how many other places this could occur.
The obvious solution is to be more careful and check return values,
but a FATAL would also have prevented execution continuing.
Thanks,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Because there isn't anything actually wrong.
A fatal error is reserved for things we cannot recover from, but a
disabled function is easily recoverable.
I don't see how it is any more recoverable than the function/class not
existing at all. How much code do you know of that checks for the
Hi
The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks, it
Basically we shouldn't break any interfaces that are user-facing but
we are free to change things internally as much as we want as long as the
external interface is honored.
So how do you actually go about adding a feature that requires an
interface change?
Take for example the SessionHandler
I missed the encoding parameter. While it's still possible to add that
to a static-only class, that would be more cumbersome and less correct
than instantiation (since the encoding is state, technically). My
apologies. Carry on ;-)
It's probably already been covered, but I don't like the fact
Call it str_escape(string, flags optional, encoding optional) and be done
with it.
Keeping it simple definitely preferred
1) do we even need encoding or is UTF8 just fine
Definitely need encoding.
mbstring supports quite a lot
http://php.net/manual/en/mbstring.supported-encodings.php
I
My whole point here is identifying WHAT needs 'escaping'. You can't simply
'escape' the output stream, you still want html tags to get out?
This problem is specific to YOU, because (as far as I understood your
previous post) you decided to store big chunks of HTML in your data
store. It is not
What concerns me with the current implementation is that it leaks many
implementation details, in particular the fact that the accessors are
implemented as *real* __getXYZ methods and automatic implementations
also use *real* $__XYZ properties.
Further to this, take the following example.
RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
public $property {
set { $this-property = ($this-property*2)+$value }
get;
}
How do I reference the property being set from within the function? The way
I have done it in the example will cause recursion? How can I
On 10 October 2012 01:16, Johannes Schlüter johan...@schlueters.de wrote:
Up until now reflection is leaky and is telling the truth. We should
either keep that or completely clean up reflection.
Reflection should always tell the truth, or there is no point in it.
On 10 October 2012 04:28,
) and the
accessor would take over again.
Also confusing. (Think of the users!)
I think Leigh brings up some important flaws to in the current RFC. What
Leigh is asking for does not appear to be possible, and in my opinion, it
should be.
I'm really not quite clear on what Leigh was going
On 10 October 2012 08:46, Bernhard Schussek bschus...@gmail.com wrote:
Second, I'd like to throw in the idea of array accessors. I mentioned
this before, but did not get any response.
public $Addresses {
offsetSet($offset, $value) { ... }
offsetGet() { ... }
On 11 October 2012 12:46, Cal c...@icical.net wrote:
For me the best solution would be a new keyword, equivalent to a var
without write access from outside the class:
New keywords should not (will not) be introduced trivially, they can
cause massive headaches with backwards compatibility
Check the zend_error function in zend.c
http://lxr.php.net/xref/PHP_5_4/Zend/zend.c#1106
On 19 October 2012 14:46, Adi Mutu adi_mut...@yahoo.com wrote:
Hello,
Can anybody show me, where in the core the user error handler is called? The
mechanism of how it's called...
Thanks,
A.
--
Hi,
We put ext/mysql in a (security) bug fix maintenance mode only
years ago. Too many ignore those attempts to get rid of ext/mysql.
Maybe it's time to put it into full non-maintenance mode then?
I believe MySQL is one of the on-by-default extensions when you
compile PHP blindly (as I'm sure
Hi
On 13 November 2012 00:29, Rasmus Lerdorf ras...@lerdorf.com wrote:
That is simply not true. If you download PHP and do ./configure make
install you do not get MySQL support. You have to explicitly specify
that you want it.
My apologies then. I actually checked a ./configure output, and
On 4 December 2012 09:04, Lester Caine les...@lsces.co.uk wrote:
April 1, 2013
The date is somewhat suspicious ;)
Both str_replace and preg_replace already support some array based
replacements, I think adding more options to these functions specifically
would just lead to confusion.
What you're proposing can already be achieved quite easily with
preg_replace_callback and passing your array/options into the
Hi Dmitry
On 18 December 2012 11:37, Dmitry Stogov dmi...@zend.com wrote:
The new solution may significantly change implementation and even behavior
in some cases (e.g https://bugs.php.net/bug.php?id=62069).
If you have any idea, do you know what the implications of your changes are
on APC?
On 18 December 2012 13:24, Stefan Neufeind neufe...@php.net wrote:
Since we already have functionality for replacing with arrays in place,
I wondered if giving it one string to replace and then an array to
choose the replacement from (rotating) would be an option. Currently
that's unsupported
In my opinion (for however little it matters), code is code, and comments
are comments. They should not mingle.
Annotations, if implemented, should have their own syntax that makes them
code, not an abstraction of a comment.
I already dislike the fact that getDocComment is there - in my opinion
On 28 January 2013 14:49, Alan Knowles a...@roojs.com wrote:
I was trying to vote against, for what it's worth.
It's a major bc break with no obvious value, and what appears to be 7 days
given to vote when every one is busy discussing a new property syntax.
See other thread by Zeev :)
On
On 30 July 2012 18:31, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
https://wiki.php.net/rfc/incompat_ctx
An RFC for deprecating and removing $this from incompatible context.
Comments are welcome.
Gustavo, my apologies, the ORIGINAL mail did say a little more about it.
On 29 January 2013 11:23, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev,
First off, very nice job on the RFC. I definitely like what's happening
here.
As far as delaying 5.5, I have mixed feelings. I think we should definitely
consider the delay, but only in a time-boxed format. So if we
There is a PECL extension that already does something similar. You may want
to take a look at that.
http://pecl.php.net/package/proctitle
On 7 February 2013 05:40, Keyur Govande keyurgova...@gmail.com wrote:
Hello,
I've created a new RFC to improve support for setting a CLI process' title
On 7 February 2013 12:22, Alexey Zakhlestin indey...@gmail.com wrote:
On 07.02.2013, at 13:54, Leigh lei...@gmail.com wrote:
There is a PECL extension that already does something similar. You may
want
to take a look at that.
http://pecl.php.net/package/proctitle
Did you read RFC
I can understand that If you haven't tried to write a tool like
capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see
much value in implementing such things.
Your RFC doesn't go to great lengths to explain the value either. Pretend
the reader has no experience with any of
On 19 February 2013 16:46, Marcello Duarte mdua...@inviqa.com wrote:
I find that more and more my developers have to learn ruby just to be able
to work in our projects. We are one of the largest PHP shops in Europe and
even the proprietary tools we are writing for DevOps stuff we are writing
On 21 February 2013 07:08, Tjerk Anne Meesters datib...@php.net wrote:
Hi,
I found myself wanting a feature of array_filter() with which I can perform
filtering based on the array key instead of the value.
With the operative word here being *instead*, keeping in line with the
numerous other
On Mar 2, 2013 12:26 AM, Ferenc Kovacs tyr...@gmail.com wrote:
only people with people with php.net accounts or with manually granted
voting wiki group membership can vote.
I have no idea who or on what ground can hand out voting ground
membership,
last time when somebody requested that
On 6 March 2013 12:48, Max Romanovsky max.romanov...@gmail.com wrote:
Dear PHP Community,
I'd like to propose several changes to PHP core:
1. Allow re-throwing exceptions without losing original stack trace,
like in other technologies:
try {/*...*/} catch(Exception $e) { throw; }
2. Introduce base class for all PHP classes. E.g. Object. It would
help
in type hinting and allow to add new common methods without any magic.
Introduce a type-hint “object” would be better I think. It would replace
is_object call.
I wonder how much BC breakage there would be
On 5 March 2013 15:13, Paul Reinheimer preinhei...@gmail.com wrote:
How many servers do you deploy code to
Does this need a dev/test/prod split? I think this question should
specifically address production servers only.
(I'm not sure how this answer steers PHP as a language, but it might be
I find this somewhat conflicting.
If it's experimental, and will likely be removed because nobody will
maintain it, why is anything being added to it at all?
This simply makes it easier for people to build a dependance on a feature
that will ultimately cease to exist in the next major version.
I think creating easy processable output from phpinfo() is a good idea in
theory, but as Madara says, I'm also not sure about any other production
uses for this aside from the issue at hand with curlwrappers.
Are there many use cases except for the config options that this would be
useful for?
I found that the memory leak is actually related to APC,
even with the latest version of PHP (5.3.25) and latest version of APC
(3.1.13),
Just to make sure it's extra clear, APC 3.1.13 is a beta release. 3.1.14
was released and un-released because of memory leak issues.
If you're still
On 18 June 2013 00:20, Sherif Ramadan theanomaly...@gmail.com wrote:
I'm starting up a thread for discussion on Pull Request 287
https://github.com/php/php-src/pull/287 (allowing array keys to be passed
to the callback function of array_filter through a third optional boolean
argument).
Why
On 18 June 2013 18:24, Sherif Ramadan theanomaly...@gmail.com wrote:
I suppose the order of the elements should remain $value, $key in the event
of ARRAY_FILTER_KEY | ARRAY_FILTER_VAL.
This is also the order already used for the callback of array_walk, so I
think it makes sense to have some
I'm disappointed $a+$a doesn't work as expected :(
On 20 July 2013 06:08, Sherif Ramadan theanomaly...@gmail.com wrote:
Sara,
On Sat, Jul 20, 2013 at 12:44 AM, Sara Golemon poll...@php.net wrote:
What's undefined isn't the relationship between preinc/postinc and add.
What's
On 7 August 2013 11:18, Yasuo Ohgaki yohg...@ohgaki.net wrote:
A user requested that crypt() should raise error without 2nd(slat)
parameter.
https://bugs.php.net/bug.php?id=55036
crypt() without salt generates extremely weak password hash.
The docs seem to indicate that some
On 7 August 2013 20:47, Sean Cannella se...@fb.com wrote:
https://wiki.php.net/rfc/constructor-promotion
What do you all think?
I'm not sure what problem this is really trying to solve, the boilerplate
code you mention is very explicit and it is very clear to the reader what
is being done.
Sorry I failed at reply to all.
On 8 August 2013 11:38, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Leigh,
On Thu, Aug 8, 2013 at 7:23 PM, Leigh lei...@gmail.com wrote:
Are you keeping it as optional for 5.6 and not the default? If you're
making it default don't we need to vote on BC breaks
On 8 August 2013 12:05, Yasuo Ohgaki yohg...@ohgaki.net wrote:
What's the point of having old serialzers that is bonded to
register_globals?
This kind of change should have done when 5.4.0 was released, IMO.
Because somebodies code will depend on functionality not changing, and we
shouldn't
On 8 August 2013 14:12, Matthieu Napoli matth...@mnapoli.fr wrote:
class MyClass {
public $foo;
protected $bar;
public function __construct($this-foo, $this-bar, $baz) {
// $this-foo and $this-bar are now set
This actually feels _way_ more intuitive to me, it feels like you are
On 8 August 2013 23:31, Yasuo Ohgaki yohg...@ohgaki.net wrote:
How php_serialize would cause BC issues for PHP users?
Not everyone uses PHP in the way you would expect. Just how many sites out
there do you think use PHPs session functionality? I'd go for hundreds of
millions, and that's a
On Aug 8, 2013 9:31 PM, Daniel Bingham daniel.bing...@ellislab.com
wrote:
Hey Igor,
I love the RFC, but how about:
use bar\baz() as baz;
As an alternative to use function. Still new syntax, but a little less
wordy.
The parenthesis add the feeling that it should be evaluated imho, I.e.
On 10 August 2013 04:45, Yasuo Ohgaki yohg...@ohgaki.net wrote:
This patch removes unneeded session writes. i.e. session data
has not changed, just skip write and improve performance.
Although it is safe to remove unneeded writes, if many of us
want ini setting for enable/disable write
On 10 August 2013 10:45, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Leigh,
On Sat, Aug 10, 2013 at 6:26 PM, Leigh lei...@gmail.com wrote:
How does this affect GC of sessions? If a session is not written for 30
minutes, but the user is active, is there a potential for their session to
be GC
On 10 August 2013 10:54, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Leigh,
On Sat, Aug 10, 2013 at 6:48 PM, Leigh lei...@gmail.com wrote:
What is the performance difference if you just touch the files instead
of writing them? (i.e. update mtime)
It will be faster for sure for files
On 22 August 2013 13:39, Sebastian Krebs krebs@gmail.com wrote:
Tbh I don't get the real problem with the _current_ behaviour. Who need the
entropy, can set it as second parameter and I am not sure, if it is wise to
use uniqid() for _security purposes_.
It's absolutely not wise to use it
Session Handler enhancement (create_sid)
I would like to propose a new feature to the current custom session
handling; the ability for a user defined function to be used when
generating the session id.
The reasons are as follows:
The Session Handler doesn't know when session_regenerate_id is
On Aug 30, 2013 1:31 PM, Anthony Ferrara ircmax...@gmail.com wrote:
For constants and function calls, the benchmark shows that the difference
is well within the margin of error for the test (considering variances of
5% to 10% were common in my running of the tests).
So hopefully this will
On 30 August 2013 20:58, Marc Bennewitz p...@marc-bennewitz.de wrote:
what is the best algorithm?
Well that is platform dependant. For example on FreeBSD you'd hope
/dev/random was used (which does not block like linux, and generates a
crypto quality pseudo-random stream)
Point being, best is
On Sep 7, 2013 4:37 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
Any updates for Escaping RFC for PHP Core?
https://wiki.php.net/rfc/escaper
I think this is must have item for next PHP.
--
Yasuo Ohgaki
yohg...@ohgaki.net
Looks like the rfc author was unable to implement it himself
On 11 September 2013 15:39, Andrea Faulds a...@ajf.me wrote:
I'm thinking, in particular, of something à la Reddit.com or Hacker News,
by which I mean has hierarchical replies with an upvote/downvote system.
So why don't you just use reddit or hacker news instead of trying to create
yet
On 11 September 2013 17:00, Paul Taulborg njag...@gmail.com wrote:
Clearly it is broken, which is why this topic and Wake Up are the most
active this group has seen in the last year, in only a few hours of time.
I'm going to generalise a lot, and there are obviously exceptions, however
most
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
From the manual: If multiple parameters are supplied then isset() will
return TRUE only if all of the parameters are set. Evaluation goes from
left to right and
On 18 September 2013 12:15, Igor Wiedler i...@wiedler.ch wrote:
for is_* functions, this could easily be done with a higher-order every
function. You pass a predicate and an array of values. It returns a boolean.
Example:
if (!every('is_int', $numbers)) {
throw new
with an
and not an ||.
isset() already operates that way, keeping is_ and implementing it
as originally proposed by Leigh would, at least, be consistent.
Indeed, my proposal was to mimic short circuiting as isset() does it,
evaluating LTR and returning false at the earliest opportunity.
--
PHP
On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote:
At least, from a technical point, evaluating LTR would require to change the
engine
(would be some more complex change as it would require to switch between
contexts
and being able to execute the ZEND_SEND_VAL opcodes one by
On Sep 24, 2013 3:43 AM, Laruence larue...@php.net wrote:
I don't think this is language concerning issue.
it could be done in user script..
thanks
I agree entirely with Laurence (and others). This shouldn't be a core
feature. It's not one size fits all.
There's several scenarios where a
On 26 September 2013 11:32, Tjerk Meesters tjerk.meest...@gmail.com wrote:
On Thu, Sep 26, 2013 at 6:19 PM, Leigh lei...@gmail.com wrote:
There's several scenarios where a users IP changes and you don't want to
drop their session. (That doesn't mean it should simply have an option to
disable
On 27 September 2013 11:39, Peter Lind peter.e.l...@gmail.com wrote:
On 27 September 2013 12:12, Leigh lei...@gmail.com wrote:
So on a successful session hijack (correct SID, new IP) the attacker
gets a new SID and keeps the valid session while the legitimate user
gets kicked out
On Sep 28, 2013 10:39 AM, Peter Lind peter.e.l...@gmail.com wrote:
So you're stuck with two choices: accept that PHP security is lax and
that as a result a lot of code will have many attack vectors, or try to
change the language itself for the better. The third option of educate is
a mirage.
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
I propose to phase out $_GET and name it $_QUERY and
I propose to phase out $_POST and name it $_FORM
I have to say I'm against this aspect of the proposal. While the names
may not be 100% accurate, _most_ people are used to their
an RFC, as it does not break any existing
expected behaviour.
I'd like to hear the lists opinion on introducing these new formatting options.
Provisional PR: https://github.com/php/php-src/pull/812
Cheers,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
On 9 September 2014 21:16, Andrea Faulds a...@ajf.me wrote:
Why is there no big/little-endian signed long long?
Because there is no big/little-endian signed long :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 9 September 2014 21:16, Andrea Faulds a...@ajf.me wrote:
Why is there no big/little-endian signed long long?
I suppose you could argue that these count
i - signed integer (machine dependent size and byte order)
I - unsigned integer (machine dependent size and byte order)
However they
On 9 September 2014 23:08, Nikita Popov nikita@gmail.com wrote:
Hi internals!
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:
https://wiki.php.net/rfc/remove_alternative_php_tags
It removes % and script language=php and the other
On Sep 9, 2014 7:36 PM, Leigh lei...@gmail.com wrote:
Hi Internals,
I would like to propose giving pack() and unpack() 64 bit format
codes, mimicking the current behaviour of 32 bit format codes.
Pack and unpack are obviously functions inspired by Perl, which has
the 64 bit format codes 'q
they all make sense for PHP.
Please review and discuss the proposed changes and see how you feel about them,
Thanks,
Leigh.
P.S @andrea your comments from the original thread are addressed in the RFC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On 16 September 2014 16:14, Anatol Belski anatol@belski.net wrote:
I made a build from the current revision
http://windows.php.net/downloads/snaps/ostc/master-f469dc74/ so anyone
curious can easy snuffle :) It contains all the currently ported exts +
debug symbols, no PGO. Please catch up
On 16 September 2014 17:25, Leigh lei...@gmail.com wrote:
What's the difference between the build you put up, and the builds in
http://windows.php.net/downloads/snaps/master/ ?
Since I am home now and can test. I'll answer my own question - builds
in snaps/master are still 32 bit builds
On 17 September 2014 15:52, Christian Stoller stol...@leonex.de wrote:
Hello all,
I hope the subject is not misleading. Please look at the following code:
?php
class A { }
class B extends A { }
interface C {
function foo(A $a);
}
class D implements C {
On 12 September 2014 22:30, Leigh lei...@gmail.com wrote:
Hi list,
I would like to propose the addition of format codes for pack() and
unpack() to work with 64 bit integers.
https://wiki.php.net/rfc/pack_unpack_64bit_formats
Dear list,
If there are no outstanding issues in one weeks time
segfaults, I am working on it)
Thanks for reading.
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 19 September 2014 23:08, Rowan Collins rowan.coll...@gmail.com wrote:
It's worth noting that both Smarty and Twig implement a similar mechanism in
their respective foreach loop syntax.
Smarty spells it {foreachelse}
http://www.smarty.net/docs/en/language.function.foreach.tpl
Twig spells
to that for now, and I'm more than happy to create a thread for
the other scenario later on, and we can discuss the python style there
instead.
Cheers,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 20 September 2014 00:15, Andrea Faulds a...@ajf.me wrote:
Why not? Python uses “else”, and before creating this RFC you initially
wanted to use “else”.
Then I realised it was folly. Documented in the RFC why else is a bad choice.
I’m bringing it up because I think we’re only going to end
in the language should be recent and relevant. It's difficult
to police legacy contributors, but if they are not interested enough
to type a few lines. the answer is clear.
Say no to non-contributors.
Cheers,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On 20 September 2014 01:02, Rowan Collins rowan.coll...@gmail.com wrote:
It seems like there are actually quite a number of special blocks you
*could* define, such as:
a) When the body is executed zero times (proposed or block)
b) When the body is executed exactly once (in a do...while loop,
On 20 September 2014 15:37, Johannes Schlüter johan...@schlueters.de wrote:
It is unclear what a no means. Might be a related to the patch the
design, a misunderstanding or due to a critical issue ... in the end a
vote creates losers with little feedback.
But well, I'm saying this from day
Updated RFC to include information about templating engines often
emulating this behaviour for ease-of-use.
Changed target version to be specifically PHP 7, so that it's clear
that changes target the AST based compiler. (If there's ever a 5.next,
we can consider that at the time)
--
PHP
On 20 September 2014 20:47, Sara Golemon p...@golemon.com wrote:
I like the general idea, but rather than explicitly focusing on the 'or'
keyword, how about just giving all loop constructs (do/while/for/foreach) a
return value? I'd suggest an integer return value indicating the number of
On 20 September 2014 23:06, Leigh lei...@gmail.com wrote:
Lots to think about here, if it's at all viable this will need it's
own separate RFC, it's a much more invasive change, but definitely a
great idea.
NikiC and Bob have convinced me to carry on with the original
proposal, and bring up
Completed my proof of concept patch:
https://github.com/lt/php-src/compare/loop-or
This gives for, foreach, and while loops an additional or {} block
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 22 September 2014 08:17, Christian Stoller stol...@leonex.de wrote:
I like this proposal as I am using this feature in Twig very often.
But I would really prefer using else instead of or, because it
is already common in the mentioned projects.
Maybe you could reconsider if it is really not
On 22 September 2014 08:49, Xinchen Hui larue...@php.net wrote:
Maybe I am too conservative. I don't like this idea. :
And I DO THINK, we should try to stop brings lots of new things into PHP7.
I am worring whether it can be release in the next year
Can you give some more
On 22 September 2014 11:10, Andrea Faulds a...@ajf.me wrote:
If we’re going to reopen or restart, I’d prefer to completely restart it than
to just reopen it. A clean slate.
Most of the issues I saw raised were related to one half of the RFC,
the shifts or the casts, perhaps you'd make better
On 23 September 2014 09:51, Michael Wallner m...@php.net wrote:
Yes, it was removed intentionally (quite a long time ago), like using
resources as array keys, to avoid hard-to-trace bugs for the user. At
least that's the reasoning I can remember.
He doesn't want to add the object as a key, he
On 23 September 2014 10:35, Michael Wallner m...@php.net wrote:
On 2014-09-23 11:15, Leigh wrote:
He doesn't want to add the object as a key, he wants to invoke __toString().
Did I write that?
No, you didn't, sorry.
I just didn't see how an object with an explicit method to convert
On 23 September 2014 12:22, Paul Dragoonis dragoo...@gmail.com wrote:
Write an extension for it then, also share your benchmarks :)
Why go to all that trouble, 10 seconds on Google and we have:
https://github.com/msgpack/msgpack-php
--
PHP Internals - PHP Runtime Development Mailing List
To
On 23 September 2014 17:36, Park Framework park.framew...@gmail.com wrote:
If you do not update in PHP 7 serialization method, it will never be
updated, the default serialization in PHP 7 will be slow.
To maintain backward compatibility, can implement support method calls
on primitive types,
On 25 September 2014 08:40, Lester Caine les...@lsces.co.uk wrote:
Why would we need to build a hash of this object? It would provide
nothing of use since we have a clean object key. Some people seem to
think a hash will provide an indication that an object has changed, but
in reality that is
1 - 100 of 330 matches
Mail list logo
