On 6/2/11 6:44 PM, Rasmus Lerdorf wrote:
I'm on a plane headed for Rio, so I can't test your patch for a while. If you
have checked it on a couple of different systems, commit it, and we will work
out any issues during the early stages of getting 5.4 out the door.
-Rasmus
I'll test it on
Hannes Magnusson writes:
> On Thu, Jun 2, 2011 at 21:03, Richard Riley wrote:
>>
>> Could some kind soul advise me on how to install php docs localy and
>> have the excellent patterns search work based on an sqllite database?
>
> https://wiki.php.net/doc/phd/view
>
Just as a side note on this i
I'm on a plane headed for Rio, so I can't test your patch for a while. If you
have checked it on a couple of different systems, commit it, and we will work
out any issues during the early stages of getting 5.4 out the door.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To uns
Hi,
A while ago I submitted a patch to allow session_set_save_handler() to
accept a class, and support the inheritance of the default session
handler's methods.
The RFC has a more detailed description and the current patch:
https://wiki.php.net/rfc/session-oo
Changes since this was last discusse
On 05/15/2011 02:45 AM, Rasmus Lerdorf wrote:
As you may have noticed, I have fixed the autoconf stuff to work with autoconf 2.60+
in PHP_5_4 and trunk. In the past I have tried to make it support both <2.60 and
>=2.60 at the same time and it never worked. autoconf 2.60 was released in June
2011/6/2 Felipe Pena
> Hi,
>
> 2011/6/2 Michael Maclean
>
>> On 02/06/11 18:20, Gustavo Lopes wrote:
>>
>>> Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
>>> escreveu:
>>>
>>> Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the rec
Hi,
2011/6/2 Michael Maclean
> On 02/06/11 18:20, Gustavo Lopes wrote:
>
>> Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
>> escreveu:
>>
>> Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
>>> at a time please ;-) And for the record I am all for killing
>>> TSRMLS_
State the case for JSON in a separate RFC and progress will be made, but I
think there is a fundamental mistake here: serialization formats are the
*means* for interoperability, not the ends.
The only way I see JSONy syntax would help is if PHP code —with JSONy
syntax— would be parsed by a JSON pa
+1 on E_NOTICE
02.06.2011 19:13 пользователь "Ilia Alshanetsky"
написал:
> I like the idea of an error message when this happens, but as few
> other people in the thread had mentioned, I think it should be a
> warning (E_WARNING) because the conversion results in data loss
> (content of the array
Nathan Nobbe writes:
> On Thu, Jun 2, 2011 at 4:01 PM, Philip Olson wrote:
>
>>
>> On Jun 2, 2011, at 2:46 PM, Richard Riley wrote:
>>
>> > Hannes Magnusson writes:
>> >
>> >> On Thu, Jun 2, 2011 at 21:03, Richard Riley
>> wrote:
>> >>>
>> >>> Could some kind soul advise me on how to install p
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
Is there any advantage in killing it as opp
On Thu, Jun 2, 2011 at 4:01 PM, Philip Olson wrote:
>
> On Jun 2, 2011, at 2:46 PM, Richard Riley wrote:
>
> > Hannes Magnusson writes:
> >
> >> On Thu, Jun 2, 2011 at 21:03, Richard Riley
> wrote:
> >>>
> >>> Could some kind soul advise me on how to install php docs localy and
> >>> have the e
On Jun 2, 2011, at 2:46 PM, Richard Riley wrote:
> Hannes Magnusson writes:
>
>> On Thu, Jun 2, 2011 at 21:03, Richard Riley wrote:
>>>
>>> Could some kind soul advise me on how to install php docs localy and
>>> have the excellent patterns search work based on an sqllite database?
>>
>> htt
Hannes Magnusson writes:
> On Thu, Jun 2, 2011 at 21:03, Richard Riley wrote:
>>
>> Could some kind soul advise me on how to install php docs localy and
>> have the excellent patterns search work based on an sqllite database?
>
> https://wiki.php.net/doc/phd/view
>
> Please ask any followup ques
On Thu, Jun 2, 2011 at 21:03, Richard Riley wrote:
>
> Could some kind soul advise me on how to install php docs localy and
> have the excellent patterns search work based on an sqllite database?
https://wiki.php.net/doc/phd/view
Please ask any followup questions on the proper mailinglist,
php.
On Thu, Jun 2, 2011 at 22:24, Stas Malyshev wrote:
> I'd like to set up a vote for the undecided TODO features on wiki.php.net,
> anybody could help me with setting up the voting module there if there's
> such thing on the wiki? Or set me up with the access to wiki machine and
> I'll install it :)
Sounds fine to me.
On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev wrote:
> Hi!
>
> We're having pretty lively discussion on the list, twitter and other places,
> but let's not forget the big goal of 5.4 :)
>
> 1. First of all, the official business. Any objections to the RMs for 5.4
> being:
> St
On Thu, Jun 2, 2011 at 10:19 PM, Sean Coates wrote:
>>> If people vote on this now, will further discussion about how this SHOULD
>>> work be shut down with "we already voted on this"?
>> which other discussions do you wish? Json is clearly not an option and
>> not enough people (but a couple) lik
hi,
I have no objection as long as the RFC for the release process is
adopted before we do any 5.4 releases, as stated earlier, this is the
only way to put ourself on the safe side.
Cheers,
On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev wrote:
> Hi!
>
> We're having pretty lively discussion on
On Jun 2, 2011, at 1:19 PM, Sean Coates wrote:
>>> If people vote on this now, will further discussion about how this SHOULD
>>> work be shut down with "we already voted on this"?
>> which other discussions do you wish? Json is clearly not an option and
>> not enough people (but a couple) likes o
Hi!
We're having pretty lively discussion on the list, twitter and other
places, but let's not forget the big goal of 5.4 :)
1. First of all, the official business. Any objections to the RMs for
5.4 being:
Stas Malyshev (stas)
David Soria Parra (dsp)
If not, we'll be the 5.4 RM team.
2. Ca
Stop spreading FUD, please.
It's no different than writing json_decode("ä\u0123").
Your statement, "the stuff in bar in UTF-8" is wrong. The \u0123
escape sequence is a representation of a Unicode character, not the
character itself. This representation can be encoded in any
ASCII-compatible enco
>> If people vote on this now, will further discussion about how this SHOULD
>> work be shut down with "we already voted on this"?
> which other discussions do you wish? Json is clearly not an option and
> not enough people (but a couple) likes or wants it.
>
> The RFC is about short array syntax
Hi!
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
Just to be clear on my vote, I'd really like to have [], and I think we
MUST keep => there, but I don't care either way about ':'.
--
Stanislav Malyshev, Software Architect
SugarCRM:
> There's no need to be rude. If you can't make your point without
> attacking people, then you need a better argument.
If you can't make your point without misusing terms to the point of
making yourself untrustworthy on that level alone, stop trying to
argue.
The "lazy programmer" axiom
On 6/2/11 11:08 AM, Pierre Joye wrote:
reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
I don't really care which syntax wins as long as one of them gets rolled in.
Brian.
--
PHP Internals - PHP Runtime De
so put +1 on both :D
On Thu, Jun 2, 2011 at 9:37 PM, Brian Moon wrote:
> On 6/2/11 11:08 AM, Pierre Joye wrote:
>>
>> reminder #2, pls do vote here:
>> https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
>> not choose which syntax they want.
>
> I don't really care which syntax
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.
The RFC is about short array syntax and as far as I can see there is
already a clear consensus for one of the proposed new syntax.
Cheers,
On Thu, Jun 2, 2011 at 9:53 PM, Se
> pls do vote here:
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
> not choose which syntax they want.
If people vote on this now, will further discussion about how this SHOULD work
be shut down with "we already voted on this"?
S
Could some kind soul advise me on how to install php docs localy and
have the excellent patterns search work based on an sqllite database?
I have a local install but only full function names match but something
like
http://localhost/phpman/manual-lookup.php?pattern=str
does not. A quick google
No we can't; I already explained why in another email last night. Copypasta:
json_decode() can deal with Unicode sequences because decodes to UTF-8. That is
not possible in a language construct:
What if I do this, in a latin1 encoded file:
$x = {foo: "ä", bar: "\u0123"}
Should that then give m
There's no need to be rude. If you can't make your point without attacking
people, then you need a better argument.
"JSON" in this case just means a simple object notation using {, [, and :. You
know that. Yes, we're all abusing the term, just like we all abuse "AJAX",
regardless of the fact th
> Also matter of opinion, and of experience. Apart from the fact that
> my use of jQuery amounts to a few weeks out of a (mumble)-year
> programming career, no I don't use pure JSON for it - Javascript
> object literals, yes, but not pure JSON.
It's not just you. The claim that people
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
Is there any advantage in killing it as opposed to simply not use it?
You will be
On Thu, Jun 2, 2011 at 7:10 PM, Ilia Alshanetsky wrote:
> Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
> at a time please ;-)
I mean in this patch only. This patch adds a couple, so it can be done
at the same time (afair these functions are not used heavily outside
the en
I like the idea of an error message when this happens, but as few
other people in the thread had mentioned, I think it should be a
warning (E_WARNING) because the conversion results in data loss
(content of the array is replaced with "Array" string).
On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAER
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
On Thu, Jun 2, 2011 at 6:04 PM, Pierre Joye wrote:
> hi Ilia,
>
> I would suggest to kill the TSRMLS_FETCH while being at it. They are
> horribly slow a
On 05/31/2011 03:30 PM, Ilia Alshanetsky wrote:
Since we are on the topic of reviewing past RFCs for 5.4, can we take
another look at the Zend Signals RFC:
https://wiki.php.net/rfc/zendsignals
The patch is solid (have been using it in production for quite some
time) and improvement is quite h
2011/6/2 Reindl Harald :
> Am 02.06.2011 16:24, schrieb Marcel Esser:
>> I am not convinced that making this an error is a good idea.
>>
>> If I receive a $_GET/$_POST value that I expect to be a string value, but I
>> actually received an array, this would
>> mean I need to now explicitly check f
reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
Thanks,
On Tue, May 31, 2011 at 8:42 PM, Brian Moon wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
--
Pierre
@pierrejoye | http://blog.thepimp.net |
Could we first go out with fully JSON compatible version for 5.4?
and then later decide the => stuff based on how that worked.
Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.
Martin Scotta
On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates
hi Ilia,
I would suggest to kill the TSRMLS_FETCH while being at it. They are
horribly slow and a couple of them can be replaced by the
TSRMLS_DC/CC, if I'm not mistaken.
For the windows side, I do not have the time to do the equivalent, so
if you commit the patch to trunk first so I can fix the
may I suggest to both of you to continue this rant off line please?
The initial question was rather simple and only about this specific
case. And we seem to agree on the necessity to have a notice/warning
here. That's the maximum we can do at this stage, both for 5.3 and
5.4.
On Thu, Jun 2, 2011
I'm pretty sure you've never seen my code, so I am not going to comment
on that.
However, speaking not just for myself, two ternary operations and two
functions calls to just prevent a stoppage code of execution, never mind
input filtering for a second, is not entirely reasonable considering t
Am 02.06.2011 17:01, schrieb Peter Lind:
> On 2 June 2011 16:50, Reindl Harald wrote:
>> Am 02.06.2011 16:24, schrieb Marcel Esser:
>>> I am not convinced that making this an error is a good idea.
>>>
>>> If I receive a $_GET/$_POST value that I expect to be a string value, but I
>>> actually re
I agree entirely.
Let me go ahead and fix these three billion man hours worth of code in
use through-out the world. I'll be back shortly.
- M.
On 6/2/2011 11:19 AM, Reindl Harald wrote:
first rule of programming: sanitize user input
if you EXPECT no array catch it
Am 02.06.2011 16:54, schri
On Jun 2, 2011, at 8:01 AM, Peter Lind wrote:
> On 2 June 2011 16:50, Reindl Harald wrote:
>>
>>
>> Am 02.06.2011 16:24, schrieb Marcel Esser:
>>> I am not convinced that making this an error is a good idea.
>>>
>>> If I receive a $_GET/$_POST value that I expect to be a string value, but I
first rule of programming: sanitize user input
if you EXPECT no array catch it
Am 02.06.2011 16:54, schrieb Marcel Esser:
> You don't need a form to receive bad user input.
>
> Also, I am not really inclined to write $v = isset($_POST['x']) ?
> (is_array($_POST['x']) ? 'something else that
> mak
> Am 02.06.2011 14:56, schrieb Rune Kaagaard:
>>> this conversion should never happen and throw a fatal error since this
>>> action is destructive to data and never useful nor will warnings/notices
>>> helps in the real world
I agree totally that such a conversion should never happen. If we could
On 2 June 2011 16:50, Reindl Harald wrote:
>
>
> Am 02.06.2011 16:24, schrieb Marcel Esser:
>> I am not convinced that making this an error is a good idea.
>>
>> If I receive a $_GET/$_POST value that I expect to be a string value, but I
>> actually received an array, this would
>> mean I need to
You don't need a form to receive bad user input.
Also, I am not really inclined to write $v = isset($_POST['x']) ?
(is_array($_POST['x']) ? 'something else that makes more sense' :
$_POST['x'] ) : null; just to avoid catching a fatal.
- M.
On 6/2/2011 10:50 AM, Reindl Harald wrote:
Am 02.
Am 02.06.2011 16:24, schrieb Marcel Esser:
> I am not convinced that making this an error is a good idea.
>
> If I receive a $_GET/$_POST value that I expect to be a string value, but I
> actually received an array, this would
> mean I need to now explicitly check for it, since it will stop the
The choice between E_WARNING and E_NOTICE is simple if we look at the
definitions of the levels
(http://php.net/manual/en/errorfunc.constants.php).
E_NOTICE is defined as "Run-time notices. Indicate that the script
encountered something that could indicate an error, but could also
happen in the no
+1
Sent from my iPhone
On Jun 2, 2011, at 4:19 AM, Patrick ALLAERT wrote:
> Hi,
>
> I would like to introduce an E_NOTICE when an array is silently
> converted to a string.
> This isn't very useful as it constantly produces the following string:
> "Array" and in most of the case, this is a sign
Hi all,
I've just read the Release Process RFC
(https://wiki.php.net/rfc/releaseprocess) and have a suggestion
regarding this part of the version numbering scheme: "x.y.z to
x.y+1.z".
I believe "x.y.z to x.y+1.0" is much more clear and common and less of
a departure from the current numbering sc
On Thu, 02 Jun 2011 15:38:00 +0200, Brian Moon wrote:
I like this for the current stable branch, no bc impact and gives a
way to detect such mistakes (not ideal but better than nothing).
On Thu, Jun 2, 2011 at 12:11 PM, Patrick
ALLAERT wrote:
Hi,
I would like to introduce an E_NOTICE when
I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value,
but I actually received an array, this would mean I need to now
explicitly check for it, since it will stop the runtime otherwise. Example:
http://home.sweet.home
On Thu, Jun 02, 2011 at 04:07:25PM +0200, Patrick ALLAERT wrote:
> Not true. Here is a valid example that would break after implementing
> this as en error.
>
> if ("$x" == "Array") {
> array_walk( $x, "print_r" );
> }
>
> I'm not saying that this is good code, I'm only saying that this woul
Even though I have quite mixed feelings about this, I think I am
finally ready to cast
my +1. Over the past few days I've discussed with a few people and
noticed the need, or rather a strong desire to have this feature in
PHP and most people seemed to care only little about how it was done
as long
2011/6/2 Brian Moon :
>> I like this for the current stable branch, no bc impact and gives a
>> way to detect such mistakes (not ideal but better than nothing).
>>
>> On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT
>> wrote:
>>>
>>> Hi,
>>>
>>> I would like to introduce an E_NOTICE when an array
2011/6/2 Reindl Harald :
>
>
> Am 02.06.2011 15:04, schrieb John LeSueur:
>> On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald wrote:
>> First, I agree that converting to json/imploding would be a bad idea.
>> There's no guarantee that the developer wanted to use the array in that way,
>> or even
>> t
I like this for the current stable branch, no bc impact and gives a
way to detect such mistakes (not ideal but better than nothing).
On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't ver
2011/6/2 Rune Kaagaard :
>> this conversion should never happen and throw a fatal error since this
>> action is destructive to data and never useful nor will warnings/notices
>> helps in the real world
>
> Unlike i.e. Python its really not the PHP way to go fatal on the
> developer during weird typ
hi,
I like this for the current stable branch, no bc impact and gives a
way to detect such mistakes (not ideal but better than nothing).
Cheers,
On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT wrote:
> Hi,
>
> I would like to introduce an E_NOTICE when an array is silently
> converted to a str
2011/6/2 Hannes Magnusson :
> How about making it useful rather then just throwing an notice?
> Recursive implode maybe? Or json/php serialized? :)
As already mentioned, that would be a much bigger BC break which would
requires RFC, voting, ...
Not that I am against, the thing is that it is diffi
E_NOTICE. The current conversion is so completely useless, that whenever it
happens, it is almost certainly an error. Any implicit conversion here would
perpetuate problems in code that was probably wrong in the first place.
John Crenshaw
Priacta, Inc.
-Original Message-
From: John LeS
<3 yes please.
Sent from my iBrain, powered by Panda.
On Jun 2, 2011, at 6:19 AM, "Patrick ALLAERT" wrote:
> Hi,
>
> I would like to introduce an E_NOTICE when an array is silently
> converted to a string.
> This isn't very useful as it constantly produces the following string:
> "Array" and i
Am 02.06.2011 15:04, schrieb John LeSueur:
> On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald wrote:
> First, I agree that converting to json/imploding would be a bad idea.
> There's no guarantee that the developer wanted to use the array in that way,
> or even
> that he wanted to use the array at
On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald wrote:
>
>
> Am 02.06.2011 13:54, schrieb Hannes Magnusson:
> > On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT
> wrote:
> >> Hi,
> >>
> >> I would like to introduce an E_NOTICE when an array is silently
> >> converted to a string.
> >> This isn't very
Am 02.06.2011 14:56, schrieb Rune Kaagaard:
>> this conversion should never happen and throw a fatal error since this
>> action is destructive to data and never useful nor will warnings/notices
>> helps in the real world
>
> Unlike i.e. Python its really not the PHP way to go fatal on the
> deve
> this conversion should never happen and throw a fatal error since this
> action is destructive to data and never useful nor will warnings/notices
> helps in the real world
Unlike i.e. Python its really not the PHP way to go fatal on the
developer during weird type conversions. I'm also +1 on the
Am 02.06.2011 13:54, schrieb Hannes Magnusson:
> On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT wrote:
>> Hi,
>>
>> I would like to introduce an E_NOTICE when an array is silently
>> converted to a string.
>> This isn't very useful as it constantly produces the following string:
>> "Array" and in
Em Thu, 02 Jun 2011 12:54:10 +0100, Hannes Magnusson
escreveu:
On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT
wrote:
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
"Array" and in m
I don't there's a good general case for this. I'd +1 on throwing E_NOTICE.
Hannes
On 2 June 2011 13:54, Hannes Magnusson wrote:
>
> How about making it useful rather then just throwing an notice?
> Recursive implode maybe? Or json/php serialized? :)
>
> -Hannes
>
> --
> PHP Internals - PHP Runt
On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT wrote:
> Hi,
>
> I would like to introduce an E_NOTICE when an array is silently
> converted to a string.
> This isn't very useful as it constantly produces the following string:
> "Array" and in most of the case, this is a sign of an error.
How abou
> Am 02.06.2011 13:15, schrieb Peter Lind:
>
> Anyway, I'll stop it here, as I doubt I'll convince you of anything
> (and vice versa).
>
> Just one thing to add: thanks for the work on PHP :) Much appreciated.
>
I think/hope that this RFC is a step in the right direction to make the
release pro
On Thu, Jun 2, 2011 at 1:15 PM, Peter Lind wrote:
> On 2 June 2011 13:03, Pierre Joye wrote:
>> On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind wrote:
>>> On 2 June 2011 12:40, Pierre Joye wrote:
>>>
>>> *snip*
>>>
No, it is the same that what we proposed. What we proposed is that
eve
On 2 June 2011 13:03, Pierre Joye wrote:
> On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind wrote:
>> On 2 June 2011 12:40, Pierre Joye wrote:
>>
>> *snip*
>>
>>>
>>> No, it is the same that what we proposed. What we proposed is that
>>> every release is actually a LTS release. What Ubuntu uses works
On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind wrote:
> On 2 June 2011 12:40, Pierre Joye wrote:
>
> *snip*
>
>>
>> No, it is the same that what we proposed. What we proposed is that
>> every release is actually a LTS release. What Ubuntu uses works fine
>> for distros given that it is a distro with
On 2 June 2011 12:40, Pierre Joye wrote:
*snip*
>
> No, it is the same that what we proposed. What we proposed is that
> every release is actually a LTS release. What Ubuntu uses works fine
> for distros given that it is a distro with an insane amount of totally
> unrelated projects they distrib
2011/6/2 Ford, Mike :
>> -Original Message-
>> From: John Crenshaw [mailto:johncrens...@priacta.com]
>> Sent: 01 June 2011 23:00
>>
> skip
>
>> 4. The format most consistent with other languages is JSON
>
> Again, matter of experience. Last time I counted, I'd used upward of
> 30 different
On Thu, Jun 2, 2011 at 12:08 PM, Sebastian Bergmann wrote:
>> The current version is aimed to give early access to new features, to
>> avoid cases like traits which take years to come out while a bit more
>> conservative users (and maybe distros) may stay on the LTS.
>
> Traits is a really good
On Thu, Jun 2, 2011 at 11:51 AM, Peter Lind wrote:
> On 2 June 2011 10:23, Pierre Joye wrote:
>> On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind wrote:
>>
>>> Sorry for jumping into the thread, but I couldn't help noting that you seem
>>> confused about the distro suggestion. I think Ubuntu was the e
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
"Array" and in most of the case, this is a sign of an error.
Let me know about your feelings.
Patch implementing that behavior change:
Am 01.06.2011 14:44, schrieb Johannes Schlüter:
> I mentioned this before: I like the Ubuntu model:
>
> * One development branch for the next version
> * One current version
> * One "long term" supported version
+1
> The current version is aimed to give early access to new features, to
> avoid
Am 02.06.2011 12:19, schrieb Patrick ALLAERT:
> I would like to introduce an E_NOTICE when an array is silently
> converted to a string.
what is new?
a fatal error would be better here
error_reporting = E_ALL | E_STRICT
google: "Notice: Array to string conversion"
signature.asc
Description: Op
On Thu, Jun 02, 2011 at 12:19:36PM +0200, Patrick ALLAERT wrote:
> Hi,
>
> I would like to introduce an E_NOTICE when an array is silently
> converted to a string.
> This isn't very useful as it constantly produces the following string:
> "Array" and in most of the case, this is a sign of an error
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
"Array" and in most of the case, this is a sign of an error.
Let me know about your feelings.
Patch implementing that behavior change:
On 2 June 2011 10:23, Pierre Joye wrote:
> On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind wrote:
>
>> Sorry for jumping into the thread, but I couldn't help noting that you seem
>> confused about the distro suggestion. I think Ubuntu was the example, and
>> there's nothing random at all about their r
> -Original Message-
> From: John Crenshaw [mailto:johncrens...@priacta.com]
> Sent: 01 June 2011 23:00
>
> Spot on. It has nothing to do with extra typing (and that sort of
> design is part of what ruined Ruby). My fingers move plenty fast and
> if extra characters make things more safe o
Am 02.06.2011 11:36, schrieb David Muir:
> That said, I'm not sure if an LTS is a good idea. One of the biggest
> frustrations for me as a developer is hosts taking forever to upgrade to
> newer versions of PHP. Most hosts I've seen are still on 5.2, and some
> don't seem to have plans of upgradin
On 02/06/11 17:23, Pierre Joye wrote:
> On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind wrote:
>
>> Sorry for jumping into the thread, but I couldn't help noting that you seem
>> confused about the distro suggestion. I think Ubuntu was the example, and
>> there's nothing random at all about their relea
On Thu, Jun 02, 2011 at 08:21:37AM +, Ford, Mike wrote:
> > Back on the soapbox. All of this is just to reduce typing "array" (5
> > characters) before things?
>
> Not here. For me, the shorter syntax is simply an order of magnitude
> more readable. I really don't care how much typing is invo
On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind wrote:
> Sorry for jumping into the thread, but I couldn't help noting that you seem
> confused about the distro suggestion. I think Ubuntu was the example, and
> there's nothing random at all about their release process. There are fixed
> timelines and
> -Original Message-
> From: Michael Shadle [mailto:mike...@gmail.com]
> Sent: 01 June 2011 21:37
>
> On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye
> wrote:
>
> > I modified the vote page, pls move your votes to the desired
> syntax
> > (or global -1)
>
> This is a good idea to group thin
2011/6/2 Sanford Whiteman
> > I don't think anyone cares about JSON for the sake of being perfect
> > JSON, I didn't intend to give that impression.
>
> Then you should stop saying "pure JSON" and "true JSON" constantly!
>
> > I'm only hoping for something that generally works on par with all
>
On Jun 1, 2011, at 7:35 AM, Derick Rethans wrote:
>> But only if you keep it consistent, PHP has always been using => for
>> key/val association, I don't see any reason to suddenly provide "key":
>> "val", unless what you want is to confuse people.
> Yes, definitely "=>" vs. ":" in any case.
+1 t
On Thu, Jun 2, 2011 at 12:09 AM, Sean Coates wrote:
> > Now, the only reason I would personally support the array shortcut is
> > if it was an implementation of JSON. I know that's not on the table
> > here
>
> I don't think anything is officially off the table, unless we forego
> discussion.
>
98 matches
Mail list logo
