On 15.02.2009, at 17:18, Marcus Boerger wrote:
Hello Stanislav,
Friday, February 13, 2009, 7:03:30 AM, you wrote:
Hi!
it should actually be a hard error. As we always claim PHP
follows pure
IS-A relation ships.
I feel very uneasy with hard errors on something that is not indeed
an
Hello Stanislav,
Friday, February 13, 2009, 7:03:30 AM, you wrote:
> Hi!
>> it should actually be a hard error. As we always claim PHP follows pure
>> IS-A relation ships.
> I feel very uneasy with hard errors on something that is not indeed an
> error preventing engine from continuing. I.e.
Hi!
it should actually be a hard error. As we always claim PHP follows pure
IS-A relation ships.
I feel very uneasy with hard errors on something that is not indeed an
error preventing engine from continuing. I.e. my (personal) opinion is
that if the engine can move forward, even with some
Maybe we can first collect a list here on internals@ on what apps have
been successfully been run on 5.3 and whether they required any
tweaking. If after we make a list there's still need to reach out
I'd be
happy to do some of that.
FWIW, I've some casual testing with Habari and 5.3 and we h
On 08.02.2009, at 15:36, Marcus Boerger wrote:
it should actually be a hard error. As we always claim PHP follows
pure
IS-A relation ships.
Not sure we claimed PHP did anything pure ever. Or when we "claim"
anything to begin with. Maybe we also claim that we are a glue
language optimi
Hello Stanislav,
it should actually be a hard error. As we always claim PHP follows pure
IS-A relation ships.
Tuesday, February 3, 2009, 8:42:51 PM, you wrote:
> Hi!
>> http://bugs.php.net/bug.php?id=46984 - E_STRICT
> I think overriding foo($x) with foo($x, $y) - with both parameters
> req
Hello Johannes,
Thursday, February 5, 2009, 8:02:47 PM, you wrote:
> On Thu, 2009-02-05 at 10:36 -0800, Sebastian Bergmann wrote:
>> Johannes Schlüter wrote:
>> > - No typehint, as it is now, #47206 "Expected / to be documented",
>> > incompatible with 5.2.6-5.2.8 but compatible with most other
> -Original Message-
> From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
> Sent: Friday, February 06, 2009 11:57 PM
> To: Andi Gutmans
> Cc: php-dev List
> Subject: Re: [PHP-DEV] towards the next 5.3 release
>
> Well we have established the primary test
On 07.02.2009, at 03:12, Andi Gutmans wrote:
-Original Message-
From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
Sent: Tuesday, February 03, 2009 5:42 AM
To: php-dev List
Subject: [PHP-DEV] towards the next 5.3 release
--snip--
5) upgrading guide
--snip--
RC really signifies a
I'd be happy to give this a whirl on the project here and report back:
geeklog.net. I'm assuming it'll run just fine. I had it running under
alpha3 fine.
--Tony
On Fri, Feb 6, 2009 at 8:12 PM, Andi Gutmans wrote:
> > -Original Message-
> > From: Lukas Kahwe Smith [mailto:m...@pooteewe
> -Original Message-
> From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
> Sent: Tuesday, February 03, 2009 5:42 AM
> To: php-dev List
> Subject: [PHP-DEV] towards the next 5.3 release
>
--snip--
> 5) upgrading guide
--snip--
RC really signifies a feature complete + "should be releasab
Hi!
Of course we could, we'd "just" have to change a structure and
zend_verify_arg_class_kind() and of course the language syntax to allow
something like "function foo(A|B $bar) {}" but this still would mean to
Maybe just use a plain old if()? :) I understand that is super-uncool
bit we reall
Sebastian Bergmann wrote:
> It just sucks, IMHO, that some functions and methods will not have
> Reflection API metadata because the same arginfo structure is used for
> two things.
That did not come out right, nevermind.
--
Sebastian Bergmann http://sebastian-bergmann.
On Thu, 2009-02-05 at 11:06 -0800, Sebastian Bergmann wrote:
> Johannes Schlüter wrote:
> > Of course we could, we'd "just" have to change a structure and
> > zend_verify_arg_class_kind() and of course the language syntax to allow
> > something like "function foo(A|B $bar) {}" but this still would
On 5.2.2009 17:32 Uhr, Johannes Schlüter wrote:
> On Wed, 2009-02-04 at 13:12 +0100, David Zülke wrote:
>> Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
>>
>>> http://bugs.php.net/bug.php?id=47206 - XSLT
>> I looked through the CVS logs, could you confirm I understand it right:
>>
>> The type
Johannes Schlüter wrote:
> Of course we could, we'd "just" have to change a structure and
> zend_verify_arg_class_kind() and of course the language syntax to allow
> something like "function foo(A|B $bar) {}" but this still would mean to
This should, of course, only be for built-in functions and
On Thu, 2009-02-05 at 10:36 -0800, Sebastian Bergmann wrote:
> Johannes Schlüter wrote:
> > - No typehint, as it is now, #47206 "Expected / to be documented",
> > incompatible with 5.2.6-5.2.8 but compatible with most other 5.2
> > versions
>
> Could we extend the arginfo system to allow for
Johannes Schlüter wrote:
> - No typehint, as it is now, #47206 "Expected / to be documented",
> incompatible with 5.2.6-5.2.8 but compatible with most other 5.2
> versions
Could we extend the arginfo system to allow for multiple typehints? Of
course the Reflection API would have to support t
On 05.02.2009, at 17:32, Johannes Schlüter wrote:
On Wed, 2009-02-04 at 13:12 +0100, David Zülke wrote:
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
http://bugs.php.net/bug.php?id=47206 - XSLT
I looked through the CVS logs, could you confirm I understand it
right:
The type hint was
On Wed, 2009-02-04 at 13:12 +0100, David Zülke wrote:
> Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
>
> > http://bugs.php.net/bug.php?id=47206 - XSLT
>
> I looked through the CVS logs, could you confirm I understand it right:
>
> The type hint was added in 5.2.6, and will be gone again in
Rob Richards wrote:
> I might agree if PHP were strictly an OO language, but it's not.
I think part of the problem is that the same information, arginfo, is
used for things: provide metadata for the Reflection API and type
hinting of internal functions/methods.
When I added the arginfo metada
Am 04.02.2009 um 15:16 schrieb Sebastian Bergmann:
Rob Richards wrote:
The addition in 5.2.6 was a BC break and is fixed in 5.2.9
Removing the type-hint is only a short-term fix, IMHO. A better
solution
would be to introduce a marker interface that is implemented by the
respective classes
Paweł Stradomski wrote:
W liście Rob Richards z dnia środa 04 lutego 2009:
If that's the route this is going to go, I'd rather be able to set an
anytype hint where the developer could possibly restrict this further
with a more specific type if they extend the class.
But that would bre
W liście Rob Richards z dnia środa 04 lutego 2009:
> If that's the route this is going to go, I'd rather be able to set an
> anytype hint where the developer could possibly restrict this further
> with a more specific type if they extend the class.
But that would break Liskov's principle...
--
Sebastian Bergmann wrote:
Rob Richards wrote:
The addition in 5.2.6 was a BC break and is fixed in 5.2.9
Removing the type-hint is only a short-term fix, IMHO. A better solution
would be to introduce a marker interface that is implemented by the
respective classes of the XML extensi
Rob Richards wrote:
> The addition in 5.2.6 was a BC break and is fixed in 5.2.9
Removing the type-hint is only a short-term fix, IMHO. A better solution
would be to introduce a marker interface that is implemented by the
respective classes of the XML extensions involved and use said
interface
David Zülke wrote:
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
http://bugs.php.net/bug.php?id=47206 - XSLT
I looked through the CVS logs, could you confirm I understand it right:
The type hint was added in 5.2.6, and will be gone again in 5.2.9, so
the only PHP releases with DOMDocume
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
http://bugs.php.net/bug.php?id=47206 - XSLT
I looked through the CVS logs, could you confirm I understand it right:
The type hint was added in 5.2.6, and will be gone again in 5.2.9, so
the only PHP releases with DOMDocument type hints there
On 03.02.2009, at 20:52, Greg Beaver wrote:
Stanislav Malyshev wrote:
Hi!
http://bugs.php.net/bug.php?id=46984 - E_STRICT
I think overriding foo($x) with foo($x, $y) - with both parameters
required - leads to calls to foo with one argument be wrong for
child -
thus violating LSP and war
Stanislav Malyshev wrote:
> Hi!
>
>> http://bugs.php.net/bug.php?id=46984 - E_STRICT
>
> I think overriding foo($x) with foo($x, $y) - with both parameters
> required - leads to calls to foo with one argument be wrong for child -
> thus violating LSP and warranting E_STRICT.
I agree. If $y were
On Tue, 3 Feb 2009, Stanislav Malyshev wrote:
> > http://bugs.php.net/bug.php?id=46984 - E_STRICT
>
> I think overriding foo($x) with foo($x, $y) - with both parameters required -
> leads to calls to foo with one argument be wrong for child - thus violating
> LSP and warranting E_STRICT.
I agree
Hi!
http://bugs.php.net/bug.php?id=46984 - E_STRICT
I think overriding foo($x) with foo($x, $y) - with both parameters
required - leads to calls to foo with one argument be wrong for child -
thus violating LSP and warranting E_STRICT.
--
Stanislav Malyshev, Zend Software Architect
s...@zend
Lukas Kahwe Smith wrote:
> Hi,
>
> I also just reopened:
> http://bugs.php.net/bug.php?id=46026
>
> Not sure if Greg has time ..
Actually, this was more complex than originally stated, in that this
code is incorrect:
if (SUCCESS == zend_hash_find(HASH_OF(filterparams), "concatenated",
sizeof("c
Hi:
I just reopend http://bugs.php.net/bug.php?id=43817 (opendir() fails on
Windows...) and marked the version 5.3.0beta1.
--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.AnalysisAn
Lukas Kahwe Smith wrote:
> Hi,
>
> I also just reopened:
> http://bugs.php.net/bug.php?id=46026
>
> Not sure if Greg has time ..
Anyone can do this, the 3 lines that need removal are correct, I simply
forgot about it at commit time, and for the last erm, several months :)
Greg
--
PHP Inte
Hi,
I also just reopened:
http://bugs.php.net/bug.php?id=46026
Not sure if Greg has time ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
36 matches
Mail list logo
