Am 25.02.2013, 20:03 Uhr, schrieb Terry Ellison :
On 03/02/13 15:27, Hans-Juergen Petrich
wrote:
In this
example (using php-5.4.11 on Linux) the memory will grow non-stop:
for ( $fp = fopen('/dev/urandom', 'rb'); true;) {
eval ('$ano_fnc = func
On Feb 26, 2013, at 10:00 AM, Benjamin Eberlei wrote:
> This is indeed not possible, because strings are not class context
> independent, you can pass them to anywhere. A string just doesn't know what
> namespace it belongs to and this does not make sense without providing more
> context in c
Hi everyone,
(I got "hooked off" this discussion, so I have tried to keep up by reading the
digest... This makes it impossible for me to correctly interleave my comments,
so I'll just "top post" or whatever the term is) (I'm sure this has been
mentioned before but a forum would be so much more
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski wrote:
> Based on the overwhelming response, the vote is now open J
>
>
>
> https://wiki.php.net/rfc/optimizerplus
>
>
>
> Voting ends March 7th.
ok, given the total lack of answers, mistakes and misleading wording
in the RFC and lack of releases in P
On Thu, Feb 28, 2013 at 2:56 AM, Ben Ramsey wrote:
> Sorry. I got sick for a few weeks, and this fell to the bottom of my
> priorities list.
>
> I'm not sure what the next steps are. This was approved by a majority vote.
> What do I need to do now to get it into 5.5?
Please kill that alias. It is
Sorry. I got sick for a few weeks, and this fell to the bottom of my
priorities list.
I'm not sure what the next steps are. This was approved by a majority vote.
What do I need to do now to get it into 5.5?
Thanks,
Ben
On Wed, Feb 27, 2013 at 6:51 AM, Pierre du Plessis
wrote:
>
> On 12 Januar
Am 27.2.2013 um 22:01 schrieb Ferenc Kovacs :
> I'm not sure that the current options covering all cases.
> How should one vote if he/she thinks that this should go into the next
> release after 5.5?
> Currently their only option would be to vote for no, which isn't doesn't
> really the same thing.
On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf wrote:
> On 02/27/2013 01:01 PM, Ferenc Kovacs wrote:
> This is where I think we have a big disconnect. This yearly release plan
> is meaningless for most people because there is no way the current
> opcode cache situation can keep up with that. PH
On Wed, Feb 27, 2013 at 4:45 PM, Nikita Popov wrote:
>>
> Not sure I understand the question. O+ is compatible with 5.5, so you can
> use that if you like. Just install it as an ext. Just like you would have
> done with APC.
>
> Nikita
More than ANY other language feature, having an integrated op
On Wed, Feb 27, 2013 at 10:43 PM, Adam Jon Richardson wrote:
> On Wed, Feb 27, 2013 at 4:40 PM, Adam Jon Richardson
> wrote:
> > On Wed, Feb 27, 2013 at 4:30 PM, Nikita Popov
> wrote:
> >> On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf
> wrote:
> >>
> >> All these are really great arguments f
On Wed, Feb 27, 2013 at 4:40 PM, Adam Jon Richardson wrote:
> On Wed, Feb 27, 2013 at 4:30 PM, Nikita Popov wrote:
>> On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf wrote:
>>
>> All these are really great arguments for including O+ ... in PHP 5.6. O+ is
>> already compatible with PHP 5.5 and a
On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf wrote:
> On 02/27/2013 01:01 PM, Ferenc Kovacs wrote:
>
> > ps: I really love what you guys did with opensourcing it, but I just
> think
> > that it is too late for 5.5 and I think that it is better to stick to the
> > original roadmap, instead of
On Wed, Feb 27, 2013 at 4:30 PM, Nikita Popov wrote:
> On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf wrote:
>
> All these are really great arguments for including O+ ... in PHP 5.6. O+ is
> already compatible with PHP 5.5 and as we're just days away from feature
> freeze this will stay so til
On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf wrote:
> On 02/27/2013 01:01 PM, Ferenc Kovacs wrote:
>
> > ps: I really love what you guys did with opensourcing it, but I just
> think
> > that it is too late for 5.5 and I think that it is better to stick to the
> > original roadmap, instead of
On 02/27/2013 01:01 PM, Ferenc Kovacs wrote:
> ps: I really love what you guys did with opensourcing it, but I just think
> that it is too late for 5.5 and I think that it is better to stick to the
> original roadmap, instead of having a 6 months delay just to ship the O+ in
> the core 6months ear
On Wed, Feb 27, 2013 at 9:06 PM, Stas Malyshev wrote:
> Hi!
>
> > May someone merge this PR (#290) as there are no arguments against it?
>
> I just outlined arguments against it in my last emails. If your email is
> not working properly and you miss some emails please check the list
> archives.
>
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski wrote:
> Based on the overwhelming response, the vote is now open J
>
>
>
> https://wiki.php.net/rfc/optimizerplus
>
>
>
> Voting ends March 7th.
>
>
>
> Zeev
>
Hi Zeev,
I'm not sure that the current options covering all cases.
How should one vote i
Hi!
> May someone merge this PR (#290) as there are no arguments against it?
I just outlined arguments against it in my last emails. If your email is
not working properly and you miss some emails please check the list
archives.
> Or do I have to wait a little bit? (How long?)
In my personal opi
On Wed, Feb 27, 2013 at 8:31 PM, Rasmus Lerdorf wrote:
> That's not true, there will be some. When bundling it with 5.5 we can
> remove the ifdefs and extra code only needed for prior versions, for
> example, and we should rename the ini names and such.
I called that cleanup not integration, but
On 02/27/2013 11:26 AM, Pierre Joye wrote:
On Wed, Feb 27, 2013 at 8:05 PM, Christopher Jones
wrote:
Are there any updated guesstimates at how long integration into PHP 5.5 will
take?
There will be no integration, but the idea is to bundle it, as it is.
The actual integration is a large ta
On 27 בפבר 2013, at 18:58, Anthony Ferrara wrote:
> Zeev et al,
>
> I just want to put my justification for the "only if no delay" vote. I voted
> that way because we're already at a significant delay. If this vote was a
> month ago when O+ was suggested first, I would definitely have voted for
On 02/27/2013 11:26 AM, Pierre Joye wrote:
> On Wed, Feb 27, 2013 at 8:05 PM, Christopher Jones
> wrote:
>
>> Are there any updated guesstimates at how long integration into PHP 5.5 will
>> take?
>
> There will be no integration, but the idea is to bundle it, as it is.
> The actual integration i
On Wed, Feb 27, 2013 at 8:05 PM, Christopher Jones
wrote:
> Are there any updated guesstimates at how long integration into PHP 5.5 will
> take?
There will be no integration, but the idea is to bundle it, as it is.
The actual integration is a large task and should/will target 5.6 and
later.
Or
Le 27/02/2013 20:04, Pierre Joye a écrit :
> I'd to get it in PECL as well, or even prior to any move to core.
+1
It will give php 5.4 (and 5.3) users an alternative to APC and will give
more audience to this extension (so more tests / feedback)
Remi.
--
PHP Internals - PHP Runtime Develop
On 02/27/2013 03:06 AM, Zeev Suraski wrote:
Are there any additional clarifications and/or unanswered questions people
are still waiting for, or can we move ahead to vote on the O+ inclusion RFC?
Zeev
Are there any updated guesstimates at how long integration into PHP 5.5 will
take?
Chr
In fact calls to this function are perfectly cacheable by op-caches and
can be optimized near zero. This would be a *great performance gain* for
this 10% Reflection usecases.
cryptocompress
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
hi Zeev,
On Wed, Feb 27, 2013 at 12:06 PM, Zeev Suraski wrote:
> Are there any additional clarifications and/or unanswered questions people
> are still waiting for, or can we move ahead to vote on the O+ inclusion RFC?
I have mixed feelings.
On one side I would say go ahead! But on the other si
sorry, i pollute this thread with discussion about reflection...
Am 27.02.2013 19:19, schrieb Nikita Popov:
> Why the heck do we want to get rid of Reflection?
> Do we want to alias *all* Reflection methods in this way?
definitely not, but:
I can access all properties of an object without reflec
On Wed, Feb 27, 2013 at 7:12 PM, Crypto Compress <
cryptocompr...@googlemail.com> wrote:
> "Get rid of ~10% of all reflection usecases with only one function."
>
> This is really an exorbitant shiny argument on its own. Simple too good to
> be true. What am i missing? :)
>
You're missing: Why the
May someone merge this PR (#290) as there are no arguments against it?
Or do I have to wait a little bit? (How long?)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"Get rid of ~10% of all reflection usecases with only one function."
This is really an exorbitant shiny argument on its own. Simple too good
to be true. What am i missing? :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 27.02.2013 18:16, schrieb Mike Willbanks:
how many times this is done
a quick search on GitHub for:
- "ReflectionClass" (PHP/Code): 240,922
- "getConstants" (PHP/Code): 22,208
This search is not accurate nor representative but there are some more
usecases in this results.
cryptocompress
On 2/27/13 10:22 AM, Sebastian Krebs wrote:
2013/2/27 Steve Clay
phpDoc already supports "@access private" for items to be left out of
public documentation. An IDE could be configured to have these items appear
greyed or not to appear in autocomplete lists.
a) You misuse the "private visibil
> I am simply suggesting an alternative to using Reflection whereas:
>>
>> get_class_constants([object|**string]);
>> get_object_constants([object])**;
>>
>> Do we need both; probably not; the first would likely do.
>>
>
> +1 for the first one only
>
>
> Am 27.02.2013 16:12, Analyst (Frank Schenk)
Am 27.02.2013 16:58, schrieb Mike Willbanks:
I am simply suggesting an alternative to using Reflection whereas:
get_class_constants([object|string]);
get_object_constants([object]);
Do we need both; probably not; the first would likely do.
+1 for the first one only
Am 27.02.2013 16:12, Anal
Zeev et al,
I just want to put my justification for the "only if no delay" vote. I
voted that way because we're already at a significant delay. If this vote
was a month ago when O+ was suggested first, I would definitely have voted
for "delay". In fact IIRC I proposed a delay back then. But after
+1
On Wed, Feb 27, 2013 at 1:12 PM, Zeev Suraski wrote:
> Based on the overwhelming response, the vote is now open J
>
>
>
> https://wiki.php.net/rfc/optimizerplus
>
>
>
> Voting ends March 7th.
>
>
>
> Zeev
>
--
Alberto Guimarães Viana
E-mail: albertogvi...@gmail.com
http://blog.albertovia
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
Zeev
>
> > thank you! It is a useful feature to me.
> >
> > class MyBitmask {
> > const POS_1 = 1;
> > //const POS_2 = 2;// reserved/undefined
> > //const POS_3 = 3;// reserved/undefined
> > const POS_4 = 4;
>
> I'm developing software with PHP since version 2 and i'm
2013/2/27 Steve Clay
> On 2/27/13 3:18 AM, Nikita Nefedov wrote:
>
>> I, for one, think it should be solved on the IDE side. I used a lot of
>> Doctrine's internal
>> methods lately and if they would be not accessible I wouldn't be able to
>> do a lot of things.
>> Of course internal methods/clas
2013/2/27 Frank Schenk
> Hi Crypto Compress,
>
> big congratz to that name, your mummy Hash Compress and your daddy Image
> Compress must be very proud!
>
> SCNR
>
> Am 02/27/2013 03:54 PM, schrieb Crypto Compress:
> > Hello Mike,
> >
> > thank you! It is a useful feature to me.
> >
> > class MyB
On Wed, Feb 27, 2013 at 3:06 AM, Zeev Suraski wrote:
> Are there any additional clarifications and/or unanswered questions people
> are still waiting for, or can we move ahead to vote on the O+ inclusion RFC?
>
It's been nearly a month since the RFC was posted and there's been
little-to-no discuss
Hi Crypto Compress,
big congratz to that name, your mummy Hash Compress and your daddy Image
Compress must be very proud!
SCNR
Am 02/27/2013 03:54 PM, schrieb Crypto Compress:
> Hello Mike,
>
> thank you! It is a useful feature to me.
>
> class MyBitmask {
> const POS_1 = 1;
> //const
On 2/27/13 3:18 AM, Nikita Nefedov wrote:
I, for one, think it should be solved on the IDE side. I used a lot of
Doctrine's internal
methods lately and if they would be not accessible I wouldn't be able to do a
lot of things.
Of course internal methods/classes shouldn't be exposed as a part of
Hello Mike,
thank you! It is a useful feature to me.
My usecase are checks on defined constants:
e.g. on my Bitmasks i want to check if given position-value is valid for
current bitmask: http://3v4l.org/CR2qJ
e.g. in my Exception Handler i check Exception-Codes: if not defined in
Exception cla
> On 12 January 2013 00:17, Ben Ramsey wrote:
> > I've opened voting for the array_column() function RFC.
> >
> > You can vote at https://wiki.php.net/rfc/array_column#voting
> >
> > Regards,
> > Ben
> >
>
> The vote has been open for almost three weeks and discussion tailed
> off after only a few
Are there any additional clarifications and/or unanswered questions people
are still waiting for, or can we move ahead to vote on the O+ inclusion RFC?
Zeev
Pierre Joye wrote:
hi,
On Wed, Feb 27, 2013 at 9:53 AM, Lester Caine wrote:
I was in a van with my son-in-law yesterday and we got around to discussing
websites and the like. I run his sites, but HE uses Joomla, so although it's
PHP he has no interest in the language as such as long as Joomla
hi,
On Wed, Feb 27, 2013 at 9:53 AM, Lester Caine wrote:
> I was in a van with my son-in-law yesterday and we got around to discussing
> websites and the like. I run his sites, but HE uses Joomla, so although it's
> PHP he has no interest in the language as such as long as Joomla works. So
> thi
Hello,
2013/2/27 Jens Riisom Schultz
> Hi,
>
> I just want to get a feel for whether the following idea would be
> instantly rejected (for example I get the feeling that adding keywords is a
> big deal):
>
> Often, when writing frameworks, you need to make public or protected
> functionality or
Paul Reinheimer wrote:
So my suggestion is simple, let's ask them: What they want, What they need,
how they installed PHP (source, rpm, deb, provided by hosting provider,
Zend Server), etc. Let's create a survey, and link to it prominently on
php.net. I considered just writing a survey myself, bu
2013/2/27 Jens Riisom Schultz
> Hi,
>
> I just want to get a feel for whether the following idea would be
> instantly rejected (for example I get the feeling that adding keywords is a
> big deal):
>
> Often, when writing frameworks, you need to make public or protected
> functionality or classes
On Wed, 27 Feb 2013 11:07:06 +0400, Jens Riisom Schultz
wrote:
Hi,
I just want to get a feel for whether the following idea would be
instantly rejected (for example I get the feeling that adding keywords
is a big deal):
Often, when writing frameworks, you need to make public or protect
53 matches
Mail list logo
