Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
- __toString()
There was a problem with the Zend engine 2.0 that forced us to drop this
feature. Now that we have 2.1 we should check again and readd the feature.
Since PHP is designed to generate string output i think that should be
made as easy as possible. And after learning echo and '.' it is hard to
explain that 'echo $foo . $bar' could result in something different than
'echo $foo, $bar'. Besides if it turned out that there is still a
reentrance problem then we'd need to remove __call, __get, __set,
iterators.....
- type hinting and
NULL
We decided to find a way to handle NULL. Iirc then we settled down on
allowing 'foo(BLA $obj = NULL) which could be easily added.
- type hinting and arrays
We decided that we want typehinting for arrays since that is a very
special kind. Since my array-typehinting patch was considered 'not so
nice' i hope somebody else has a better idea.
- php 5.1 is aiming to increase performance and security => ifsetor
It is nice and easy and fast...only it's name. Well guys come on that's
the stupiest reason to reject. The name is selfspeaking, you're all only
not so used to its name as you are with foreach for now.
- did we came to a conclusion on Rasmus' input filtering yet
Since we said we aim to increase security with 5.1 we should incorporate
that idea/technique in some way.
--
Best regards,
Marcus
Marcus Boerger wrote:
- php 5.1 is aiming to increase performance and security => ifsetor
It is nice and easy and fast...only it's name. Well guys come on that's
the stupiest reason to reject. The name is selfspeaking, you're all only
not so used to its name as you are with foreach for now.
I think ifsetor is a useful shortcut for something people do a lot.
- did we came to a conclusion on Rasmus' input filtering yet
Since we said we aim to increase security with 5.1 we should incorporate
that idea/technique in some way.
I don't think I am going to have it ready that fast. I'll commit
something to pecl soon but I am tied up with some really annoying
time-wasting stuff right now.
-Rasmus
At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
- __toString()
There was a problem with the Zend engine 2.0 that forced us to drop this
feature. Now that we have 2.1 we should check again and readd the feature.
Since PHP is designed to generate string output i think that should be
made as easy as possible. And after learning echo and '.' it is hard to
explain that 'echo $foo . $bar' could result in something different than
'echo $foo, $bar'. Besides if it turned out that there is still a
reentrance problem then we'd need to remove __call, __get, __set,
iterators.....
Yes, I think we could revisit this. It should work right now although I'm
still skeptical about what place to put this and what not. If I recall you
wanted convert_to_string() and all other places to support this, right?
Also, I would like to add serialize/unserialize callbacks for internal
extensions so that they can take part in session handling. Stas has already
started looking into it and it's probably a relatively small patch.
- type hinting and
NULLWe decided to find a way to handle NULL. Iirc then we settled down on
allowing 'foo(BLA $obj = NULL) which could be easily added.
We didn't settle for anything here. We came to the conclusion that we could
not find a good syntax for it and that the syntax you are proposing is
ambiguous.
- type hinting and arrays
We decided that we want typehinting for arrays since that is a very
special kind. Since my array-typehinting patch was considered 'not so
nice' i hope somebody else has a better idea.
My main problem is the implementation. I don't think this is critical for
5.1 at all.
- php 5.1 is aiming to increase performance and security => ifsetor
It is nice and easy and fast...only it's name. Well guys come on that's
the stupiest reason to reject. The name is selfspeaking, you're all only
not so used to its name as you are with foreach for now.
It wasn't only the name but also the implementation. Actually, I was hoping
that the input filter API would resolve this issue once and for all even if
in a bit of a different (and IMO better) way.
- did we came to a conclusion on Rasmus' input filtering yet
Since we said we aim to increase security with 5.1 we should incorporate
that idea/technique in some way.
Yes. It's a good thing but I don't think it has to be in 5.1. We should add
it when everyone feels comfortable with it and Rasmus has time to work on it.
- Still need to integrate PDO into the build system. I emailed Wez about
this. I see this a show stopper for 5.1. Basically I think --with-db should
build both ext/db and ext/pd_db.
Marcus, 5.1 doesn't have to include everything. The way I see it the
current improvements in the code base and PDO make for a great .1 release.
I prefer not making mistakes with features especially when they are issues
which aren't critical (and I really think they aren't).
Andi
- Still need to integrate PDO into the build system. I emailed Wez about
this. I see this a show stopper for 5.1. Basically I think --with-db should
build both ext/db and ext/pd_db.
I already made a start on this last night (PDO is there in HEAD now).
Not sure if I'll have time to tackle the build system over the next
few days (have a lot of work and actual PDO coding to fit in).
I think we still have time to get this working.
--Wez.
At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
- php 5.1 is aiming to increase performance and security => ifsetor
It wasn't only the name but also the implementation. Actually, I was hoping
that the input filter API would resolve this issue once and for all even if
in a bit of a different (and IMO better) way.
This function has more uses than input filtering.
--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
Hello Andi,
- php 5.1 is aiming to increase performance and security => ifsetor
It is nice and easy and fast...only it's name. Well guys come on that's
the stupiest reason to reject. The name is selfspeaking, you're all only
not so used to its name as you are with foreach for now.
AG> It wasn't only the name but also the implementation. Actually, I was hoping
AG> that the input filter API would resolve this issue once and for all even if
AG> in a bit of a different (and IMO better) way.
Input filtering does not solve the problem ifsetor() is designed to
solve. It tackles a small part of it, but ifsetor() is a general purpose
construct that is used for $_GET, $_POST, as well as ANY OTHER array
element or variable in your script.
$x = ifsetor($somearray[$foo][$bar], 0);
Is a lot cleaner than:
$x = isset($somearray[$foo][$bar]) ? $somearray[$foo][$bar] : 0;
--
ifsetor()'s purpose is simple and clear:
To return a variable value if it exists or a default value if it does
not exist WITHOUT generating any error.
Thanks.
--
Best regards,
Jason mailto:jason@ionzoft.com
Hello Andi,
Thursday, February 17, 2005, 8:49:44 PM, you wrote:
At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
- __toString()
There was a problem with the Zend engine 2.0 that forced us to drop this
feature. Now that we have 2.1 we should check again and readd the feature.
Since PHP is designed to generate string output i think that should be
made as easy as possible. And after learning echo and '.' it is hard to
explain that 'echo $foo . $bar' could result in something different than
'echo $foo, $bar'. Besides if it turned out that there is still a
reentrance problem then we'd need to remove __call, __get, __set,
iterators.....
Yes, I think we could revisit this. It should work right now although I'm
still skeptical about what place to put this and what not. If I recall you
wanted convert_to_string() and all other places to support this, right?
Also, I would like to add serialize/unserialize callbacks for internal
extensions so that they can take part in session handling. Stas has already
started looking into it and it's probably a relatively small patch.
Damn i knew i have forgotten something. I had some ideas for that but no
imlementation time. If he wants he could contact me of course :-)
regards
marcus
Hello Andi,
Thursday, February 17, 2005, 8:49:44 PM, you wrote:
At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
- __toString()
There was a problem with the Zend engine 2.0 that forced us to drop this
feature. Now that we have 2.1 we should check again and readd the feature.
Since PHP is designed to generate string output i think that should be
made as easy as possible. And after learning echo and '.' it is hard to
explain that 'echo $foo . $bar' could result in something different than
'echo $foo, $bar'. Besides if it turned out that there is still a
reentrance problem then we'd need to remove __call, __get, __set,
iterators.....
Yes, I think we could revisit this. It should work right now although I'm
still skeptical about what place to put this and what not. If I recall you
wanted convert_to_string() and all other places to support this, right?
For PHP 5.0 we used to have a special conversion make_printable - i guess we
shouldn't go that way again if there's no need and instead simply call the
objects conversion handler that could (again) call __toString() if it is
present. What do you think?
--
Best regards,
Marcus mailto:helly@php.net
- php 5.1 is aiming to increase performance and security => ifsetor
It is nice and easy and fast...only it's name. Well guys come on that's
the stupiest reason to reject. The name is selfspeaking, you're all only
not so used to its name as you are with foreach for now.
I really love this idea a lot, but I hope there will be an ifemptyor() as
well..
Maybe these names could be considered:
"setor" and "emptyor"
setor($foo, "bar");
emptyor($foo, "bar");
or if they won't be call by reference:
$foo = setor($foo, "bar");
$foo = emptyor($foo, "bar");
I really like this idea, and I don't know if it will be by-reference, but if
they would, then I think it would be nice to have them return a boolean
which is False if the alternative was used and True otherwise.
Just my 0.02 euro.
Ron
Ron Korving wrote:
$foo = emptyor($foo, "bar");
I'm not really sure that you'd use this for. Set $foo to either the
original value (if $foo was empty before) or "bar"? Is that empty as in
empty()? So you could end up with null, "", 0, "0", false or "bar"?
- Chris
You're absolutely right... It should've said "notemptyor" :) Very perceptive
;)
Ron
"Christian Schneider" cschneid@cschneid.com wrote in message
news:421500A7.4040209@cschneid.com...
Ron Korving wrote:
$foo = emptyor($foo, "bar");
I'm not really sure that you'd use this for. Set $foo to either the
original value (if $foo was empty before) or "bar"? Is that empty as in
empty()? So you could end up with null, "", 0, "0", false or "bar"?
- Chris
Marcus,
a minor but important issue (to me, at least) is the consistent use of
SPL exceptions throughout OOP based extensions...
"Marcus Boerger" helly@php.net wrote in message
news:59089102.20050217201853@marcus-boerger.de...
Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
A little offtopic, but I'm still curious.. is multiple inheritence something
we might see appearing in 5.2 ?
Ron
"Marcus Boerger" helly@php.net wrote in message
news:59089102.20050217201853@marcus-boerger.de...
Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
- __toString()
There was a problem with the Zend engine 2.0 that forced us to drop this
feature. Now that we have 2.1 we should check again and readd the
feature.
Since PHP is designed to generate string output i think that should be
made as easy as possible. And after learning echo and '.' it is hard to
explain that 'echo $foo . $bar' could result in something different than
'echo $foo, $bar'. Besides if it turned out that there is still a
reentrance problem then we'd need to remove __call, __get, __set,
iterators.....
- type hinting and
NULLWe decided to find a way to handle NULL. Iirc then we settled down on
allowing 'foo(BLA $obj = NULL) which could be easily added.
- type hinting and arrays
We decided that we want typehinting for arrays since that is a very
special kind. Since my array-typehinting patch was considered 'not so
nice' i hope somebody else has a better idea.
- php 5.1 is aiming to increase performance and security => ifsetor
It is nice and easy and fast...only it's name. Well guys come on that's
the stupiest reason to reject. The name is selfspeaking, you're all only
not so used to its name as you are with foreach for now.
- did we came to a conclusion on Rasmus' input filtering yet
Since we said we aim to increase security with 5.1 we should incorporate
that idea/technique in some way.--
Best regards,
Marcus
A little offtopic, but I'm still curious.. is multiple inheritence something
we might see appearing in 5.2 ?
No.
-adam
--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!
Hello Ron,
Thursday, February 17, 2005, 11:10:55 PM, you wrote:
A little offtopic, but I'm still curious.. is multiple inheritence something
we might see appearing in 5.2 ?
Definitively not.
You may raise this question prior to PHP 6,
However still getting the answer 'no'.
The concept simply doesn't match with PHP
and since we have multiple inheritance for
interfaces that's enough.
Best regards,
Marcus mailto:helly@php.net
Okay, I'll accept the "no" of course, but I am curious.. Is it an
implementation problem with the current engine? Saying that using interfaces
discards the MI issue is nonsense imho, because I can't implement any
functions in an interface.
So why is this such a big "no"? Implementation problem or is it against a
certain PHP philosophy?
Ron
"Marcus Boerger" helly@php.net wrote in message
news:1334163369.20050217233233@marcus-boerger.de...
Hello Ron,
Thursday, February 17, 2005, 11:10:55 PM, you wrote:
A little offtopic, but I'm still curious.. is multiple inheritence
something
we might see appearing in 5.2 ?Definitively not.
You may raise this question prior to PHP 6,
However still getting the answer 'no'.
The concept simply doesn't match with PHP
and since we have multiple inheritance for
interfaces that's enough.Best regards,
Marcus mailto:helly@php.net
Hello,
Speaking of these matters, how about implementing functions within
interfaces?
--
Best regards,
Jason mailto:jason@ionzoft.com
Thursday, February 17, 2005, 5:46:08 PM, you wrote:
RK> Okay, I'll accept the "no" of course, but I am curious.. Is it an
RK> implementation problem with the current engine? Saying that using interfaces
RK> discards the MI issue is nonsense imho, because I can't implement any
RK> functions in an interface.
RK> So why is this such a big "no"? Implementation problem or is it against a
RK> certain PHP philosophy?
RK> Ron
RK> "Marcus Boerger" helly@php.net wrote in message
RK> news:1334163369.20050217233233@marcus-boerger.de...
Hello Ron,
Thursday, February 17, 2005, 11:10:55 PM, you wrote:
A little offtopic, but I'm still curious.. is multiple inheritence
RK> something
we might see appearing in 5.2 ?Definitively not.
You may raise this question prior to PHP 6,
However still getting the answer 'no'.
The concept simply doesn't match with PHP
and since we have multiple inheritance for
interfaces that's enough.Best regards,
Marcus mailto:helly@php.net
Hello,
Speaking of these matters, how about implementing functions within
interfaces?
That is by definition impossible. Instead of being an interface, it
would be an implementation.
-ryan
--
Best regards,
Jason mailto:jason@ionzoft.comThursday, February 17, 2005, 5:46:08 PM, you wrote:
RK> Okay, I'll accept the "no" of course, but I am curious.. Is it an
RK> implementation problem with the current engine? Saying that using
interfaces
RK> discards the MI issue is nonsense imho, because I can't implement
any
RK> functions in an interface.RK> So why is this such a big "no"? Implementation problem or is it
against a
RK> certain PHP philosophy?RK> Ron
RK> "Marcus Boerger" helly@php.net wrote in message
RK> news:1334163369.20050217233233@marcus-boerger.de...Hello Ron,
Thursday, February 17, 2005, 11:10:55 PM, you wrote:
A little offtopic, but I'm still curious.. is multiple inheritence
RK> something
we might see appearing in 5.2 ?Definitively not.
You may raise this question prior to PHP 6,
However still getting the answer 'no'.
The concept simply doesn't match with PHP
and since we have multiple inheritance for
interfaces that's enough.Best regards,
Marcus mailto:helly@php.net--
"Ron Korving" r.korving@xit.nl wrote in message
news:20050217224614.21062.qmail@lists.php.net...
So why is this such a big "no"? Implementation problem or is it against a
certain PHP philosophy?
Just do a google search on the cons of MI (narrow it to C++ if you please).
it's much more a philosophical issue, although i'd still raise practicality
issues over efficiency in a scripting environment.
not to mention numerous implementation issues which are too easy to get
wrong.
Ron
Ron Korving wrote:
is multiple inheritence something we might see appearing in 5.2 ?
The concept of Multiple Inheritance should be left to programming
languages that can properly deal with it (by letting the programmer
influence how inheritance collision can be resolved, for instance).
Multiple Inheritance is one feature that I do not want to see in PHP.
And since we have interfaces (for which we allow multiple inheritance) I
do not see a need for Multiple Inheritance; interfaces are a much
cleaner way to model.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Sebastian Bergmann wrote:
Ron Korving wrote:
is multiple inheritence something we might see appearing in 5.2 ?
The concept of Multiple Inheritance should be left to programming
languages that can properly deal with it (by letting the programmer
influence how inheritance collision can be resolved, for instance).Multiple Inheritance is one feature that I do not want to see in PHP.
And since we have interfaces (for which we allow multiple inheritance) I
do not see a need for Multiple Inheritance; interfaces are a much
cleaner way to model.
Also we have __call() to help you in not having to cut and paste
implementations around.
regards,
Lukas
Nope. Interfaces is supported as an alternative approach to MI.
Andi
At 11:10 PM 2/17/2005 +0100, Ron Korving wrote:
A little offtopic, but I'm still curious.. is multiple inheritence something
we might see appearing in 5.2 ?Ron
"Marcus Boerger" helly@php.net wrote in message
news:59089102.20050217201853@marcus-boerger.de...Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
- __toString()
There was a problem with the Zend engine 2.0 that forced us to drop this
feature. Now that we have 2.1 we should check again and readd the
feature.
Since PHP is designed to generate string output i think that should be
made as easy as possible. And after learning echo and '.' it is hard to
explain that 'echo $foo . $bar' could result in something different than
'echo $foo, $bar'. Besides if it turned out that there is still a
reentrance problem then we'd need to remove __call, __get, __set,
iterators.....
- type hinting and
NULLWe decided to find a way to handle NULL. Iirc then we settled down on
allowing 'foo(BLA $obj = NULL) which could be easily added.
- type hinting and arrays
We decided that we want typehinting for arrays since that is a very
special kind. Since my array-typehinting patch was considered 'not so
nice' i hope somebody else has a better idea.
- php 5.1 is aiming to increase performance and security => ifsetor
It is nice and easy and fast...only it's name. Well guys come on that's
the stupiest reason to reject. The name is selfspeaking, you're all only
not so used to its name as you are with foreach for now.
- did we came to a conclusion on Rasmus' input filtering yet
Since we said we aim to increase security with 5.1 we should incorporate
that idea/technique in some way.--
Best regards,
Marcus
Marcus Boerger wrote:
Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
I would like to highlight again that getting the pear installer version
1.4 will also be important. getting this into php 5.1 will improve the
life for pecl considerably!
Greg has been working really hard on getting this stuff far along and
now we need testers just like PDO to get this stuff stable. Especially
with Wez being very busy with PDO its important that other people form
internals step up to ensure that all the new features for PECL work well
in the real world.
regards,
Lukas
Lukas Smith wrote:
Marcus Boerger wrote:
Hello internals,
before we rush into another version, how about clearing some open
issues
that were explicitly relayed from 5.0 to 5.1.I would like to highlight again that getting the pear installer version
1.4 will also be important. getting this into php 5.1 will improve the
life for pecl considerably!Greg has been working really hard on getting this stuff far along and
now we need testers just like PDO to get this stuff stable. Especially
with Wez being very busy with PDO its important that other people form
internals step up to ensure that all the new features for PECL work well
in the real world.
I plan to release PEAR 1.4.0a1 this week. Although this version should
not be included in PHP 5.1 beta 1, I expect that barring any disasters,
the first beta should be ready by PHP 5.1 beta 2. In the mean time, the
release of a1 will give me a chance to fine-tune the install-pear.php
script and other factors that go into the release process.
What makes more sense: sticking with PEAR 1.3.5 for PHP 5.1 stable, or
trying to get PEAR 1.4.0 stable into PHP 5.1 stable?
If 5.1 stable is planned for no sooner than May/June, this is no
problem. Earlier than that might be pushing it, but who knows, the
current release is very stable, it is only alpha because features may
need to change after users have a chance to try them out.
Greg