towards the next 5.3 release

16 years ago by Lukas Kahwe Smith — view source

unread

Aloha,

So Johannes and I have chatted about what needs to happen before we
can go to RC1. If there are no bigger issues the next version will
indeed be RC1. Release sometime in the second half of February. No
specific date has been set as of yet. One of the key questions before
a date can be set is what kind of issues we still have left to fix:

http://bugs.php.net/search.php?status=Open&phpver=5.3&cmd=display
we have the phar issues for big endian systems
closures and especially reflection were changed just before beta1
memory leak in the re2c
upgrading guide
reorganize the bundled php.ini files to production/development
recommendations
memleak in zend_object_handlers.c
PHP_5_3 missed merge from PHP_5_2 for write_func callback

I want to elaborate on point 1) a bit more. Of course we should fix as
many bugs as possible. But we should also not burden 5.3.0 with being
a bug fix release. Whatever gets fixed in terms of old bugs is
welcome, but we RMs will focus on those introduced in 5.3.

We would appreciate it of people could quickly assign themselves to
the above tickets, so that we know who to talk to.

assigned bugs where I am not sure if the developer in question is
still actively on the issue:
http://bugs.php.net/bug.php?id=47198 - ticks and ext/pcntl
http://bugs.php.net/bug.php?id=42641 - ob_start()
http://bugs.php.net/bug.php?id=47206 - XSLT

Other important assigned bugs are assigned to andrey/mysql, derick,
pierre, dmitry, scott. i assume you guys will let us know if you need
help, cannot fix the issue etc.

So I am sure there are still things off in other places too. Please
speak up what you feel needs to be addressed.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

PS: Just FYI .. I will be 99% offline from Feb. 14th until March 5th,
as I am traveling to Tanzania for vacation

16 years ago by Lukas Kahwe Smith — view source

unread

Hi,

I also just reopened:
http://bugs.php.net/bug.php?id=46026

Not sure if Greg has time ..

regards,
Lukas

16 years ago by Greg Beaver — view source

unread

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

16 years ago by Greg Beaver — view source

unread

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("concatenated"), (void **) &tmpzval) ) {

SEPARATE_ZVAL(tmpzval);
convert_to_boolean_ex(tmpzval);
data->expect_concatenated = Z_LVAL_PP(tmpzval);
zval_ptr_dtor(tmpzval);
tmpzval = NULL;
}

The reason being that it incorrectly uses whatever the zval is, thus any
hash table or object would evaluate to true, even an empty array or object.

Thus, the correct fix is the one implemented in zlib_filter.c, and I've
ported it over. It involves using a temporary zval, zval_copy_ctor()ing
it, and then convert_to_boolean_ex()ing it, which leaves the original
zval alone (the SEPARATE_ZVAL call does not do this properly), and
provides a valid boolean value. I'll commit momentarily.

Greg

16 years ago by Greg Beaver — view source

unread

Lukas Kahwe Smith wrote:

Aloha,

So Johannes and I have chatted about what needs to happen before we can
go to RC1. If there are no bigger issues the next version will indeed be
RC1. Release sometime in the second half of February. No specific date
has been set as of yet. One of the key questions before a date can be
set is what kind of issues we still have left to fix:

http://bugs.php.net/search.php?status=Open&phpver=5.3&cmd=display

we have the phar issues for big endian systems

I don't have access to any big endian systems, so I am appealing to
those who do to help me fix these (Scott had mentioned them, but I don't
have much information to be able to fix them, or even exactly what they
are).

http://bugs.php.net/bug.php?id=47085 - phar rename()

I'll handle this one, didn't realize it was there.

http://bugs.php.net/bug.php?id=47265 - phar and safe_mode

ditto

http://bugs.php.net/bug.php?id=47230 - phar

I can't fix this one, no sparc available. Any takers?

Greg

16 years ago by Scott MacVicar — view source

unread

Greg Beaver wrote:

Lukas Kahwe Smith wrote:

Aloha,

So Johannes and I have chatted about what needs to happen before we can
go to RC1. If there are no bigger issues the next version will indeed be
RC1. Release sometime in the second half of February. No specific date
has been set as of yet. One of the key questions before a date can be
set is what kind of issues we still have left to fix:

http://bugs.php.net/search.php?status=Open&phpver=5.3&cmd=display

we have the phar issues for big endian systems

I don't have access to any big endian systems, so I am appealing to
those who do to help me fix these (Scott had mentioned them, but I don't
have much information to be able to fix them, or even exactly what they
are).

https://www.opensolaris.org/register.jspa

And then speak to dsp for getting your account added to the test machine.

Scott

16 years ago by Daniel Convissor — view source

unread

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.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

16 years ago by Stanislav Malyshev — view source

unread

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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Derick Rethans — view source

unread

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 with that Stas, this shouldn't change.

regards,
Derick

--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: derickrethans

16 years ago by Greg Beaver — view source

unread

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 optional, the LSP is no longer violated, and the
E_STRICT disappears, as expected.

Opn->Bgs

Greg

16 years ago by Lukas Kahwe Smith — view source

unread

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 optional, the LSP is no longer violated, and the
E_STRICT disappears, as expected.

Opn->Bgs

I agree. This is exactly what we have E_STRICT for ..

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

16 years ago by Marcus Boerger — view source

unread

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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Best regards,
Marcus

16 years ago by Lukas Kahwe Smith — view source

unread

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 optimized for the web. I think that would imply that it would
try to keep going unless the engine is in an unstable state. So if you
ask me about what we should "claim" if anything .. is that we can
notify a user if he breaks the "IS-A" relationship, but that we will
not force a rewrite if you have coded yourself into a corner.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

16 years ago by Stanislav Malyshev — view source

unread

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 assumption, it
should. IMHO it's like having undefined variables, etc. It makes PHP
less strict, but I'd say it's not necessarily a bad thing.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Marcus Boerger — view source

unread

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. my (personal) opinion is
that if the engine can move forward, even with some assumption, it
should. IMHO it's like having undefined variables, etc. It makes PHP
less strict, but I'd say it's not necessarily a bad thing.

Hard as in E_RECOVERABLE_ERROR of course, since you are right that the
engine indeed can continue.

Best regards,
Marcus

16 years ago by Lukas Kahwe Smith — view source

unread

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. my (personal) opinion
is
that if the engine can move forward, even with some assumption, it
should. IMHO it's like having undefined variables, etc. It makes PHP
less strict, but I'd say it's not necessarily a bad thing.

Hard as in E_RECOVERABLE_ERROR of course, since you are right that the
engine indeed can continue.

Thats almost as useless. If you make it E_RECOVERABLE_ERROR .. it
essentially prevents people from modifying the method signatures in a
non academic OO manner, which I think is not the point of PHP.
E_STRICT reminds people that they are doing the wrong thing in
academic terms, which however might very well make sense in business
terms non the less.

regards,
Lukas

16 years ago by david.zuelke@bitextender.com — view source

unread

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 are 5.2.6,
5.2.7 and 5.2.8?

Thanks,

David

16 years ago by johannes@schlueters.de — view source

unread

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 are 5.2.6,
5.2.7 and 5.2.8?

I think independently from what we do in 5.3 we will have
incompatibilities between versions here which can't be worked-around in
userland (I don't consider if (version_compare(...)) { class ... } else
{ class ... } a proper workaround)

So here are three choices:

The DOMDoument typehint is certainly wrong.
Adding an interface is lots of additional trouble (user code will
break again, no proper way for users to be 5.2 and 5.3 compatible)
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

After reading this thread and some limited private discussion I think
the last option is the best.

johannes

16 years ago by david.zuelke@bitextender.com — view source

unread

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 are 5.2.6,
5.2.7 and 5.2.8?

I think independently from what we do in 5.3 we will have
incompatibilities between versions here which can't be worked-around
in
userland (I don't consider if (version_compare(...)) { class ... }
else
{ class ... } a proper workaround)

So here are three choices:

The DOMDoument typehint is certainly wrong.

Adding an interface is lots of additional trouble (user code will
break again, no proper way for users to be 5.2 and 5.3 compatible)

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

After reading this thread and some limited private discussion I think
the last option is the best.

16 years ago by Sebastian Bergmann — view source

unread

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 this :-/

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

16 years ago by johannes@php.net — view source

unread

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 this :-/

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
break source compatibility in a bad way here as the user's code would
have to follow the signature and won't be able to be 5.2 and 5.3
compatible in one file.

johannes

16 years ago by Sebastian Bergmann — view source

unread

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 methods. But
yeah, it probably does more harm than good.

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. But I will shut up now.

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

16 years ago by johannes@schlueters.de — view source

unread

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 methods. But
yeah, it probably does more harm than good.

Doing this for built-in stuff won't help the issue here is about
overloading an internal method. So we'd have to give it to userland.

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. But I will shut up now.

So reflection should use other data than the engine thus leading to
inconsistencies? Reflection's purpose is to give the engine's
information to userland ...

johannes

16 years ago by Sebastian Bergmann — view source

unread

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.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

16 years ago by Stanislav Malyshev — view source

unread

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 really don't have to invent another mini-php there to specify
argument types (what if I want A and B, but not C which extends B, but
also null would be OK, and strings "A" and "B" too?)

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Marcus Boerger — view source

unread

Hello Johannes,

Thursday, February 5, 2009, 8:02:47 PM, you 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 multiple typehints? Of
course the Reflection API would have to support this :-/

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
break source compatibility in a bad way here as the user's code would
have to follow the signature and won't be able to be 5.2 and 5.3
compatible in one file.

I actually think we only need this as an internal option and not for
reflection. For user code and reflection we would want to add support
for plain object (any class) type hinting - oh wait I said that before.
Right, my suggestion was to di:
function foo(Class $object) {}
It got rejected becuase I used the existing keyword ;class' rather then
inventing a new one that will in any case create a massive amount of new
issues (as with any new keyword). The only wayt out would be using magic
indication, as in two underscores. For instance:
function foo(Object $object) {}
Internally this obviously requires a change of the API and needs to be
done now, prior to 5.3.0.

For internal functions, we can get more precise, by providing a new 'i'
option in zend_parse_args. That would take the allowed classes from a
zend_class_entry**, with the last one being NULL.

(But well, it anyway already got rejected. So I guess we just live with
the problems. And changing it now would come with the risk of another
delay, which would of course be the worst thing ever).

Best regards,
Marcus

16 years ago by Christian Stocker — view source

unread

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 are 5.2.6,
5.2.7 and 5.2.8?

I think independently from what we do in 5.3 we will have
incompatibilities between versions here which can't be worked-around in
userland (I don't consider if (version_compare(...)) { class ... } else
{ class ... } a proper workaround)

So here are three choices:

The DOMDoument typehint is certainly wrong.

Adding an interface is lots of additional trouble (user code will
break again, no proper way for users to be 5.2 and 5.3 compatible)

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

After reading this thread and some limited private discussion I think
the last option is the best.

As one of the maintainer of ext/xsl, here's my +1 on the third option

chregu

16 years ago by Andi Gutmans — view source

unread

-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Tuesday, February 03, 2009 5:42 AM
To: php-dev List
Subject: [PHP-DEV] towards the next 5.3 release

--snip--

upgrading guide
--snip--

RC really signifies a feature complete + "should be releasable" state.
I think a good step before would be to reach out to some of the popular
PHP application authors and see if they can give b1 a try. This will
give us input for upgrading guide and it may raise some issues.

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.

Andi

16 years ago by Tony Bibbs — view source

unread

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

-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Tuesday, February 03, 2009 5:42 AM
To: php-dev List
Subject: [PHP-DEV] towards the next 5.3 release

--snip--

upgrading guide
--snip--

RC really signifies a feature complete + "should be releasable" state.
I think a good step before would be to reach out to some of the popular
PHP application authors and see if they can give b1 a try. This will
give us input for upgrading guide and it may raise some issues.

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.

Andi

--

--
Tony Bibbs
Email: tony@tonybibbs.com Phone: 515.554.8046
Twitter: tonybibbs Skype: tonybibbs
Web: http://www.tonybibbs.com

16 years ago by Lukas Kahwe Smith — view source

unread

-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Tuesday, February 03, 2009 5:42 AM
To: php-dev List
Subject: [PHP-DEV] towards the next 5.3 release

--snip--

upgrading guide
--snip--

RC really signifies a feature complete + "should be releasable" state.
I think a good step before would be to reach out to some of the
popular
PHP application authors and see if they can give b1 a try. This will
give us input for upgrading guide and it may raise some issues.

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.

Well we have established the primary testers mailinglist for this
purpose. However the current release plan only includes mailing this
list when the RC stage has been reached:
http://www.php.net/reST/php-src/README.RELEASE_PROCESS

So obviously this list can be used to get in contact with this group
of projects. Maybe it makes sense to include them in x.y.0 releases.
Then again the plan was to mail them once we hit RC1 anyways ...

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

16 years ago by Andi Gutmans — view source

unread

-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@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 testers mailinglist for this
purpose. However the current release plan only includes mailing this
list when the RC stage has been reached:
http://www.php.net/reST/php-src/README.RELEASE_PROCESS

So obviously this list can be used to get in contact with this group
of projects. Maybe it makes sense to include them in x.y.0 releases.
Then again the plan was to mail them once we hit RC1 anyways ...

OK that's good although it may make sense to push that up to beta.
In the past we have looked at Release Candidates as ("We think it's
ready to release and if no one finds critical bugs we could just rename
the package"). I doubt this is where you think we're at now and it's
more about making sure we get broader testing. It's a bit of a chicken
and egg so I understand the benefits of calling it RC. I guess what I
was suggesting was that we at least have folks do a quick sanity with
applications so we feel good about going into the RC.

Andi

16 years ago by Sean Coates — view source

unread

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 haven't had
any problems since ArrayObject was fixed, as far as I know.

16 years ago by Sebastian Bergmann — view source

unread

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 in the type hint.

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

16 years ago by Rob Richards — view source

unread

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 extensions involved and use said
interface in the type hint.

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.

Rob

16 years ago by pstradomski@gmail.com — view source

unread

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...

--
Paweł Stradomski

16 years ago by Rob Richards — view source

unread

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 break Liskov's principle...

I might agree if PHP were strictly an OO language, but it's not.
Although SimpleXML is currently the only other extension that shares
nodes with DOM, there are potential for others and not everything is OO
(i.e. both xmlReader and writer have procedural interfaces).

Rob

16 years ago by Sebastian Bergmann — view source

unread

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 metadata to XSLTProcessor last year I was not
aware of the latter purpose. I only wanted to fix the "missing metadata
for reflection" issue.

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

16 years ago by david.zuelke@bitextender.com — view source

unread

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 of the XML extensions involved and use said
interface in the type hint.

And then code breaks code again.

The problem with the previous change, the fix for it and the fix you
suggest is that it cannot be handled at runtime using a version check.
My class Foo extends XsltProcessor, and it cannot have different
method signatures for different PHP versions.

Good argument for adding a preprocessor, isn't it? :D

David

towards the next 5.3 release

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 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.

Maybe just use a plain old if()? :) I understand that is super-uncool bit we really don't have to invent another mini-php there to specify argument types (what if I want A and B, but not C which extends B, but also null would be OK, and strings "A" and "B" too?)

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 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.

Maybe just use a plain old if()? :) I understand that is super-uncool
bit we really don't have to invent another mini-php there to specify
argument types (what if I want A and B, but not C which extends B, but
also null would be OK, and strings "A" and "B" too?)