...
> Running PHP on the JVM doesn't mean making PHP more like Java. It
> just means running the PHP language on a platform with a lot of
> benefits and advantages, and given the differences in engineering
> resources dedicated to each, one that's likely to continue to
> improve a lot faster than t
On Tue, May 31, 2011 at 2:07 AM, Tom Samplonius wrote:
>
> > > How has Unicode been lost?
>
> >
> http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
>
> Well, that explains how that particular project melted down, but what
> Unicode features did
Hi!
responsible for, I'm much more interested in developing less-buggy
applications faster, leveraging other people's frameworks instead of
reinventing the wheel (hence my interest in Java), improving
monitoring and deployment, etc.
It may be possible to make PHP source compile into JVM byteco
On Tue, Jul 28, 2009 at 10:41, Moriyoshi Koizumi wrote:
> I set up a RFC page for this in wiki.php.net. Here it goes:
> http://wiki.php.net/rfc/altmbstring
So.. Shouldn't we try to get this into PHP5.4?
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
Hi!
I set up a RFC page for this in wiki.php.net. Here it goes:
http://wiki.php.net/rfc/altmbstring
So.. Shouldn't we try to get this into PHP5.4?
Is it ready? Maybe have it as a PECL extension?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext.
> > The presentation implied that there was vast goals for the project,
> > including a lot of localization features. It seems like some of the
> > smaller features can be worked into a Son-of-Unicode project, and
> > maybe rolled into 5.5?
>
> it would be a good thing, but nobody stepped up for
On Tue, May 31, 2011 at 09:44, Stas Malyshev wrote:
> Hi!
>
>>> I set up a RFC page for this in wiki.php.net. Here it goes:
>>> http://wiki.php.net/rfc/altmbstring
>>
>> So.. Shouldn't we try to get this into PHP5.4?
>
> Is it ready? Maybe have it as a PECL extension?
I was under the impression
Hi!
I was under the impression it was a drop-in-replacement, so a pecl ext
doesn't make much sense.
I'd say if it's a drop-in PECL ext may still make sense - you don't
compile in the old one but use the PECL one instead. Wouldn't it work?
--
Stanislav Malyshev, Software Architect
SugarCRM:
On Tue, May 31, 2011 at 10:42 AM, Stas Malyshev wrote:
> Hi!
>
>
> I was under the impression it was a drop-in-replacement, so a pecl ext
>>
> doesn't make much sense.
>
> I'd say if it's a drop-in PECL ext may still make sense - you don't compile
> in the old one but use the PECL one instead. Wo
On Tue, May 31, 2011 at 9:58 AM, Tom Samplonius wrote:
>
> > > The presentation implied that there was vast goals for the project,
> > > including a lot of localization features. It seems like some of the
> > > smaller features can be worked into a Son-of-Unicode project, and
> > > maybe rolled i
> > The PHP Wikipedia page is wrong about this too, and states that
> > addslashes() can be used instead of magic quotes. addslashes()
> > should probably be deprecated too (and it isn't Unicode aware
> > either, so removing it solves two problems).
>
> magic_quotes did the same thing than manual
On Tue, May 31, 2011 at 11:44 AM, Tom Samplonius wrote:
>
> > > The PHP Wikipedia page is wrong about this too, and states that
> > > addslashes() can be used instead of magic quotes. addslashes()
> > > should probably be deprecated too (and it isn't Unicode aware
> > > either, so removing it sol
On May 28, 2011, at 10:42 AM, Daniel Brown wrote:
> On Sat, May 28, 2011 at 06:05, Kalle Sommer Nielsen wrote:
>>
>> expose_php = Off?
>
>I think what he and others mean is that they want the option to
> leave the logo, credits, et cetera, completely out of the build at
> compile time.
We
Yeah, I was wondering why the magical logo thing was implemented like that.
Just use the href= "data:image/png;base64,..." scheme instead if you really
need a logo there. Combine that with smaller size and heavy jpeg compression
and it shouldn't make the HTML /that/ bloated.
Hannes
If you really
Hello.
Typecasting on the index passed to ArrayObject::offsetGet and
ArrayObject::offsetSet seems to be the reason of ArrayObject's confusing
behavior on x86 systems.
According to
http://php.net/manual/en/language.types.integer.php#language.types.integer.overflow,
If PHP encounters a numb
https://wiki.php.net/rfc/shortsyntaxforarrays
Since this was brought again recently by Rasmus
(http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where
several people including Andi chimed in on it and Ilia seemed to reverse
his thoughts as well (with caveats), I thought I would star
I'm one of the people who've brought it up on Twitter. Today's discussion seems
to have earned some traction, which is a step in the right direction, I believe.
> I would prefer (as Rasmus pointed out) not to start a long discussion about
> it. Primarily I would be curious if anyone on the lists
+1
On Tue, May 31, 2011 at 3:52 PM, Sean Coates wrote:
> I'm one of the people who've brought it up on Twitter. Today's discussion
> seems to have earned some traction, which is a step in the right direction, I
> believe.
>
>> I would prefer (as Rasmus pointed out) not to start a long discussio
A few notes worth mentioning:
- That RFC moved from fail to 'under discussion' a few weeks ago, although it
hasn't been edited
- Most people are now for it, or at least that's the general feeling on IRC
(#php.pecl) these past few weeks
- Discussing it is on the 5.4 TODO ( https://wiki.php.net/t
Voting in favor of a short syntax, as a mostly userland dev, seems a
no-brainer, but both suggested syntaxes and patches are rather unnatural:
they attempt to mimic JSON syntax, but do not go the whole way.
The second syntax, possibly more natural to PHP devs, might well be more
trouble tha
Hello everyone,
There are differing opinions on this matter so I'll base a conclusion on
current SVN:
- Both (INF==INF and INF===INF) are true in PHP 5_4 because it's the correct
behavior
- PHP 5_3 will continue as is for BC reasons (INF==INF = false, INF===INF =
true)
So unless something cha
Agree with Derick, strictly speaking, in maths science, INF != INF.
But I dont care if PHP tells me than yes, because PHP is not designed
to solve high level maths problems :)
Cheer,
Julien.Pauli
On Fri, May 27, 2011 at 4:48 PM, Derick Rethans wrote:
> On Thu, 26 May 2011, Scott MacVicar wrote
This is my first time posting to the mailing list, been lurking for a little
while, but I would like to throw in my thoughts. I've written about the idea of
PHP supporting JSON notation on my blog before
(http://www.justincarmony.com/blog/2011/04/12/php-itch-to-scratch-object-notation/),
and I
>> I would prefer (as Rasmus pointed out) not to start a long discussion about
>> it. Primarily I would be curious if anyone on the lists (from the RFC wiki
>> page) below would like to change your vote or if you are not listed below
>> and would like to be counted, that would be great too.
i'm
Hi!
At risk of turning this into a longer-than-necessary discussion, I
believe a new RFC is required at this point. Making [ and ] work as
(T_ARRAY, '(') and (')'), respectively is no longer good enough, for
the main reason you've pointed out: JSON is becoming ubiquitous;
actual first-class JSON
On 05/31/2011 08:52 PM, Sean Coates wrote:
I'm one of the people who've brought it up on Twitter. Today's discussion seems
to have earned some traction, which is a step in the right direction, I believe.
I would prefer (as Rasmus pointed out) not to start a long discussion about it.
Primarily
This is (as far as I remember) my first mail on this list and I don't
really know, how the voting process works. I guess its free4all, so ...
Am 31.05.2011 20:42, schrieb Brian Moon:
I would prefer (as Rasmus pointed out) not to start a long discussion
about it. Primarily I would be curious i
Hello,
On Tue, May 31, 2011 at 11:42 AM, Brian Moon wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to r
On 05/31/2011 11:52 AM, Sean Coates wrote:
> I'm one of the people who've brought it up on Twitter. Today's discussion
> seems to have earned some traction, which is a step in the right direction, I
> believe.
>
>> I would prefer (as Rasmus pointed out) not to start a long discussion about
>> i
Hi!
Stas, I didn't understand your point about eval() and security. What did
you mean?
I meant if PHP has JSON syntax as native, e.g. you can say something like:
$a = {"a":"b"};
Then the temptation would be to write something like:
// $json_string is {"a":"b"}
$a = eval($json_string);
just
On 05/31/2011 02:25 PM, Stas Malyshev wrote:
> Hi!
>
>> Stas, I didn't understand your point about eval() and security. What did
>> you mean?
>
> I meant if PHP has JSON syntax as native, e.g. you can say something like:
>
> $a = {"a":"b"};
>
> Then the temptation would be to write something li
It is worth noting that point you bring up is one that is present in PHP
currently:
php > print_r(json_decode(json_encode(array('a' => 'b';
stdClass Object
(
[a] => b
)
php > print_r(json_decode(json_encode(array('a', 'b';
Array
(
[0] => a
[1] => b
)
-Dan
On Tue, May 31, 201
After reviewing the patch (again), I think there is no harm in support
short-array syntax, similar to JSON format:
$a = [1, 2, 3];
$b = ['foo': 'orange', 'bar': 'apple', 'baz': 'lemon'];
So, I am changing my previous -1 to +1.
On Tue, May 31, 2011 at 8:42 PM, Brian Moon wrote:
> https:/
Hi,
I'm glad the topic has been picked up again, but I think there is an
inconsistency in the proposal now that we are talking about being JSON-ish:
JSON describes objects, not arrays. Then, what if "[]" were used for arrays
and "{}" for objects?, so that:
[1,2,3] //array(0=>1, 1=>2, 2=>3)
['one'
Hi!
It is worth noting that point you bring up is one that is present in PHP
currently:
php > print_r(json_decode(json_encode(array('a' => 'b';
stdClass Object
(
[a] => b
)
json_decode has an option for that, see php.net/json_decode
--
Stanislav Malyshev, Software Architect
SugarCRM
Stas,
Why would you use eval() as opposed to json_decode() ?
On Tue, May 31, 2011 at 11:25 PM, Stas Malyshev wrote:
> Hi!
>
>> Stas, I didn't understand your point about eval() and security. What did
>> you mean?
>
> I meant if PHP has JSON syntax as native, e.g. you can say something like:
>
>
> Agree with Derick, strictly speaking, in maths science, INF != INF.
I disagree,based on quote from
http://compilers.iecc.com/comparch/article/98-07-134:
"Since a projective infinity doesn't have a sign, comparing a floating point
value other than infinity to a projective infinity is unordered.
Hi!
Why would you use eval() as opposed to json_decode() ?
I dunno... People do all kinds of things they're not supposed to :)
E.g., they may want to include() JSON files to benefit from opcode
caches, etc.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)45
On 05/31/2011 02:34 PM, Dan Birken wrote:
> It is worth noting that point you bring up is one that is present in PHP
> currently:
>
> php > print_r(json_decode(json_encode(array('a' => 'b';
> stdClass Object
> (
> [a] => b
> )
>
> php > print_r(json_decode(json_encode(array('a', 'b';
Rasmus,
Don't you think having support for both ['a':1, 'b':2] and {'a':1,
'b':2} would create confusion?
On Tue, May 31, 2011 at 11:16 PM, Rasmus wrote:
> On 05/31/2011 11:52 AM, Sean Coates wrote:
>> I'm one of the people who've brought it up on Twitter. Today's discussion
>> seems to have ea
On Tue, May 31, 2011 at 4:36 PM, dukeofgaming wrote:
> Hi,
>
> I'm glad the topic has been picked up again, but I think there is an
> inconsistency in the proposal now that we are talking about being JSON-ish:
> JSON describes objects, not arrays. Then, what if "[]" were used for arrays
> and "{}"
Would seem to me a more elegant solution would to just drop the idea of json
interoperability and go with something that works for PHP.
('a'=>'b', 0=>1234) perhaps?
On May 31, 2011, at 4:45 PM, Ilia Alshanetsky wrote:
> Rasmus,
>
> Don't you think having support for both ['a':1, 'b':2] and {'
On 31/05/11 19:42, Brian Moon wrote:
https://wiki.php.net/rfc/shortsyntaxforarrays
Since this was brought again recently by Rasmus
I'm all for this, though I would confess to having a preference for the
second syntax:
$arr = [ 'foo' => 'bar', 'baz' => 'foo' ]
seems to fit better with PHP
>> Don't you think having support for both ['a':1, 'b':2] and {'a':1,
>> 'b':2} would create confusion?
This sounds OK to me, FWIW.
> Would seem to me a more elegant solution would to just drop the idea of json
> interoperability and go with something that works for PHP.
>
> ('a'=>'b', 0=>1234
Guys, as I said earlier, not even javascript (from javascript object
notation, as in JSON) is 100% interoperable with JSON because single quotes
are valid in javascript and not in json. I say ":" is way more cleaner than
"=>" and it is a good opportunity to adopt it.
Forgive me for injecting my $.02 here but what is the original reason
for changing the most basic language syntax to be a little bit
shorter?
Is it hurting anyone to type out "array()" or something?
I think it is silly that "shortening array syntax" is up for
discussion but ensuring Unicode compa
On 05/31/2011 02:45 PM, Ilia Alshanetsky wrote:
> Rasmus,
>
> Don't you think having support for both ['a':1, 'b':2] and {'a':1,
> 'b':2} would create confusion?
Not if we present this as native json support in PHP. Then we have to
support the {} version. Other than a couple of grumpy old-timers,
Yes it does :)
I guess my point was it would be confusing if PHP supported JSON-like
syntax, but json_decode(X) was different from eval(X). So if PHP isn't
going to use JSON syntax (because it doesn't work for assoc arrays), then I
don't think there is much benefit in using *almost* JSON syntax.
On Tue, May 31, 2011 at 11:59 PM, Rasmus wrote:
> On 05/31/2011 02:45 PM, Ilia Alshanetsky wrote:
>> Rasmus,
>>
>> Don't you think having support for both ['a':1, 'b':2] and {'a':1,
>> 'b':2} would create confusion?
>
> Not if we present this as native json support in PHP. Then we have to
> suppor
On Tue, 31 May 2011 22:41:36 +0100, Hannes Landeholm
wrote:
Agree with Derick, strictly speaking, in maths science, INF != INF.
I disagree,based on quote from
http://compilers.iecc.com/comparch/article/98-07-134:
"Since a projective infinity doesn't have a sign, comparing a floating
poin
Exactly my point. Why try to fudge json into php, instead of just improving php?
On May 31, 2011, at 5:02 PM, Dan Birken wrote:
> Yes it does :)
>
> I guess my point was it would be confusing if PHP supported JSON-like
> syntax, but json_decode(X) was different from eval(X). So if PHP isn't
> g
On 05/31/2011 02:59 PM, Michael Shadle wrote:
> Forgive me for injecting my $.02 here but what is the original reason
> for changing the most basic language syntax to be a little bit
> shorter?
>
> Is it hurting anyone to type out "array()" or something?
>
> I think it is silly that "shortening a
I agree with this. So the idea would be adding short hand object notation for
PHP, inspired by JSON, but we also allow for associative arrays. So:
$object = { 'var1': 'one', 'var2': 'two' }; // for an object
$assoc_array = [ 'var1': 'one', 'var2': 'two' ]; // for an array
// even mix and match
On May 31, 2011, at 3:06 PM, Rasmus wrote:
> On 05/31/2011 02:59 PM, Michael Shadle wrote:
>> Forgive me for injecting my $.02 here but what is the original reason
>> for changing the most basic language syntax to be a little bit
>> shorter?
>>
>> Is it hurting anyone to type out "array()" or so
On Tue, May 31, 2011 at 3:06 PM, Rasmus wrote:
> Because most of those can't be done without breaking millions of lines
> of code out there. And a couple of people worked on Unicode for years
> and got very little support. That is not a small project. This short
> syntax for arrays is probably th
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 helpful, especially when APC is being
used. Are there
Hi!
The patch is solid (have been using it in production for quite some
time) and improvement is quite helpful, especially when APC is being
used. Are there any reasons not to apply this to 5.4?
I don't know of any. Are there any issues with this change (BC, etc.)?
--
Stanislav Malyshev, Softw
I do not believe so.
On Wed, Jun 1, 2011 at 12:35 AM, Stas Malyshev wrote:
> Hi!
>
>> The patch is solid (have been using it in production for quite some
>> time) and improvement is quite helpful, especially when APC is being
>> used. Are there any reasons not to apply this to 5.4?
>
> I don't kn
Hi!
I do not believe so.
Then I guess if nobody has any objections we can do it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From the perspective of someone that's just trying to get stuff done:
$packet = array('response' => array('status' => 1,'message' => ''),'data' =>
array('id' => 1, 'username' => 'john doe'));
$packet = ['response': ['status': 1, 'message': '', 'data': ['id': 1,
'username': 'john doe'] ] ];
The
On 05/31/2011 03:35 PM, Stas Malyshev wrote:
> Hi!
>
>> The patch is solid (have been using it in production for quite some
>> time) and improvement is quite helpful, especially when APC is being
>> used. Are there any reasons not to apply this to 5.4?
>
> I don't know of any. Are there any issue
I've always considered json an awesome machine to machine interchange format
(the most efficient one) but not the easiest to read for configuration or
manually defining anything.
I see nothing wrong with the initial example. Has worked well for years. :)
On May 31, 2011, at 3:43 PM, Marcel Ess
Yeah, you'll note I am not actually advocating making a full JSON
implementation in the PHP language.
However, as per your point, JSON is no longer just a machine interchange
format. It's many other things these days, including a query definition
protocol. It's unlikely that the number of systems
+1
On May 31, 2011, at 2:42 PM, Brian Moon wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse
+1
To be honest, ['a': 'b'] or ['a' => 'b'] is so much better than array('a' =>
'b') for general use I don't even care which one is picked, as long as one
of them is picked.
-Dan
On Tue, May 31, 2011 at 3:43 PM, Marcel Esser wrote:
> From the perspective of someone that's just trying to get stu
On Tue, May 31, 2011 at 7:29 PM, Dan Birken wrote:
> +1
>
> To be honest, ['a': 'b'] or ['a' => 'b'] is so much better than array('a'
> =>
> 'b') for general use I don't even care which one is picked, as long as one
> of them is picked.
>
> -Dan
>
+1 to that too. Even when I've never liked that
+1 for a short array syntax.
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.
On Wed, Jun 1, 2011 at 02:42, dukeofgaming wrote:
> On Tue, May 31, 2011 at 7
On 05/31/2011 05:42 PM, dukeofgaming wrote:
> I'm afraid that if ":" is associated with the JSON interop argument and the
> later is discarded then ":" will be discarded too, much like what happened
> with the echo shortcut (" of JSON interop could be taken to another RFC and get less noise and be
On 1 June 2011 08:57, Etienne Kneuss wrote:
> +1 for a short array syntax.
>
> 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.
Agreed here: +1 for shor
On Tue, May 31, 2011 at 9:27 PM, Rasmus wrote:
> On 05/31/2011 05:42 PM, dukeofgaming wrote:
>
> > I'm afraid that if ":" is associated with the JSON interop argument and
> the
> > later is discarded then ":" will be discarded too, much like what
> happened
> > with the echo shortcut (" idea
> >
Hi!
Yeah, I was wondering why the magical logo thing was implemented like that.
Just use the href= "data:image/png;base64,..." scheme instead if you really
need a logo there. Combine that with smaller size and heavy jpeg compression
and it shouldn't make the HTML /that/ bloated.
Well, there ar
Hi!
I agree, it would be a break a lot of code. But I'd rather see some
fundamental changes at that level (call it PHP 6, make it not BC with
PHP 5.x or earlier), and remove the cruft and standardize on some of
the slop.
Fundamental changes means "throw out your production code and start
deve
Also, take a peak at this: http://www.phpsadness.com/sad/45
And compare it with this:
http://perldoc.perl.org/perldsc.html#Declaration-of-a-HASH-OF-COMPLEX-RECORDS
Regards,
David Vega
On Wed, Jun 1, 2011 at 12:15 AM, Stas Malyshev wrote:
> Hi!
>
>
> I agree, it would be a break a lot of code.
I don't really want to stand on my soapbox any longer, as it's obvious
where the crowd leans on this one, but I need to clarify a couple
points a bit and feel obligated to reply to another.
On Tue, May 31, 2011 at 10:15 PM, Stas Malyshev wrote:
> Fundamental changes means "throw out your product
On Wed, Jun 1, 2011 at 12:35 AM, Michael Shadle wrote:
> I don't really want to stand on my soapbox any longer, as it's obvious
> where the crowd leans on this one, but I need to clarify a couple
> points a bit and feel obligated to reply to another.
>
> On Tue, May 31, 2011 at 10:15 PM, Stas Mal
Hi!
If a handful of "experienced people" decided to go forward with my
crackpot idea above, would you be in support, just because they are?
No, but I wouldn't say that nobody needs it. I'd say it's a bad idea
despite somebody needing it, for reasons so and so.
I figured it was tough, based
Hi,
I remember having wiki editing privileges not so long ago, I was going to
enter and add the entry for discussions at
https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit anymore.
Would it be too much to ask to have them enabled?.
Best regards,
David Vega
Hi,
I thought it might be interesting for all to read some feedback I got from
some questions I made to the Joomla community, specifically, the guys and
gals that have been implementing the decoupling of the Joomla framework: the
Joomla Platform.
They currently still use svn officially but they h
Michael Maclean wrote:
https://wiki.php.net/rfc/shortsyntaxforarrays
Since this was brought again recently by Rasmus
I'm all for this, though I would confess to having a preference for the
second syntax:
$arr = [ 'foo' => 'bar', 'baz' => 'foo' ]
seems to fit better with PHP than the other
On May 31, 2011, at 11:05 PM, dukeofgaming wrote:
> Hi,
>
> I remember having wiki editing privileges not so long ago, I was going to
> enter and add the entry for discussions at
> https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit anymore.
> Would it be too much to ask to have them
Thanks, I also don't think that was the case.
Regards,
David
On Wed, Jun 1, 2011 at 1:26 AM, Philip Olson wrote:
>
> On May 31, 2011, at 11:05 PM, dukeofgaming wrote:
>
> > Hi,
> >
> > I remember having wiki editing privileges not so long ago, I was going to
> > enter and add the entry for dis
dukeofgaming wrote:
I thought it might be interesting for all to read some feedback I got
from some questions I made to the Joomla community, specifically, the
guys and gals that have been implementing the decoupling of the Joomla
framework: the Joomla Platform.
They currently still use svn offi
82 matches
Mail list logo
