Re: [PHP-DEV] DVCS
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 officially but they have been experimenting with both mercurial and git. These are their responses so far: http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/fd3b0151cc215c0e It may bring some insight to what a DVCS could do for the PHP community. I think that there are perhaps still a couple of separate problems here which the DVCS community need to get behind for any of them to become a 'front runner'. The main problem here IS 'subrepo' which is a concept that neither HG or GIT handle particularly well, but to my mind is essential for a very much modular project like PHP! While I have sort of managed to put together a 'checkout' of a set of packages which together make a single build of the target project, I'm still having to pull and commit changes manually to each subrepo - I don't get the simple overview of outstanding changes that was SO nice to work with in CVS! To try and put this in a 'PHP' context ... I DID have a list of extensions I was working with, and a 'sync' in ECLIPSE gave me a nice list of which ones had had changes pushed ... I could then go and either simply update to those changes on an extension by extension basis - or review the changes in each file so allow me to integrate other peoples changes with my own local 'tweaks'. This is something that DVCS SHOULD be perfect for, but the management tools for bundling a selection of parts of a project are not there yet, mainly because the core developers on both HG and GIT "don't see then need because they don't need that type of working"! I'm limping along with HG at the moment simply because it works on both Linux AND Windows, while GIT's windows support is still rather hit and miss when one is already using other unix tools on windows, but I do not have the same level of integration in Eclipse that CVS and SVN provide beautify straight out of the box. At least I can drop out of Eclipse into TortoiseHg and do the code management, but it's not an ideal way of working. If I was a 'console jockey' then much of this would probably be a lot less of a problem. One seems to need to write scripts to do what YOU want to do in both HG and GIT - and then need to learn Python to do that in HG :( But I never used CVS from the command line so a LOT of the reasoning for even the switch to SVN was irrelevant since Eclipse had already solved all of those 'problems'. At the current time I think that PHP would need to restructure how it is packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd still prefer CVS here it works BETTER as a master for DVCS! ) as the master from which we CAN currently sync using HG or GIT is the best of a bad job currently. Unless some knows better? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wiki editing privileges
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 discussions at > > https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit anymore. > > Would it be too much to ask to have them enabled?. > > I don't think anyone [intentionally] took away wiki editing rights, but you > now have full access to the rfc namespace. > > Regards, > Philip > >
Re: [PHP-DEV] Wiki editing privileges
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 enabled?. I don't think anyone [intentionally] took away wiki editing rights, but you now have full access to the rfc namespace. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 one, JSON-compatibility aside. Keeping the => does make a lot more sense since it differentiates that PHP CAN do things here that simply do not work in JSON? This ONLY works with JSON when one takes the care to avoid associative arrays, and => in my mind has always been 'associate' ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
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 have been experimenting with both mercurial and git. These are their responses so far: http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/fd3b0151cc215c0e It may bring some insight to what a DVCS could do for the PHP community. Best regards, David On Thu, Apr 28, 2011 at 2:28 AM, Lester Caine wrote: > dukeofgaming wrote: > >> >> http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 >> >> So, I don't want to make debate here of wether centralized is better than >> distributed (because the point is moot), but I think its not a good >> situation for the community to have a previously open door to DVCSs now >> closed. >> > > Having been battling with various projects that have decided that 'git is > good' or 'hg is best' ... I've been trying to live in the new world and > failing. That link is looking like a nice CURRENT overview of the situation > although things are still changing mainly for the good. > > My problem until recently was that 'subrepo' management in DVCS has always > been playing catchup. Yesterday for the first time I checked out a > 'super-project' matching one of the composite builds provided on an original > CVS repo! Still not fully integrated into Eclipse, but hopefully even that > will come with time. But now I can 'clone' the half dozen different builds > and manage them in parallel with both github and bitbucket 'masters'. > > I'm using Mercurial and TortoiseHg which almost work transparently between > Linux and Windows, and with hg-git access to the 'git is good' projects is > also transparent even on windows. Next step this weekend IS to tidy up the > SVN setup so that I have the PHP code locally mirrored as well > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] Wiki editing privileges
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
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 on the amount of effort/time people spent. Sad to see that it seems abandoned though. Well, you know, if somebody has time/energy to pick it up - go ahead. But people that worked on it felt they are not getting the result they hoped for, so they cut their losses and moved on. The beauty of open source is that if anybody wants to pick it up it's still out there. IMHO, JSON-style syntax is *not* as readable as PHP array syntax. It's shorthanding something that is pretty short as well. That's obviously a matter of taste - I consider it more readable, for example. For elephant's sake, we're being unfavorably compared to Perl on readability! :) But seriously, if I alone felt that, I'd suck it up - as I did when it failed last time. But this time more people feel that way - so maybe it's time for a change. People change, experiences change, tastes change, languages change. is *unnecessary* as nothing is broken. I can only imagine the poor PHP developers bastardizing this so badly it takes hours to decypher what they are trying to do. I think while you point on excessive shortcutting is completely valid, in this example it is not excessive, as [] array syntax is very common (Perl, Python, Ruby, JS, D, etc.) and recognizable. -- 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
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 Malyshev
> wrote:
>
> > Fundamental changes means "throw out your production code and start
> > developing a new one". Guess how many PHP shops with existing code would
> be
> > happy to do it. It's nice to rant about how PHP function are inconsistent
> > and stuff, but no project was seriously impeded by it ever. At most it is
> > mildly irritating. Huge BC break, on the other hand, would mean all major
> > apps/libraries/frameworks become instantly not available, and who knows
> when
> > they catch up. At this point, you might as well have a new language.
>
> This is understood, but it was a crackpot example. IMHO, adding more
> ways to express the same thing in a well-established language is more
> or less the same. It's relearning something you thought you already
> knew; yes, one breaks BC, but that is why you'd have to classify it a
> different major version. I'm done on that one. Like I said, it's a
> crackpot example.
>
> > Since many experienced people are supporting it, I'd think that while it
> > seems unnecessary to you, it may seem otherwise for them.
>
> Many experienced people are also against it.
>
AFAIK, it was because they didn't want to maintain/implement it. Don't know
if this was before the patch was provided.
>
> If a handful of "experienced people" decided to go forward with my
> crackpot idea above, would you be in support, just because they are?
>
> Also, you're implying that this is a *necessary* change for these
> experienced people. Is there something I am missing that PHP is *not*
> handling currently and requires this *necessary* change? (No)
>
> > Read this (esp. first answer):
> > http://stackoverflow.com/q/6162484/214196
> >
> > It's about Perl, but gives you an impression why it is so tough.
>
> I figured it was tough, based on the amount of effort/time people
> spent. Sad to see that it seems abandoned though.
>
> > Why not? If the pieces are good, stealing them is good. It's how progress
> > happens - you "steal" good pieces and add couple of your own, and hope
> the
> > result is good enough that somebody else would want to steal stuff from
> it
>
> While a language is maturing, I would probably agree. I consider PHP
> quite mature now. I'd say the proof is in the pudding based on the
> numbers.
>
> My chief concerns are these:
>
> IMHO, JSON-style syntax is *not* as readable as PHP array syntax. It's
> shorthanding something that is pretty short as well.
>
> Currently, if I want to find an array in code, I can search just for
> "array" or "Array" or "=>" or variations thereof. This adds yet
> another type of grep I have to run through. One that I am not sure can
> be easily accomplished (wouldn't it be matching quite a lot more
> because of it's bare nature? Now we've got to look up neat ways to
> combine and grep for :?[]{} etc.) Also, now you have coders on the
> same project using their personal preference.
> If something isn't broken, why fix it? That was the basis on my
> original comment about things that actually were underway or brought
> up due to issues.
>
> Before I get off my sandbox, and go back to the shadows on the dev
> list, someone privately replied to me and said this will help because
> it will "its hurting lots of people's eyes (and wrists on the long
> term)" - I'm taking that as a joke.
>
Weird, I didn't mean to reply privately, must have mistaken the reply to all
button. Anyhow, I did say it tongue-in-cheek, but the shorter syntax is
easier on the eyes for the nested case. Just FTR I'll copy most of my email
here:
Stolen?, why not learned?. Java has great architectural stuff and if wasn't
for other languages (and developers educated on them) we wouldn't have stuff
like exceptions, reflection, and —in the future— traits. You write as if PHP
could not or should not improve, and that is a very wrong attitude to have
IMHO.
The shorter syntaxes are more readable and thus an improvement. You said:
"Is it hurting anyone to type out "array()" or something?"
I say its hurting lots of people's eyes (and wrists on the long term, tsk
tsk). But its not going to be an obligatory syntax, you will always be able
to use "array()" if you enjoy it; personally, I don't, and I don't think the
proposers and supporters enjoy it that much either.
---
Regards,
David
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 production code and start
> developing a new one". Guess how many PHP shops with existing code would be
> happy to do it. It's nice to rant about how PHP function are inconsistent
> and stuff, but no project was seriously impeded by it ever. At most it is
> mildly irritating. Huge BC break, on the other hand, would mean all major
> apps/libraries/frameworks become instantly not available, and who knows when
> they catch up. At this point, you might as well have a new language.
This is understood, but it was a crackpot example. IMHO, adding more
ways to express the same thing in a well-established language is more
or less the same. It's relearning something you thought you already
knew; yes, one breaks BC, but that is why you'd have to classify it a
different major version. I'm done on that one. Like I said, it's a
crackpot example.
> Since many experienced people are supporting it, I'd think that while it
> seems unnecessary to you, it may seem otherwise for them.
Many experienced people are also against it.
If a handful of "experienced people" decided to go forward with my
crackpot idea above, would you be in support, just because they are?
Also, you're implying that this is a *necessary* change for these
experienced people. Is there something I am missing that PHP is *not*
handling currently and requires this *necessary* change? (No)
> Read this (esp. first answer):
> http://stackoverflow.com/q/6162484/214196
>
> It's about Perl, but gives you an impression why it is so tough.
I figured it was tough, based on the amount of effort/time people
spent. Sad to see that it seems abandoned though.
> Why not? If the pieces are good, stealing them is good. It's how progress
> happens - you "steal" good pieces and add couple of your own, and hope the
> result is good enough that somebody else would want to steal stuff from it
While a language is maturing, I would probably agree. I consider PHP
quite mature now. I'd say the proof is in the pudding based on the
numbers.
My chief concerns are these:
IMHO, JSON-style syntax is *not* as readable as PHP array syntax. It's
shorthanding something that is pretty short as well.
Currently, if I want to find an array in code, I can search just for
"array" or "Array" or "=>" or variations thereof. This adds yet
another type of grep I have to run through. One that I am not sure can
be easily accomplished (wouldn't it be matching quite a lot more
because of it's bare nature? Now we've got to look up neat ways to
combine and grep for :?[]{} etc.) Also, now you have coders on the
same project using their personal preference.
If something isn't broken, why fix it? That was the basis on my
original comment about things that actually were underway or brought
up due to issues.
Before I get off my sandbox, and go back to the shadows on the dev
list, someone privately replied to me and said this will help because
it will "its hurting lots of people's eyes (and wrists on the long
term)" - I'm taking that as a joke.
I understand I can use the "long syntax" still. Great. But *why*
introduce a second one? I can't even read half the Perl I see nowadays
because people have shortcutted so much crap. As I've said PHP is my
bread and butter, please don't make life harder by making syntax
changes that enable developers to be more cryptic code. I'm a
minimalist myself, I like smaller chunks of clean code, but this idea
is *unnecessary* as nothing is broken. I can only imagine the poor PHP
developers bastardizing this so badly it takes hours to decypher what
they are trying to do.
I have a feeling this is getting adopted either way, but I feel
obligated as a user to ask "wtf?"
- mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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. 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 > developing a new one". Guess how many PHP shops with existing code would be > happy to do it. It's nice to rant about how PHP function are inconsistent > and stuff, but no project was seriously impeded by it ever. At most it is > mildly irritating. Huge BC break, on the other hand, would mean all major > apps/libraries/frameworks become instantly not available, and who knows when > they catch up. At this point, you might as well have a new language. > > > Shorter array syntax seems like an unnecessary addon, will create more >> > > Since many experienced people are supporting it, I'd think that while it > seems unnecessary to you, it may seem otherwise for them. > > > I would help with the Unicode project if I could. I am not sure why it >> was so tough, but I imagine people infinitely smarter than I am were >> > > Read this (esp. first answer): > http://stackoverflow.com/q/6162484/214196 > > It's about Perl, but gives you an impression why it is so tough. > > > Making JSON style arrays seems stupid to me. When I look at a PHP >> script I expect PHP syntax. Not stolen pieces from a bunch of other >> languages (yes, some of it is that way already, but let's not keep the >> trend going please?) >> > > Why not? If the pieces are good, stealing them is good. It's how progress > happens - you "steal" good pieces and add couple of your own, and hope the > result is good enough that somebody else would want to steal stuff from 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 > >
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 developing a new one". Guess how many PHP shops with existing code would be happy to do it. It's nice to rant about how PHP function are inconsistent and stuff, but no project was seriously impeded by it ever. At most it is mildly irritating. Huge BC break, on the other hand, would mean all major apps/libraries/frameworks become instantly not available, and who knows when they catch up. At this point, you might as well have a new language. Shorter array syntax seems like an unnecessary addon, will create more Since many experienced people are supporting it, I'd think that while it seems unnecessary to you, it may seem otherwise for them. I would help with the Unicode project if I could. I am not sure why it was so tough, but I imagine people infinitely smarter than I am were Read this (esp. first answer): http://stackoverflow.com/q/6162484/214196 It's about Perl, but gives you an impression why it is so tough. Making JSON style arrays seems stupid to me. When I look at a PHP script I expect PHP syntax. Not stolen pieces from a bunch of other languages (yes, some of it is that way already, but let's not keep the trend going please?) Why not? If the pieces are good, stealing them is good. It's how progress happens - you "steal" good pieces and add couple of your own, and hope the result is good enough that somebody else would want to steal stuff from 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
Re: [PHP-DEV] removing some cruft
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 are some browsers that don't support data: (ahem, IE7) but I'd say cleanness is more important and those browsers must die anyway :) That, however, doesn't solve problem with credits page, and IE hates navigable data: (meaning HTML) so we couldn't use it for credits. But if someone submits patch for images, I don't see a problem with that. -- 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
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
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
> > of JSON interop could be taken to another RFC and get less noise and
> better
> > ideas as a separate topic.
>
>
> -Rasmus
>
Yep, I know, and thank you very much for that (I did see your commit a
couple of hours after you posted it). I think there was a lot of confusion
and fear (myself included) when "" is the only thing left to decide on this
proposal. I was thinking that if ":" was to be introduced, perhaps
"array('a':'A',...)" should also be added for consistency, and that is extra
work. In my opinion adopting ":" would be nice, but it would also be noise
for the developer community, perhaps good noise but noise nonetheless.
The healthy thing to do here IMHO, would be putting introduction of ":" as a
separate RFC, perhaps part of a JSON interoperability RFC, but as Adam just
replied, PHP is not JSON and "=>" is a very fundamental thing to change, so
I have mixed feelings about this.
Also, can we agree on the topic of introducing "{ }" for objects to the
proposal?.
Best regards,
David
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
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 short array syntax using =>; -0 for short array syntax using colons. PHP isn't JSON, and I'd rather be consistent with previous PHP syntax, given the choice. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
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 better
> ideas as a separate topic.
http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
+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: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 much "=>" and would love to
> see ":" make an entrance instead .
>
> 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 better
> ideas as a separate topic.
>
> Regards,
>
> David
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
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 much "=>" and would love to
see ":" make an entrance instead .
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 ("
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
+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 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 clarity improvement above is an exponential function that gets better
> and better the more deeply nested you are. I don't know anyone that needs
> the ability to support full JSON notation in PHP, but there are entirely too
> many deeply nested array() declarations with lots of tabs in our lives,
> especially when we start working with things like JSON and/or Mongo or xyz.
>
> That's all I wanted to say to this.
>
> Cheers,
> M.
>
> --
> Marcel Esser
> Vice President of Engineering, CROSCON
> +1 (202) 470-6090
> marcel.es...@croscon.com
>
> Before printing this e-mail, please consider the rainforest.
>
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
+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 his thoughts > as well (with caveats), I thought I would start a real thread about it. The > reason the RFC stalled was stated as: > > "This patch will not be accepted because slight majority of the core > developers voted against. Though if you take a accumulated mean between core > developers and userland votes seems to show the opposite it would be > irresponsible to submit a patch witch is not supported or maintained in the > long run." > > So, the PHP users want it, but too many PHP core devs did not want it or did > not see the use of it. From rereading the mailing list archive, most had the > tone of "I don't see a reason for it." I was in that camp in 2003 when it > first came up. However, with the emergence of JSON and systems that use JSON > as an interface, this type of syntax would be most welcome in the day to day > life of a PHP developer. > > 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. > > PHP SVN account holder voters > = > Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav > Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic > > Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, > Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, > Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, > Hannes Magnusson, David Coallier > > > Other voters > > Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, > Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, > Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly > Negyesi, Guilherme Blanco, Jonathan-Bond Caron > > Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke > > > -- > Brian. > http://brian.moonspot.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
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 that use JSON as a
descriptor or filter will decrease in the near future; many people are
implementing JSON subsets or supersets in this format. And, as mentioned,
that turns into a ton of typing when you start getting deeply nested - in
a way that is not nearly as straight-forward as functionally identical
JSON-like notation.
So, considering all that, there is no real reason that I can see why it
shouldn't be possible to facilitate the developer with an ability to more
easily express these more complicated, nested examples.
That's why everyone in Mexico was cheering.
- M.
--
Marcel Esser
Vice President of Engineering, CROSCON
+1 (202) 470-6090
marcel.es...@croscon.com
Before printing this e-mail, please consider the rainforest.
On 5/31/11 7:30 PM, "Michael Shadle" wrote:
>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 Esser
>wrote:
>
>> 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 clarity improvement above is an exponential function that gets
>>better and better the more deeply nested you are. I don't know anyone
>>that needs the ability to support full JSON notation in PHP, but there
>>are entirely too many deeply nested array() declarations with lots of
>>tabs in our lives, especially when we start working with things like
>>JSON and/or Mongo or xyz.
>>
>> That's all I wanted to say to this.
>>
>> Cheers,
>> M.
>>
>> --
>> Marcel Esser
>> Vice President of Engineering, CROSCON
>> +1 (202) 470-6090
>> marcel.es...@croscon.com
>>
>> Before printing this e-mail, please consider the rainforest.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
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 Esser wrote:
> 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 clarity improvement above is an exponential function that gets better and
> better the more deeply nested you are. I don't know anyone that needs the
> ability to support full JSON notation in PHP, but there are entirely too many
> deeply nested array() declarations with lots of tabs in our lives, especially
> when we start working with things like JSON and/or Mongo or xyz.
>
> That's all I wanted to say to this.
>
> Cheers,
> M.
>
> --
> Marcel Esser
> Vice President of Engineering, CROSCON
> +1 (202) 470-6090
> marcel.es...@croscon.com
>
> Before printing this e-mail, please consider the rainforest.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Zend Signal Handling
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 issues with this change (BC, etc.)? There could be some weird interactivity issues with certain environments, but the patch takes care of most issues and I think the added stability this gives opcode caches is worth the minor risk. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
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 clarity improvement above is an exponential function that gets better and
better the more deeply nested you are. I don't know anyone that needs the
ability to support full JSON notation in PHP, but there are entirely too many
deeply nested array() declarations with lots of tabs in our lives, especially
when we start working with things like JSON and/or Mongo or xyz.
That's all I wanted to say to this.
Cheers,
M.
--
Marcel Esser
Vice President of Engineering, CROSCON
+1 (202) 470-6090
marcel.es...@croscon.com
Before printing this e-mail, please consider the rainforest.
Re: [PHP-DEV] RFC: Zend Signal Handling
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
Re: [PHP-DEV] RFC: Zend Signal Handling
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 know of any. Are there any issues with this change (BC, etc.)? > -- > 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
Re: [PHP-DEV] RFC: Zend Signal Handling
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, 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
[PHP-DEV] RFC: Zend Signal Handling
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 any reasons not to apply this to 5.4? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 the most requested PHP feature right now > and we have a working patch that doesn't break any existing code so the > effort involved is minimal. If you have a working patch that solves the > Unicode issues, by all means, show us. 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. Shorter array syntax seems like an unnecessary addon, will create more code confusion (now people have to think of two different ways something is represented), books will become dated overnight (even moreso than they are now) I would help with the Unicode project if I could. I am not sure why it was so tough, but I imagine people infinitely smarter than I am were working on it. I saw some automated Unicode testing thing that was running on a php.net server once and it looked like there was over 70% coverage at that point. I don't see why it's so hard for PHP to get it going with all the third party libraries out there which could support it (and why other languages developed in C or C++ can support it as well) I don't mean to get off-topic. PHP is my bread and butter, I have immense respect for you. It just feels like there's things requested of the language now that are trying to morph the language into something else. I see blog posts about "10 things PHP needs to have to be more like Java" - if you want Java, use Java. Stop trying to extend PHP to do everything for you. It services the majority of websites on the net and it has done that for years without that crap - and there is a reason for that. Making JSON style arrays seems stupid to me. When I look at a PHP script I expect PHP syntax. Not stolen pieces from a bunch of other languages (yes, some of it is that way already, but let's not keep the trend going please?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 something? >> >> I think it is silly that "shortening array syntax" is up for >> discussion but ensuring Unicode compatibility isn't a higher priority. >> Not to mention named parameters in functions. Or Consistent naming for >> functions str_* vs str*, needle/haystack ordering, etc. If you're >> wanting to augment or change fundamentals of the language why not >> clean some stuff up there first? > > 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 the most requested PHP feature right now > and we have a working patch that doesn't break any existing code so the > effort involved is minimal. If you have a working patch that solves the > Unicode issues, by all means, show us. And because this mailing list thread is about 'short syntax for arrays' and not the other items you mentioned. If you're interested in another topic, or have a proposal, then please do so as a different thread. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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
$person = {
'name': 'Justin',
'city': 'Ogden'
'phones' : [
'home': '555-3928',
'work': '555-3922'
]
};
echo $person->phones['home']; // output: 555-3928
The other option is the [] shorthand would create an ArrayObject, so you can
interact with the object like an array or object. But I think it is important
that we make it possible to allow for array AND object shorthand.
Justin
On May 31, 2011, at 3:56 PM, dukeofgaming wrote:
> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 array syntax" is up for > discussion but ensuring Unicode compatibility isn't a higher priority. > Not to mention named parameters in functions. Or Consistent naming for > functions str_* vs str*, needle/haystack ordering, etc. If you're > wanting to augment or change fundamentals of the language why not > clean some stuff up there first? 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 the most requested PHP feature right now and we have a working patch that doesn't break any existing code so the effort involved is minimal. If you have a working patch that solves the Unicode issues, by all means, show us. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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
> 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.
>
> It just seems simpler that:
> array(1, 2) equals [1, 2]
> array(1 => 2) equals [1 => 2]
>
> -Dan
>
> On Tue, May 31, 2011 at 2:42 PM, Rasmus wrote:
>
>> 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';
>>> Array
>>> (
>>>[0] => a
>>>[1] => b
>>> )
>>
>> Sure, but that makes makes perfect sense, does it not? Javascript does
>> not have associative arrays. So any non-scalar array has to be mapped to
>> a Javascript object in order to be represented. When we bring it back we
>> map a Javascript object to a PHP object, however, there is an optional
>> argument on json_decode() to change that to an associative array if
>> desired.
>>
>> The point we are making is that this exact inability of the json
>> notation to distinguish an associative array from an object makes it a
>> problematic choice for a native syntax in PHP.
>>
>> -Rasmus
>>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] INF behavior
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 point value other than infinity to a projective infinity is unordered. However, a projective infinity is equal to itself." Yes, as I argued, for purposes of IEEE 754, it's certainly the case that INF = INF. This may not be true for certain meanings of "infinity" or notions of ordering, but we have a standard for floating point arithmetic with well-defined terms and rules which we ought to follow. As a curiosity, Mathematica defines the result of Equal[Infinity, Infinity] and Equal[Overflow, Overflow], but not for ComplexInfinity or Indeterminate (similar to NaN): In[1]:= ComplexInfinity == ComplexInfinity Out[1]= ComplexInfinity == ComplexInfinity In[2]:= Infinity == Infinity Out[2]= True In[3]:= Overflow == Overflow Out[3]= True In[4]:= Indeterminate == Indeterminate Out[4]= Indeterminate == Indeterminate -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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
> support the {} version. Other than a couple of grumpy old-timers, I
> think we are in agreement that we should add a short array syntax.
> Whether we should extend that to also add a short object syntax is a
> secondary question.
I guess if you present it as a native json support in PHP, it probably
would be ok from clarity standpoint. Overloading {} parser should be
doable, but a little trickier than []. The + of the current patch is
that it is very nice and simple.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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.
It just seems simpler that:
array(1, 2) equals [1, 2]
array(1 => 2) equals [1 => 2]
-Dan
On Tue, May 31, 2011 at 2:42 PM, Rasmus wrote:
> 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';
> > Array
> > (
> > [0] => a
> > [1] => b
> > )
>
> Sure, but that makes makes perfect sense, does it not? Javascript does
> not have associative arrays. So any non-scalar array has to be mapped to
> a Javascript object in order to be represented. When we bring it back we
> map a Javascript object to a PHP object, however, there is an optional
> argument on json_decode() to change that to an associative array if
> desired.
>
> The point we are making is that this exact inability of the json
> notation to distinguish an associative array from an object makes it a
> problematic choice for a native syntax in PHP.
>
> -Rasmus
>
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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, I
think we are in agreement that we should add a short array syntax.
Whether we should extend that to also add a short object syntax is a
secondary question.
Just as a data point, I gave a presentation in Mexico a couple of days
ago to a couple of hundred kids where I went over the accepted new
features in 5.4 and also a short list of features under discussion, and
this short array syntax got the most applause by far. It is much harder
to explain traits than this feature.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 compatibility isn't a higher priority. Not to mention named parameters in functions. Or Consistent naming for functions str_* vs str*, needle/haystack ordering, etc. If you're wanting to augment or change fundamentals of the language why not clean some stuff up there first? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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.
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
>> 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) perhaps?
Please, no. Let's implement or augment JSON, not bastardize it.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 than the other one, JSON-compatibility aside. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 {'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 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 (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.
>>>
>>> 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
>>> would be very valuable to me.
>>
>> The tricky part with going all json is the syntax, specifically the {}'s
>>
>> But I think it is doable, mostly because this is not valid today:
>>
>> $a = true ? { 1 : 2 };
>>
>> And in json if you have {}'s you have to have a ':' inside.
>>
>> I have always preferred to "borrow" a familiar syntax from other
>> languages that the average PHP user is comfortable with instead of
>> making up a new one.
>>
>> Stas, I didn't understand your point about eval() and security. What did
>> you mean?
>>
>> -Rasmus
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 "{}" for objects?, so that:
>
> [1,2,3] //array(0=>1, 1=>2, 2=>3)
> ['one':1, 'two':2, 'three' : 3] // array('one'=>1, 'two'=>2, 'three' => 3)
> ['one':1, 'two':2, 'three' : 3] // (object)array('one'=>1, 'two'=>2,
> 'three' => 3)
>
>
Err, I meant:
{'one':1, 'two':2, 'three' : 3} // (object)array('one'=>1, 'two'=>2, 'three'
=> 3)
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 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 (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.
>>
>> 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 would be
>> very valuable to me.
>
> The tricky part with going all json is the syntax, specifically the {}'s
>
> But I think it is doable, mostly because this is not valid today:
>
> $a = true ? { 1 : 2 };
>
> And in json if you have {}'s you have to have a ':' inside.
>
> I have always preferred to "borrow" a familiar syntax from other
> languages that the average PHP user is comfortable with instead of
> making up a new one.
>
> Stas, I didn't understand your point about eval() and security. What did
> you mean?
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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';
> Array
> (
> [0] => a
> [1] => b
> )
Sure, but that makes makes perfect sense, does it not? Javascript does
not have associative arrays. So any non-scalar array has to be mapped to
a Javascript object in order to be represented. When we bring it back we
map a Javascript object to a PHP object, however, there is an optional
argument on json_decode() to change that to an associative array if desired.
The point we are making is that this exact inability of the json
notation to distinguish an associative array from an object makes it a
problematic choice for a native syntax in PHP.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] INF behavior
> 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. However, a projective infinity is equal to itself." Hannes On 31 May 2011 21:39, Julien Pauli wrote: > 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: > > > >> On 26 May 2011, at 20:03, Philip Olson wrote: > >> > >> > Hello geeks, > >> > > >> > A geek is needed to clarify PHP bug #45712. This is an edge case but > the test (bug45712.phpt) contains code similar to the following: > >> > > >> > >> > $inf = pow(0, -2); > >> > > >> > var_dump($inf); // float(INF) > >> > var_dump($inf == $inf); // bool(false) > >> > var_dump($inf === $inf); // bool(true) > >> > ?> > >> > > >> > That's how it's behaved since ~forever (AFAICT) and remains in > 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true. > >> > > >> > Is this is how we want it? And how should this be > documented/explained? > >> > >> I think I changes this :-) > >> > >> It didn't make sense that == and === produce different results. > >> > >> Though if someone has a better understanding of maths then we can fix > it. > > > > I think it does make sense. == is the equal operator, and INF is not > > equal to INF (just like SQL NULL is not equal to NULL). However, they > > are identical (like you can test in SQL with NULL IS NULL). > > > > cheers, > > Derick > > > > -- > > http://derickrethans.nl | http://xdebug.org > > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > > twitter: @derickr and @xdebug > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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:
>
> $a = {"a":"b"};
>
> Then the temptation would be to write something like:
>
> // $json_string is {"a":"b"}
> $a = eval($json_string);
>
> just as Javascript programmers sometimes do. That would have the same
> security implications as it has in Javasctipt - somebody could inject
> executable code there, etc. Of course, nobody forces you to do this, but the
> temptation would be there.
>
> Also, with full JSON support it is not entirely clear to me what {"a": "b"}
> would mean - is it an array or an object? In JS, it's definitely an object,
> but in PHP objects are almost never used to store pure state without
> behavior, because we have hashtable arrays, while JS only has vector arrays.
> So here we have some unclear point (which does not happen with [] syntax,
> since with [] it's obvious we're talking about arrays, just as in many other
> languages).
> --
> 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
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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: 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
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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':1, 'two':2, 'three' : 3] // array('one'=>1, 'two'=>2, 'three' => 3)
['one':1, 'two':2, 'three' : 3] // (object)array('one'=>1, 'two'=>2, 'three'
=> 3)
Regards,
David
On Tue, May 31, 2011 at 4: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 like:
>
> // $json_string is {"a":"b"}
> $a = eval($json_string);
>
> just as Javascript programmers sometimes do. That would have the same
> security implications as it has in Javasctipt - somebody could inject
> executable code there, etc. Of course, nobody forces you to do this, but the
> temptation would be there.
>
> Also, with full JSON support it is not entirely clear to me what {"a": "b"}
> would mean - is it an array or an object? In JS, it's definitely an object,
> but in PHP objects are almost never used to store pure state without
> behavior, because we have hashtable arrays, while JS only has vector arrays.
> So here we have some unclear point (which does not happen with [] syntax,
> since with [] it's obvious we're talking about arrays, just as in many other
> languages).
>
> --
> 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
>
>
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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://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 start a real thread about > it. The reason the RFC stalled was stated as: > > "This patch will not be accepted because slight majority of the core > developers voted against. Though if you take a accumulated mean between core > developers and userland votes seems to show the opposite it would be > irresponsible to submit a patch witch is not supported or maintained in the > long run." > > So, the PHP users want it, but too many PHP core devs did not want it or did > not see the use of it. From rereading the mailing list archive, most had the > tone of "I don't see a reason for it." I was in that camp in 2003 when it > first came up. However, with the emergence of JSON and systems that use JSON > as an interface, this type of syntax would be most welcome in the day to day > life of a PHP developer. > > 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. > > PHP SVN account holder voters > = > Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav > Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic > > Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, > Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, > Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem > Maas, Hannes Magnusson, David Coallier > > > Other voters > > Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, > Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, > Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly > Negyesi, Guilherme Blanco, Jonathan-Bond Caron > > Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke > > > -- > Brian. > http://brian.moonspot.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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, 2011 at 2: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 like:
>
> // $json_string is {"a":"b"}
> $a = eval($json_string);
>
> just as Javascript programmers sometimes do. That would have the same
> security implications as it has in Javasctipt - somebody could inject
> executable code there, etc. Of course, nobody forces you to do this, but the
> temptation would be there.
>
> Also, with full JSON support it is not entirely clear to me what {"a": "b"}
> would mean - is it an array or an object? In JS, it's definitely an object,
> but in PHP objects are almost never used to store pure state without
> behavior, because we have hashtable arrays, while JS only has vector arrays.
> So here we have some unclear point (which does not happen with [] syntax,
> since with [] it's obvious we're talking about arrays, just as in many other
> languages).
>
> --
> 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
>
>
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 like:
>
> // $json_string is {"a":"b"}
> $a = eval($json_string);
We could perhaps catch that case. I'm not sure that is a reason to
reject the idea. People who use eval() on user-supplied data are already
lost causes and trying to design for that case is tricky.
> Also, with full JSON support it is not entirely clear to me what {"a":
> "b"} would mean - is it an array or an object? In JS, it's definitely an
> object, but in PHP objects are almost never used to store pure state
> without behavior, because we have hashtable arrays, while JS only has
> vector arrays. So here we have some unclear point (which does not happen
> with [] syntax, since with [] it's obvious we're talking about arrays,
> just as in many other languages).
Right, this is a trickier issue. In order to handle both associative
arrays and objects the PHP notation would need to be along the lines of:
[ 1,2,3 ] - Scalar array
[ 'a':1, 'b':2 ] - Associative array
{ 'a':1, 'b':2 } - Stdclass object with properties a and b
of course the middle case is not valid json and then things break down a
bit. If we are going to support full json and then not be completely
compatible, why use the json syntax at all. And not supporting
associative arrays in the syntax is not an option.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 as Javascript programmers sometimes do. That would have the same
security implications as it has in Javasctipt - somebody could inject
executable code there, etc. Of course, nobody forces you to do this, but
the temptation would be there.
Also, with full JSON support it is not entirely clear to me what {"a":
"b"} would mean - is it an array or an object? In JS, it's definitely an
object, but in PHP objects are almost never used to store pure state
without behavior, because we have hashtable arrays, while JS only has
vector arrays. So here we have some unclear point (which does not happen
with [] syntax, since with [] it's obvious we're talking about arrays,
just as in many other languages).
--
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
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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
>> 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.
>
> 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 would be
> very valuable to me.
The tricky part with going all json is the syntax, specifically the {}'s
But I think it is doable, mostly because this is not valid today:
$a = true ? { 1 : 2 };
And in json if you have {}'s you have to have a ':' inside.
I have always preferred to "borrow" a familiar syntax from other
languages that the average PHP user is comfortable with instead of
making up a new one.
Stas, I didn't understand your point about eval() and security. What did
you mean?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 reverse his > thoughts as well (with caveats), I thought I would start a real thread about > it. The reason the RFC stalled was stated as: > I am very much +1 for this. I would also like to note the sooner we get it in the sooner it can actually be adopted as most hosting providers are a couple years behind of latest release, so I hope we can build some momentum this time around and get a solid "feature" that the user base wants. In addition I think the "Square bracket array shortcut - keys and values are separated by colons:" is the way to go. Thanks, -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 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. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 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.
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 would be very
valuable to me.
I would be happy to find some time to participate in RFC reform for this
subject.
That said:
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 would be very valuable to me.
It looks appealing, though if you think about security implications, I'm
not sure it'd be actually as useful as one might think - i.e., you'd
rarely want to eval() a JSON string, and absent that native JSON may not
help you much.
That aside, I think [] as array syntax is long overdue and would improve
PHP readability and compatibility with other dynamic languages.
--
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
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
>> 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 a +1, was not present during first vote. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 think it would be beneficial because: - Frameworks and Libraries are becoming more verbose as they support more modular designs. The more PHP as a language can do to help developers make their frameworks less verbose (like supporting JSON like notations), the happier developers will be. - Most developers are familiar with JSON, so the learning curve for this notation would be low. - While short hand for arrays would be nice, some developers are moving to use objects more over arrays, so a shorthand that supports both arrays and objects would be great. But the bottom line is I would love to help put together whatever is required for a new RFC, and do anything to help others who don't see the use for the short notation. Justin Carmony On May 31, 2011, at 12: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 his thoughts > as well (with caveats), I thought I would start a real thread about it. The > reason the RFC stalled was stated as: > > "This patch will not be accepted because slight majority of the core > developers voted against. Though if you take a accumulated mean between core > developers and userland votes seems to show the opposite it would be > irresponsible to submit a patch witch is not supported or maintained in the > long run." > > So, the PHP users want it, but too many PHP core devs did not want it or did > not see the use of it. From rereading the mailing list archive, most had the > tone of "I don't see a reason for it." I was in that camp in 2003 when it > first came up. However, with the emergence of JSON and systems that use JSON > as an interface, this type of syntax would be most welcome in the day to day > life of a PHP developer. > > 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. > > PHP SVN account holder voters > = > Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav > Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic > > Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, > Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, > Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, > Hannes Magnusson, David Coallier > > > Other voters > > Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, > Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, > Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly > Negyesi, Guilherme Blanco, Jonathan-Bond Caron > > Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke > > > -- > Brian. > http://brian.moonspot.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-DEV] INF behavior
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: > >> On 26 May 2011, at 20:03, Philip Olson wrote: >> >> > Hello geeks, >> > >> > A geek is needed to clarify PHP bug #45712. This is an edge case but the >> > test (bug45712.phpt) contains code similar to the following: >> > >> > > > $inf = pow(0, -2); >> > >> > var_dump($inf); // float(INF) >> > var_dump($inf == $inf); // bool(false) >> > var_dump($inf === $inf); // bool(true) >> > ?> >> > >> > That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, >> > but PHP 5.4.0-dev changes behavior so both now return true. >> > >> > Is this is how we want it? And how should this be documented/explained? >> >> I think I changes this :-) >> >> It didn't make sense that == and === produce different results. >> >> Though if someone has a better understanding of maths then we can fix it. > > I think it does make sense. == is the equal operator, and INF is not > equal to INF (just like SQL NULL is not equal to NULL). However, they > are identical (like you can test in SQL with NULL IS NULL). > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] INF behavior
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 changes then this is how INF will be documented. And please inform the documentation team if this changes. ;) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
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 than it is worth, though, as it is quite close to the existing ()-braced format, only with [], thus possibly disturbing new users of the language. The first syntax, being more remote from the normal array() initializer format, might well be less disturbing. But in that case, it might just as well be completely handle a complete JSON initialization format, without the need for a json_decode(). Le Tue, 31 May 2011 20:42:18 +0200, Brian Moon a écrit: 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 start a real thread about it. The reason the RFC stalled was stated as: "This patch will not be accepted because slight majority of the core developers voted against. Though if you take a accumulated mean between core developers and userland votes seems to show the opposite it would be irresponsible to submit a patch witch is not supported or maintained in the long run." So, the PHP users want it, but too many PHP core devs did not want it or did not see the use of it. From rereading the mailing list archive, most had the tone of "I don't see a reason for it." I was in that camp in 2003 when it first came up. However, with the emergence of JSON and systems that use JSON as an interface, this type of syntax would be most welcome in the day to day life of a PHP developer. 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. PHP SVN account holder voters = Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, Hannes Magnusson, David Coallier Other voters Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly Negyesi, Guilherme Blanco, Jonathan-Bond Caron Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke -- Utilisant le logiciel de courrier révolutionnaire d'Opera : http://www.opera.com/mail/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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/todo/php54 )
And since I voted against it last time around, here's my take (quoting myself
here from the recent 5.4 thread):
"I'm changing my old vote, so -1 to +1. Changes and additions to syntax may (or
may not) slow adoption, but since other such changes are being made then let's
do it. And while explicit code (e.g., array()) is nice, many people are
familiar with array shortcuts."
I think the main question is if related features (e.g., inline array slicing)
should also be implemented. Once upon a time the $arr{} syntax almost did that.
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
+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 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.
>
> 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 would be
> very valuable to me.
>
> I would be happy to find some time to participate in RFC reform for this
> subject.
>
> That said:
>
>> PHP SVN account holder voters
>> =
>> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
>> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> +1 (sean)
>
> S
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
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 (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.
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 would be very
valuable to me.
I would be happy to find some time to participate in RFC reform for this
subject.
That said:
> PHP SVN account holder voters
> =
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
+1 (sean)
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Short syntax for Arrays (redux)
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 start a real thread about it. The reason the RFC stalled was stated as: "This patch will not be accepted because slight majority of the core developers voted against. Though if you take a accumulated mean between core developers and userland votes seems to show the opposite it would be irresponsible to submit a patch witch is not supported or maintained in the long run." So, the PHP users want it, but too many PHP core devs did not want it or did not see the use of it. From rereading the mailing list archive, most had the tone of "I don't see a reason for it." I was in that camp in 2003 when it first came up. However, with the emergence of JSON and systems that use JSON as an interface, this type of syntax would be most welcome in the day to day life of a PHP developer. 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. PHP SVN account holder voters = Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, Hannes Magnusson, David Coallier Other voters Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly Negyesi, Guilherme Blanco, Jonathan-Bond Caron Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke -- Brian. http://brian.moonspot.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Typecasting in ArrayObject::offsetGet and ArrayObject::offsetSet
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 number beyond the bounds of the integer type, it will be
interpreted as a float instead. Also, an operation which results in a number
beyond the bounds of the integer type will return a float instead.
So, integer is casted to float, then it's passed to
ArrayObject::offsetSet and is casted back to integer, probably due to
the following lines (ext/spl/spl_array.c:348):
if (offset->type == IS_DOUBLE) {
index = (long)Z_DVAL_P(offset);
} else {
index = Z_LVAL_P(offset);
}
As a result of calling ArrayObject::offsetSet(index, value) on x86 with
a float index exceeds 'long', value appears under a non-obvious index
and is replaced on every other call with greater than 'long' index.
Tests are attached. test_array.phpt is passed on both x86 and x86_64,
test_array_object.phpt fails to pass on x86 (but is passed on x86_64).
This difference in array's and ArrayObject's behavior made me to
consider this a bug.
array_object_error.php on x86 just makes pretty clear the reason of fail
(see notices PHP throws).
--TEST--
test 1
--FILE--
--TEST--
test 1
--FILE--
<>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing some cruft
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 need such content in phpinfo() you could simply embed the picture in HTML using the data: scheme. On 31 May 2011 15:57, Philip Olson wrote: > > 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 also have other possibilities here (this is not a proposal, but rather, > a list of options/ideas to ponder): > > 0. Do nothing > > 1. Disable expose_php within the distributed php.ini-* files > > Trivial, but changing [at least] php.ini-production is a real possibility. > > 2. Disable expose_php by default within PHP > > We could do this too. Default === when no php.ini file is used. > > 3. Remove the specific PHP version from the exposed PHP header > > There are security concerns although I'm not sure what implications (BC?) > or real help this would offer. For example, version information can be > deciphered by other means (e.g., logos and credits change over time) but > maybe it's a help because, for example, displaying phpinfo() requires direct > user action. See also #4. > > 4. Change its behavior and usage > > For example, phpinfo() relies upon expose_php for both the logo and credits > information to be displayed. However, the phpinfo() output clearly exposes > PHP (along with the version) regardless of the expose_php setting so we > could instead embed the logo into phpinfo(), and display credits as per > phpcredits(), instead of relying upon expose_php for this as done currently. > In other words, expose_php could be off yet phpinfo() behavior would remain > close to the same with either a little extra markup, or appended credits > near the license. > > But this raises the question: Why do we have magical logo and credit guids? > > 5. And a performance review > > People are concerned with performance issues (e.g., images loaded into > memory) although I'm not sure what real performance is lost (some have made > guesses). Is there a real issue with performance here? How does it compare > with, let's say, loading an additional extension? If so, how can it be > helped? > > Regards, > Philip > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] removing some cruft
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 also have other possibilities here (this is not a proposal, but rather, a list of options/ideas to ponder): 0. Do nothing 1. Disable expose_php within the distributed php.ini-* files Trivial, but changing [at least] php.ini-production is a real possibility. 2. Disable expose_php by default within PHP We could do this too. Default === when no php.ini file is used. 3. Remove the specific PHP version from the exposed PHP header There are security concerns although I'm not sure what implications (BC?) or real help this would offer. For example, version information can be deciphered by other means (e.g., logos and credits change over time) but maybe it's a help because, for example, displaying phpinfo() requires direct user action. See also #4. 4. Change its behavior and usage For example, phpinfo() relies upon expose_php for both the logo and credits information to be displayed. However, the phpinfo() output clearly exposes PHP (along with the version) regardless of the expose_php setting so we could instead embed the logo into phpinfo(), and display credits as per phpcredits(), instead of relying upon expose_php for this as done currently. In other words, expose_php could be off yet phpinfo() behavior would remain close to the same with either a little extra markup, or appended credits near the license. But this raises the question: Why do we have magical logo and credit guids? 5. And a performance review People are concerned with performance issues (e.g., images loaded into memory) although I'm not sure what real performance is lost (some have made guesses). Is there a real issue with performance here? How does it compare with, let's say, loading an additional extension? If so, how can it be helped? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode (was What's up with Quercus?)
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 solves two problems).
> >
> > magic_quotes did the same thing than manually addslashing every
> > argument AFAIK, so I can't see why you say they couldn't be used
> > interchangeably.
> > the problem with magic was the magic part, addslashes is a valid
> > feature on its own.
>
> It is not that magic_quotes and addslashes() can't be used
> interchangeably, it is that addslashes() shouldn't be used either.
> addslashes() isn't aware of other characters sets, so it won't add slashes
> to everything it should. It works fine for ASCII, but will probably open up
> a security hole when used on UTF8 strings. Even the addslashes() manual
> page, highly recommends you don't use addslashes().
>
>
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
fortunately there aren't many cases, when this can be turned into a
successful attack, but this can be exploited.
unfortunately many people doesn't aware of this, but
mysql_real_escape_string can be vulnerable also, if you doesn't use the
mysql_set_charset method but the mysql_query('SET NAMES ...');
> Ideally, addslashes() should be added to the deprecation list too. It
> will have to be removed (or somehow fixed) as part of "Full Unicode" support
> anyways.
>
agree
>
> That is why I think the deprecation of features for PHP6 was more
> important than Unicode. It makes PHP6 secure (well, more secure) by
> default.
>
>
it will abolish the false sense of security, but I think we will think many
cases, where hosting providers upgrade without proper testing, and a whole
bunch of php application will be vulnerable without features like
magic_quotes or safe_mode
but I hope that I will be proven wrong, and I think that we waited long
enough already.
Tyrael
Re: [PHP-DEV] Unicode (was What's up with Quercus?)
> > 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 manually addslashing every > argument AFAIK, so I can't see why you say they couldn't be used > interchangeably. > the problem with magic was the magic part, addslashes is a valid > feature on its own. It is not that magic_quotes and addslashes() can't be used interchangeably, it is that addslashes() shouldn't be used either. addslashes() isn't aware of other characters sets, so it won't add slashes to everything it should. It works fine for ASCII, but will probably open up a security hole when used on UTF8 strings. Even the addslashes() manual page, highly recommends you don't use addslashes(). Ideally, addslashes() should be added to the deprecation list too. It will have to be removed (or somehow fixed) as part of "Full Unicode" support anyways. That is why I think the deprecation of features for PHP6 was more important than Unicode. It makes PHP6 secure (well, more secure) by default. > Tyrael Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode (was What's up with Quercus?)
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 into 5.5? > > > > it would be a good thing, but nobody stepped up for that, and it > > seems that somehow it isn't really important for the internals. > > This happens in every open source project. You can't expect a group of > open source developers to develop what you ask for. So, it isn't the fault > of "internals" that no one is stepping up. Go onto any open source > developers mailing list, and send a "You guys should do X", and you'll see > the exact same thing happen. > > you was the one who proposed that we should have this rolled. I just said that nobody took the responsibility to push this forward. so actually you are the one who said that "You guys should do X" > On top of that, where is no concept for what Unicode-for-PHP should be. > There was for the previous (now deemed to have failed) project, including > UTF16. But should it be UTF16 or UTF8 or should both be supported? Unicode > identifiers...yes or no? I'm quite interested what everyone's Unicode > wishlist would look like. > > without somobody who is commited to the cause and has the neccessary technical knowledge both in the php core and in unicode stuff, this kind of discussions is deemed to fail. personally I would go for UTF-8, as Andrei suggested, and also expose the ICU facility to the php userland(extend/polish the intl ext.) the main problem was with the previous attempt that we had to rewrite a whole lot of code to make them unicode aware and that didn't work out. we should take this into account, and probably come up with some middle-ground implementation, which is maybe a second class citizen, or slower that, both it would be better that we have with mbstring, and we won't screw up the people who don't need it. > > > But right now, there is this impression of failure, and implication > > > that PHP has no Unicode, because a project to add UTF16 to > > > everything in PHP wasn't completed. > > > > yes there is the impression, Unicode support was the flagship feature > > of the PHP6 release. > > Actually, for me, the deprecated features were far more important than > Unicode, as I can create Unicode web apps right now. thats weird, I mean I agree that killing some bad decisions after 10 years is a good thing, but I wouldn't upgrade to PHP6 for that alone. > 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 manually addslashing every argument AFAIK, so I can't see why you say they couldn't be used interchangeably. the problem with magic was the magic part, addslashes is a valid feature on its own. Tyrael
Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU
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. Wouldn't it work? > If you have to recompile PHP without mbstring to use the replacement then I think it's doesn't really matter that you can install this through pecl, or not. of course it's better to have this in the PECL repo than not having it at all. Tyrael
Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU
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: 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
Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU
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 it was a drop-in-replacement, so a pecl ext doesn't make much sense. As for it being 100%, probably not - but there are still several months to go. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode (was What's up with Quercus?)
> > 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 that, and it > seems that somehow it isn't really important for the internals. This happens in every open source project. You can't expect a group of open source developers to develop what you ask for. So, it isn't the fault of "internals" that no one is stepping up. Go onto any open source developers mailing list, and send a "You guys should do X", and you'll see the exact same thing happen. On top of that, where is no concept for what Unicode-for-PHP should be. There was for the previous (now deemed to have failed) project, including UTF16. But should it be UTF16 or UTF8 or should both be supported? Unicode identifiers...yes or no? I'm quite interested what everyone's Unicode wishlist would look like. > > But right now, there is this impression of failure, and implication > > that PHP has no Unicode, because a project to add UTF16 to > > everything in PHP wasn't completed. > > yes there is the impression, Unicode support was the flagship feature > of the PHP6 release. Actually, for me, the deprecated features were far more important than Unicode, as I can create Unicode web apps right now. 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). > of course we can rationalize the importance of the full unicode > support, or redefine success, but that won't change the facts that 5 > years of work on I18n was botched with PHP6. Five years, without a being able to release even a single minimally implemented feature, is definitely a lesson learned. If you have been coding for a year, and there isn't anything that you can release, you need to make radical changes to what you've been doing. > Tyrael Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU
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. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU
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: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
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 bytecode. However, if you want Java frameworks, you'd probably have to code along the guidelines that are expected from Java programmers, at which point I'm not sure how useful it would be to code it in PHP. If you want to just call out to Java libraries, there are multiple ways of interfacing (webservices, java bridges, etc.) but more tight integration may not actually be beneficial. That being said - if somebody does it, all power to them, we'll see what comes out of 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
Re: [PHP-DEV] Unicode (was What's up with Quercus?)
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 people want out of that project that they didn't get? no, that explains what was the originals goals, which isn't just getting unicode support, but a full internationalization support, and how that failed by the lack of support and understanding. > 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 that, and it seems that somehow it isn't really important for the internals. > > But right now, there is this impression of failure, and implication that > PHP has no Unicode, because a project to add UTF16 to everything in PHP > wasn't completed. > > yes there is the impression, Unicode support was the flagship feature of the PHP6 release. of course we can rationalize the importance of the full unicode support, or redefine success, but that won't change the facts that 5 years of work on I18n was botched with PHP6. Tyrael
Re: [PHP-DEV] Fwd: What's up with Quercus?
... > 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 the native PHP runtime. I think you are assuming that the bit of code that converts PHP to JVM bytecode (and/or a Java PHP interpreter) is an insignificant chunk of engineering. Quercus has lagged PHP5 development, and it needs work in order to run common apps. Plus, an analog of the Ruby RSpec project will probably have to be built for PHP (PHPSpec?). The PHP5 implementation is the spec right now, just like Ruby (used to be). Quercus is currently a component of a commercial Java application server. Can Quercus can be run in another app server, like Jetty, or does it only work in Resin? I doubt that Caucho would be interesting in making Quercus work stand alone. Quercus will probably need to be forked. That is quite a lot of work. How many people did it take to create JRuby (Ruby on the JVM) and the RSpec project? From the mailing list, it looks like it was about 5 to 8 core developers over about 2 years. And then after all that, JRuby is still not the preferred deployment environment for Ruby (it's mod_rails aka Passenger). Though, RSpec did end up making the original Ruby implementation better. I'm not opposed to PHP on the JVM, but it is not a small undertaking. You should probably begin by extracting the Quercus code from from the Caucho subversion repository, and import it into a new github repository, and then see if you can get Quercus to run without Resin. > As far as HipHop, from what I've seen it holds zero interest for me > right now. If you're FaceBook, and you're spending hundreds of > millions of dollars on servers every year then squeezing 5% or 10% More like 50% to 100%. > more performance out of you code is probably worthwhile. But with > only a few hundred servers running the PHP applications I'm > responsible for, I'm much more interested in developing less-buggy > applications faster, leveraging other people's frameworks instead of PHP has shed loads of web frameworks too. > reinventing the wheel (hence my interest in Java), improving > monitoring and deployment, etc. > > -- Arnold Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
