The RFC here: https://wiki.php.net/rfc/propertygetsetsyntax
Talks about allowing a sub-class to access a parent getter via
TimePeriod::$Milliseconds or possibly parent::$Milliseconds.
Either of those methods (currently) tries to access a static property in the
parent or defined class. It would
Hi Chris:
> Can you log a bug for this?
https://bugs.php.net/bug.php?id=60333
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Br
On Sat, Nov 19, 2011 at 02:46, Clint M Priest wrote:
> What would everyone think about multiple levels of visibility for
> getters/setters?
>
> class Sample {
>
> public $Variable {
> public get { return "Public"; }
> protected get { return "Protected"; }
>
What would everyone think about multiple levels of visibility for
getters/setters?
class Sample {
public $Variable {
public get { return "Public"; }
protected get { return "Protected"; }
private get { return "Private"; }
public set
On 11/18/2011 01:06 PM, Daniel Convissor wrote:
Hi Folks:
The output of mysqli_fetch_field() produces different results when
running against mysqlnd than it does against libmysql. I've mentioned
Can you log a bug for this?
Chris
--
Email: christopher.jo...@oracle.com
Tel: +1 650 506 863
Hi Again:
> type libmysql mysqlnd
> ---
> CHAR(2) 26
Oh, by the way, I saw a CHAR(20) field come out as 60 in mysqlnd. So it
looks like the size is being multiplied by 3. Perhaps that's a clue for
debugging.
Thanks,
--Dan
--
T H E A N A L Y S I S A
2011/11/17 Johannes Schlüter
> Just to make one thing clear: To the best of my knowledge the module
> works with 5.4 and trunk (it's three months since I tested, but I'm not
> aware of a recent big API break) only defect is that the PDO sqlite2
> driver won't be there and can't be enabled in an e
Hi Folks:
The output of mysqli_fetch_field() produces different results when
running against mysqlnd than it does against libmysql. I've mentioned
issues along these lines a couple times on the list in the midst of
other threads relating to MySQL handling, but nobody has really
addressed it direc
hi Dirk,
It is not a regression in our code but in the freetype library. I
still have to find a way to have a reliable tests suite for this.
Cheers,
On Thu, Nov 10, 2011 at 11:01 PM, Dirk Haun wrote:
> I've notice, back in PHP 5.4.0 beta 2, that this test was failing:
>
> Bug #48555 (ImageFTBBo
I've added it to the ticket, and we used the pgsql-fixed.diff. After that
patch, php was CONSTANTLY exiting on signal 6. The posted backtrace was before
that patch.
---
Eric F Crist
System Administrator
ClaimLynx, Inc
(952) 593-5969 x2301
On Nov 18, 2011, at 14:15:04, Felipe Pena wrote:
>
2011/11/10 Eric Crist :
> Hello folks,
>
> We've run into problems related to using Postgres as a datastore for
> sessions, which appears to be identified in bug report 52389
> (https://bugs.php.net/bug.php?id=52389). We've tried the patch attached to
> the ticket, and have not seen our issue r
2011/11/10 Scott Aubrey :
> Hi List,
>
> When testing out 5.4b2 , I've noticed that the default Phar stub runs
> the first argument to Phar::createDefaultStub when run using the cli
> server. Is this right? Should i file a bug?
>
I can't understand, please file a bug explaining such behavior.
Tha
Hi,
2011/11/10 Dirk Haun :
> I've notice, back in PHP 5.4.0 beta 2, that this test was failing:
>
> Bug #48555 (ImageFTBBox() differs from previous versions for texts with new
> lines) [ext/gd/tests/bug48555.phpt]
>
> So I went to https://bugs.php.net/bug.php?id=48555 and left a comment.
>
> The
On Fri, 18 Nov 2011 12:46:05 +0100, Nicolas Grekas wrote:
> Without a real ob_gzhandler function, replacing it with an alias as
> currently in RC1 : what if someone then creates an ob_gzhandler function
> in userland ? would ob_start('ob_gzhandler') use the userland function
> or still the alias ?
On Fri, Nov 18, 2011 at 6:40 PM, Ralph Schindler
wrote:
> Hey Pierre,
>
> My perspective and expectations are framed by all sorts of existing
> literature as well as the discussions on this list. It saddens me that you
> did not address any of the points I've brought up. And, I simply cannot
> t
Comments Inline
> 1) What we know and have been told is that PHP's signature
> checking is governed by Liskov Substitution Principle. There are
> many references to this in the list.
Except that signature checking is not needed for LSP to function. You
can write all of your code using duck typi
Hey Ralph,
i think your argument on this is wrong. If we go your road:
1. Fact: PHP follows the LSP
2. Fact: The constructor is not part of the type, but a factory method.
3. Conclusion: constructors are not allowed to be part of the interface or
abstract classes.
Reversing the argument, by intr
On 18 November 2011 17:37, Ferenc Kovacs wrote:
>
>
> On Fri, Nov 18, 2011 at 5:40 PM, Richard Quadling
> wrote:
>>
>> On 18 November 2011 13:31, Felipe Pena wrote:
>> > 2011/11/18 Pierre Joye :
>> >> same here, and for any other places in the ob_* APIs. Functions
>> >> returns false on error, c
Hey Pierre,
My perspective and expectations are framed by all sorts of existing
literature as well as the discussions on this list. It saddens me that
you did not address any of the points I've brought up. And, I simply
cannot tell what basis you have for your interpretation and opinion. It
On Fri, Nov 18, 2011 at 5:40 PM, Richard Quadling wrote:
> On 18 November 2011 13:31, Felipe Pena wrote:
> > 2011/11/18 Pierre Joye :
> >> same here, and for any other places in the ob_* APIs. Functions
> >> returns false on error, cleaning something already cleaned or empty is
> >> not an erro.
On Fri, Nov 18, 2011 at 5:37 PM, Felipe Pena wrote:
> 2011/11/18 Etienne Kneuss :
>> To me, it feels similar to the Array->String conversion:
>> It is one of those implicit conversions that is almost always indicating a
>> bug.
>>
>> Therefore I would rather have both throw warnings than none of
On 18 November 2011 13:31, Felipe Pena wrote:
> 2011/11/18 Pierre Joye :
>> same here, and for any other places in the ob_* APIs. Functions
>> returns false on error, cleaning something already cleaned or empty is
>> not an erro.
>>
>
> Same opinion here.
WOW. All the developers agreeing with a c
2011/11/18 Etienne Kneuss :
> Hi,
>
> On Fri, Nov 18, 2011 at 16:41, Nikita Popov wrote:
>> *push*
>>
>> On Fri, Nov 11, 2011 at 10:40 PM, Nikita Popov
>> wrote:
>>> Hi internals!
>>>
>>> I'd like to get some attention to bug #60039 [1]. It is about the
>>> behavior of array_key_exists with "unus
2011/11/18 Clint M Priest :
> Is there any reason I would have to free a pointer from the language_parser
> if I am just storing a reference to $1
>
> I'm doing this:
> CG(accessor_node) = &$1;
>
This doesn't looks right, as &$1 points to the local variable in yyparse().
> And in doing so it is
Hi,
On Fri, Nov 18, 2011 at 16:41, Nikita Popov wrote:
> *push*
>
> On Fri, Nov 11, 2011 at 10:40 PM, Nikita Popov
> wrote:
>> Hi internals!
>>
>> I'd like to get some attention to bug #60039 [1]. It is about the
>> behavior of array_key_exists with "unusual" keys like floats, bools
>> and resou
*push*
On Fri, Nov 11, 2011 at 10:40 PM, Nikita Popov
wrote:
> Hi internals!
>
> I'd like to get some attention to bug #60039 [1]. It is about the
> behavior of array_key_exists with "unusual" keys like floats, bools
> and resources. Currently array_key_exists throws a warning if such a
> key is
Is there any reason I would have to free a pointer from the language_parser if
I am just storing a reference to $1
I'm doing this:
CG(accessor_node) = &$1;
And in doing so it is causing a memory leak, only if I add:
efree($1.u.constant.value.str.val);
Does that memory leak go away.
-Clint
2011/11/18 Pierre Joye :
> same here, and for any other places in the ob_* APIs. Functions
> returns false on error, cleaning something already cleaned or empty is
> not an erro.
>
Same opinion here.
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
same here, and for any other places in the ob_* APIs. Functions
returns false on error, cleaning something already cleaned or empty is
not an erro.
On Fri, Nov 18, 2011 at 2:08 PM, Ilia Alshanetsky wrote:
> I agree with Stas' point there is really no need to force people do
> the while (ob_get_le
So the consensus so far is to drop notices from ob_clean(), ob_end_clean() and
ob_get_clean()? What about ob_flush() or others?
David
On 18.11.2011, at 14:08, Ilia Alshanetsky wrote:
> I agree with Stas' point there is really no need to force people do
> the while (ob_get_level()) ob_end_cle
I agree with Stas' point there is really no need to force people do
the while (ob_get_level()) ob_end_clean(); loop or "force" people to
use the @ob_end_clean(); to avoid notices. If there are no buffers to
clear it should be a noop, without any notices being raised.
On Fri, Nov 18, 2011 at 12:04
Without a real ob_gzhandler function, replacing it with an alias as
currently in RC1 : what if someone then creates an ob_gzhandler function in
userland ? would ob_start('ob_gzhandler') use the userland function or
still the alias ? I think this is a second argument to make ob_gzhandler a
real func
I strongly disagree, this encourages bad practices. We could however
reduce the error level to warning.
On Fri, Nov 18, 2011 at 10:54 AM, Derick Rethans wrote:
> On Thu, 17 Nov 2011, Ralph Schindler wrote:
>
>> That said, we really should consider removing this limitation from
>> constructor
>>
On Thu, 17 Nov 2011, Ralph Schindler wrote:
> That said, we really should consider removing this limitation from constructor
> signature checking. Not only is it a BC break, it doesn't make sense in the
> context of PHP.
I agree, we should not be having that check for constructors based on
the
hi,
On Thu, Nov 17, 2011 at 10:12 PM, Ralph Schindler
wrote:
> Hey All,
>
> Concerning RC1, __construct() and https://wiki.php.net/rfc/prototype_checks
>
> I think we need to round out this discussion on the __construct() signature
> checking in 5.4. The current behavior (RC1) feels very wrong w
On Mon, 14 Nov 2011 11:59:04 -0800, Stas Malyshev wrote:
> Well, apparently they did for some reason, doing custom output handlers
> based on it I guess. So the question is - is it possible to still have
> this function implemented?
I'll try to hack up a replacement. It would definitely help if
Well done! :)
2011/11/18 Laruence :
> Hi:
>
> I have fixed the bug(it is a simple fix that I didn't expect before
> I look into it ), ignore me...
>
> thanks
>
> On Fri, Nov 18, 2011 at 1:09 PM, Laruence wrote:
>> Hi:
>>
>> I have filed a bug about this issue: https://bugs.php.net/bug.php?id=
Hi:
I have fixed the bug(it is a simple fix that I didn't expect before
I look into it ), ignore me...
thanks
On Fri, Nov 18, 2011 at 1:09 PM, Laruence wrote:
> Hi:
>
> I have filed a bug about this issue: https://bugs.php.net/bug.php?id=60306
>
> following script:
>
> $s = "洪仁";
> var
38 matches
Mail list logo
