next »

[DangerMouse]

Hey all,

Following on from the brief comments on PHP6 and UTF-8 support, I was wondering what the general consensus on the PHP6 proposed feature set was? Will you be making the switch?

http://houstonphp.org/presentations/bryan/php6_features.pdf - a fairly decent summary.

From my point of view as I don't really have any complex applications and I'm still learning its probably worth my while to jump on board straightaway. Although the one major feature (as far as I can tell) namespaces will apparently be appearing in PHP 5.3. I don't really have any applications large enough to reap the benefits of namespaces but I guess its kind of a best practice issue and will help my understanding of OO design.

DM

[perkiset]

That presentation makes PHP6 look like an incremental update (like 5.3) rather than a full version increase. NBs will be happy with the dropping of magicquotes LOL.

I dunno yet.. gonna have to see how stable it is. Couple nice feature make things a little easier (APC in core, for example) but nothing jumps out as a Gotta Have just yet.

[jammaster82]

NBs will be happy with the dropping of magicquotes LOL.

Whats the deal with magic quotes?

[vsloathe]

What *isn't* the deal with magic quotes?

[nutballs]

fuck magic quotes.

I now just run a magic-quotes un-magicifier.
the world is good now...

[Phaëton]

php6?!?!?!?!?!    How come i cant find anything substantial on this?


and yea i feel the magic quotes and goofy character pain... just
migrated some swedish phpbb board data to my machine... to
the tune of 8 hours.....  should have taken 30 minutes but
I had to figure out which versions of php/blah blah were all playing a part
in showing me something like :

----------------->           <------------------------------

in a line like:

INSERT INTO MYTABLE VALUES("

As opposed to VALUES(" with just a open paren and a double quote...

It was php doing it to the data somehow...

Supposedly php 6 was gonna fix this issue?   Im kinda confused..( not that this isnt now public record lol)
But im confused I used utf-8, which I *thought* would handle all ickies the right way but apparently not.

Magic quotes, mysql escape string... all these weird rules and tecnicals have wasted more of my time..
. shouldnt utf-8 or some other 'catch all' be the standard?

[perkiset]

UTF8 will help in a big way when you are sending/receiving data from a client. But in this case, your talking about the EDITOR having the problem I think.

Don't think php 6 or 6000 would help you with that, neither would you find much IMO because that would not be a php problem.

UNLESS what you just posted is debug line from someone hitting your BBS - in which case, it's more likely malicious post, trying to break. Your system or DB. 

[nutballs]

also. everything needs to be talking UTF8. I have had similar problems that I was never able to resolve because something along the way, either php, linux, or mysql (and inside mysql there are things to set like column, table and database collation) that seem to affect success.

then of course spitting out to the web, you have the browser, php, contenttype (both header and html declaration), etc etc. it sucks.

[nop_90]

There is no PHP 6
The versioning process of PHP has been exceptionally modified to clear the situation about the long-expected PHP 6. The last stable release, PHP 5.3.2, has been transformed in PHP 6 using the powerful Unix-based tool sed and finally released as PHP 6.0.

I am not 100% sure what the reason is.
Maybe for the same reason python 1.6 changed into python 2.0

[Phaëton]

Okay well i want to write some functions i can put in my toolbox to deal with this.


im going to write a process that :

extracts all data from a table and
converts the data to hex.

then put the hex data in an xml record.

then, hopefully i will have a charset agnostic view of the data?

i guess my question is if i create a table with one row of data
and store ascii 0-255 in it will that be an example of all the data
that could possibly be stored in a field or is there something else
i should consider..   the target being to create a sample table
with all possible characters in it... will ascii 0-255 utf-8 table
cover it or is there something else i should consider.

I want to store all characters and put some tests at each phase
of my functions to check to see at each point that the data is
true... what type of record would be all possible characters, i guess
is my question... so i can work from there, prove my process works with
a record containing all possible characters?

[perkiset]

hmm... "all possible" would have to include 0x00 which is a bitch to store in anything other than a BLOB (if it's in the middle of an array of characters)

[kurdt]

Naah.. after coding with Ruby there's nothing in PHP6 that was able raise even slightest of interest. Like perk said, looks like PHP 5.3 instead of a whole new version. One thing that would impress would be if they could get rid of ; endings and {} block markers. After coding with javascript and Ruby, remembering to write ; is really annoying. {} isn't that big deal but it just makes code more readable when you do and end. Of course those are only two things compared to Ruby that I could see PHP team implementing.. the rest would require to modify PHP to a whole new language

[vsloathe]

Naah.. after coding with Ruby there's nothing in PHP6 that was able raise even slightest of interest. Like perk said, looks like PHP 5.3 instead of a whole new version. One thing that would impress would be if they could get rid of ; endings and {} block markers. After coding with javascript and Ruby, remembering to write ; is really annoying. {} isn't that big deal but it just makes code more readable when you do and end. Of course those are only two things compared to Ruby that I could see PHP team implementing.. the rest would require to modify PHP to a whole new language

Code blocks and reverse conditionals, PLS PHP DEVS!

e.g.:

Code:

Math.rand() if myVar == 1

Also, give us nil!

[vsloathe]

In PHP I am stuck going:

Code:

<?php
( $myVar == 1 ? rand() : 0 )

stupid backwards notation