Stanislav Malyshev wrote:
>>the feature actually exists because we need array($obj,
>> 'parent::func')
>
> Why/when do you need that?
You'd probably do something along those lines if it were possible:
((ParentClass) $child)->virtualMethod();
If you prefer, s/You/One/
Regards,
--
Michael
Jacques Marneweck wrote:
> Are you using PHPUnit for the unit tests?
>
> Also there was some alert stuff that Jim Winstead if I remember correctly
> was wanting to hook into the mix (it's all commented out from my last
> look at
> the bugsweb code), which would be great to allow devs to subscribe
the feature actually exists because we need array($obj, 'parent::func')
Why/when do you need that?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Documentation and Norwegian translation of the PHP Manual (phpdoc
and phpdoc-no)
Hello all,
Please create this account (id #1927) and I'll take care of the
karma. Thanks!
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Are you using PHPUnit for the unit tests?
Also there was some alert stuff that Jim Winstead if I remember
correctly
was wanting to hook into the mix (it's all commented out from my last
look at
the bugsweb code), which would be great to allow devs to subscribe to
bugs
(package / project /
Hello Richard,
the feature actually exists because we need array($obj, 'parent::func')
best regards
marcus
Thursday, May 31, 2007, 10:33:54 PM, you wrote:
> On Thu, May 31, 2007 1:06 pm, Stanislav Malyshev wrote:
>>> It's already supported, but buggy right now. I don't believe fixing
>>> it
William A. Rowe, Jr. wrote:
> An example php.ini file that is significantly immune to these side effects
> would seem to be a good idea. Either that, or a "DON'T COHOST UNTRUSTED
> SCRIPTS" disclaimer :)
Disabling dl() is a rather well-known ISP configuration. And it isn't
allowed at all in any
Richard Lynch wrote:
> On Thu, May 31, 2007 3:36 pm, William A. Rowe, Jr. wrote:
>> In httpd server (and most) there is a startup phase, when we generally
>> trust what the admin has done, and a runtime phase. There are obvious
>> exploits if untrusted scripts can run arbitrary dlload's after
>> s
Rasmus Lerdorf wrote:
> William A. Rowe, Jr. wrote:
>> An example php.ini file that is significantly immune to these side effects
>> would seem to be a good idea. Either that, or a "DON'T COHOST UNTRUSTED
>> SCRIPTS" disclaimer :)
>
> Disabling dl() is a rather well-known ISP configuration. And
On Thu, May 31, 2007 4:14 pm, William A. Rowe, Jr. wrote:
> Richard Lynch wrote:
>> On Thu, May 31, 2007 3:36 pm, William A. Rowe, Jr. wrote:
>>> In httpd server (and most) there is a startup phase, when we
>>> generally
>>> trust what the admin has done, and a runtime phase. There are
>>> obvious
On Thu, May 31, 2007 3:44 pm, Stanislav Malyshev wrote:
>> What about array('B', 'self::foo') -- I can see how that's needed to
>> call the static method, I guess...
>
> But that won't be different from just array('B', 'foo') so you don't
> need self::...
Duh.
Sorry.
I somehow had some imaginary
On Thu, May 31, 2007 3:36 pm, William A. Rowe, Jr. wrote:
> In httpd server (and most) there is a startup phase, when we generally
> trust what the admin has done, and a runtime phase. There are obvious
> exploits if untrusted scripts can run arbitrary dlload's after
> startup.
Call me silly, but
Rasmus Lerdorf wrote:
> William A. Rowe, Jr. wrote:
>> In httpd server (and most) there is a startup phase, when we generally
>> trust what the admin has done, and a runtime phase. There are obvious
>> exploits if untrusted scripts can run arbitrary dlload's after startup.
>>
>> enable_dl in php.i
What about array('B', 'self::foo') -- I can see how that's needed to
call the static method, I guess...
But that won't be different from just array('B', 'foo') so you don't
need self::...
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals -
William A. Rowe, Jr. wrote:
> In httpd server (and most) there is a startup phase, when we generally
> trust what the admin has done, and a runtime phase. There are obvious
> exploits if untrusted scripts can run arbitrary dlload's after startup.
>
> enable_dl in php.ini will obviously override t
On Wed, May 30, 2007 9:54 am, Jochem Maas wrote:
> Richard Lynch wrote:
>> Maybe I'm just confused (well, I'm always confused...) but if a
>> Class
>> has multiple children, how the heck would PHP know which child:: to
>> call?...
>
> the use of the name 'child' is very confusing, I would prefer 's
In httpd server (and most) there is a startup phase, when we generally
trust what the admin has done, and a runtime phase. There are obvious
exploits if untrusted scripts can run arbitrary dlload's after startup.
enable_dl in php.ini will obviously override this, but to start up and
load dynamic
On Thu, May 31, 2007 1:06 pm, Stanislav Malyshev wrote:
>> It's already supported, but buggy right now. I don't believe fixing
>> it
>> for odd cases will bother anyone.
>
> Well, I'm for one not sure that callback in form array('B',
> 'parent::foo') shouldn't error out instead (I know it works now
I'd rather not have my old libphp#.so file over-written when I install
a new version, in case things go horribly wrong and I want to just
roll-back...
Then you have the same reason to worry right now - every php5 install
from 5.0.0 to 5.2.3 overwrites libphp5.so.
There was a time where one c
On Wed, May 30, 2007 5:02 pm, stefano federici wrote:
> I trying to find a reason why array functions are not allowed to be
> used as normal arrays. To clarify, I'm allowed to write
>
> $arr = array( "maria", "mario", "luigi", "luisa");
> echo $arr[1];
>
> but I'm not allowed to write
>
> echo arra
On Thu, May 31, 2007 4:04 am, Jani Taskinen wrote:
> Antony Dovgal kirjoitti:
>> On 31.05.2007 03:29, Jani Taskinen wrote:
>>> The whole idea of having that number there is pretty stupid..why
>>> not
>>> just remove them altogether..?
>>
>> Well, in some places it's just not possible, like libphp6.
It's already supported, but buggy right now. I don't believe fixing it
for odd cases will bother anyone.
Well, I'm for one not sure that callback in form array('B',
'parent::foo') shouldn't error out instead (I know it works now, but it
never states in the docs it's legal and I don't think it
And if you think that this breaks something..well, it doesn't.
The old libphp4.so, and libphp5.so aren't changing with this, are
they? :D
Right, but the World Order [tm] does =)
Looking at how Unix shared libs are named customary, there's a
considerable part of those bearing major versions i
If, for exemple, you want to run PHP4 and PHP5 on two different instances of
Apache using the same Apache binary (but two different httpd.conf), it's
useful to have them named libphp4.so and libphp5.so because `make install'
automatically throws the library where apxs tells it to.
If the major ve
Hi,
yes, the notice is expected. You either have to cast to a binary string
or by setting the stream's encoding using stream_encode() since we can't
guess which encoding you're going to use for a stream.
johannes
On Thu, 2007-05-31 at 05:38 -0700, Nikhil Gupta wrote:
> Hi,
> I'm writing some PHP
Hi,
I'm writing some PHPT test cases for PHP 6 and wanted to check that I was
seeing the correct behaviour with unicode.
I tried the following simple testcase and gets Notice message with php6 unicode
ON.
--TEST--
test.phpt
--FILE--
--UEXPECT--
command:
php run-tests.php -u test.phpt
cat test.
Hi,
I'm trying to write a function in an extension (using PHP_FUNCTION) that
returns a value by reference. I have declared an arg info block
(ZEND_BEGIN_ARG_INFO_EX) to tell the engine that I am returning a value
by reference. Then to return the value, I first delete the old return
value (zval_ptr
On 31.05.2007 13:44, Jani Taskinen wrote:
"worked for years" is just why I said "having a totally new major
version"..meaning this is the time to fix the bad practises.
For filenames this is no problem at all, you can always rename files
yourself if you _really_ need to have different files arou
"worked for years" is just why I said "having a totally new major
version"..meaning this is the time to fix the bad practises.
For filenames this is no problem at all, you can always rename files
yourself if you _really_ need to have different files around.
And if you think that this breaks some
On 31.05.2007 13:25, Lukas Kahwe Smith wrote:
Antony Dovgal wrote:
On 31.05.2007 13:04, Jani Taskinen wrote:
Antony Dovgal kirjoitti:
On 31.05.2007 03:29, Jani Taskinen wrote:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?
Well, in some p
Stefan Walk wrote:
At the moment, SVN is a pain in the ass when it comes to merging, but
they claim that it's fixed in 1.5...
svnmerge.py: http://www.orcaware.com/svn/wiki/Svnmerge.py
can help quite a lot as it maintains merges. And as it stores the merge
information in SVN properties I'm sur
This is when I use concept called "rename" when I copy these babies around.. :D
And as you knew, it's not possible (anymore) to have both enabled in same apache
instance anyway.
--Jani
Antony Dovgal kirjoitti:
On 31.05.2007 13:04, Jani Taskinen wrote:
Antony Dovgal kirjoitti:
On 31.05.2007
Correct me if I'm wrong, but for those "just not possible" cases, a
single version-constant in the source would suffice, right? So it's at
least not inconsistent...
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Antony Dovgal wrote:
On 31.05.2007 13:04, Jani Taskinen wrote:
Antony Dovgal kirjoitti:
On 31.05.2007 03:29, Jani Taskinen wrote:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?
Well, in some places it's just not possible, like libphp6.so e
On 31.05.2007 13:04, Jani Taskinen wrote:
Antony Dovgal kirjoitti:
On 31.05.2007 03:29, Jani Taskinen wrote:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?
Well, in some places it's just not possible, like libphp6.so etc.
You chose just t
Antony Dovgal kirjoitti:
On 31.05.2007 03:29, Jani Taskinen wrote:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?
Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it
On 5/31/07, Stefan Walk <[EMAIL PROTECTED]> wrote:
IMO, git is a choice worth thinking about for linux-only projects, but
if there are windows clients involved, it's not anymore (last time i
checked, it required cygwin).
I used it under cygwin and works well as far as I can tell (be sure to
use
IMO, git is a choice worth thinking about for linux-only projects, but
if there are windows clients involved, it's not anymore (last time i
checked, it required cygwin).
At the moment, SVN is a pain in the ass when it comes to merging, but
they claim that it's fixed in 1.5...
Regards,
Stefan
--
On 5/31/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> freedesktop has moved to GIT some time ago and for what I heard from
> the developers, it is a huge improvement in their development process.
> The only bad point (which exists with any other migratrion) is the
> time required to learn the
Pierre wrote:
> Hi,
>
> On 5/31/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>
>> As we expect many more years for PHP we should make sure that the train
>> we're riding has momentum and can help us continue to scale our dev
>> process. I think SVN is the right train to hop onto.
>
> I would like
Hi,
On 5/31/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
As we expect many more years for PHP we should make sure that the train
we're riding has momentum and can help us continue to scale our dev
process. I think SVN is the right train to hop onto.
I would like to propose Git. I think it is m
static function getTableName() { return 'PRODS'; }
What a great idea! You can just do:
$tableName = $this->getTableName();
...from within the base class. No need for static:: or super:: keywords
anymore... It may be not as elegant as having a special keyword for
it... But, for now, this appr
On 31.05.2007 03:29, Jani Taskinen wrote:
The whole idea of having that number there is pretty stupid..why not just remove
them altogether..?
Well, in some places it's just not possible, like libphp6.so etc.
Other places should be fixed, of course.
Actually I have a patch for some SAPIs, just d
static function getTableName() { return 'PRODS'; }
What a great idea! You can just do:
$tableName = $this->getTableName();
...from within the base class. No need for static:: or super:: keywords
anymore... It may be not as elegant as having a special keyword for
it... (Or if this is the inte
44 matches
Mail list logo
