subject:"\[PHP\] CONVERT"

On Thu, 2010-05-27 at 21:45 +0800, Guus Ellenkamp wrote:

Thanks, but are you sure of that? I did some research a while ago and found
that officially PHP files should be ascii and not have any specific
character encoding. I believe it will work anyhow (did not try this one),
but would like to stick with the standards.

Ashley Sheridan a...@ashleysheridan.co.uk wrote in message
news:1274883714.2202.228.ca...@localhost...
On Wed, 2010-05-26 at 22:20 +0800, Guus Ellenkamp wrote:

We use PHP defines for defining text in different languages. As far as I
know PHP files are supposed to be ASCII, not UTF-8 or something like
that.
What I want to make is a conversion program that would convert a given
UTF-8
file with the format

definetext1=this is a text in random UTF-8, probably arabic or similar
text
definetext2=this is another text in random UTF-8, probably arabic or
similar
text

into a file with the following defines

define('definetext1',chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
define('definetext2,chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));

Not sure if I'm using the correct chr/ord function, but I hope the above
is
clear enough to make clear what I'm looking for. Basically the output
file
should be ascii and not contain any utf-8.

Any advise? The html_special_chars did not seem to work for Vietnamese
text
I tried to convert, so something seems to get wrong with just reading an
array of strings and converting the strings and putting them in defines.

PHP files can contain utf-8, and in-fact is the preference of most
developers I know of.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Very sure, ever PHP file I ever make is always in utf8. The only problem
you might encounter is when outputting HTML, you should make sure that
you output the right text encoding headers, as some browsers won't
correctly detect it and can tend to output utf-8 characters as random
blocks and other characters.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Convert UTF-8 to PHP defines

2010-05-27 Thread Adam Richardson

On Thu, May 27, 2010 at 9:45 AM, Guus Ellenkamp
ellenkamp_g...@hotmail.comwrote:

 Thanks, but are you sure of that? I did some research a while ago and found
 that officially PHP files should be ascii and not have any specific
 character encoding. I believe it will work anyhow (did not try this one),
 but would like to stick with the standards.

 Ashley Sheridan a...@ashleysheridan.co.uk wrote in message
 news:1274883714.2202.228.ca...@localhost...
  On Wed, 2010-05-26 at 22:20 +0800, Guus Ellenkamp wrote:
 
  We use PHP defines for defining text in different languages. As far as I
  know PHP files are supposed to be ASCII, not UTF-8 or something like
  that.
  What I want to make is a conversion program that would convert a given
  UTF-8
  file with the format
 
  definetext1=this is a text in random UTF-8, probably arabic or similar
  text
  definetext2=this is another text in random UTF-8, probably arabic or
  similar
  text
 
  into a file with the following defines
 
 
 define('definetext1',chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
 
 define('definetext2,chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
 
  Not sure if I'm using the correct chr/ord function, but I hope the above
  is
  clear enough to make clear what I'm looking for. Basically the output
  file
  should be ascii and not contain any utf-8.
 
  Any advise? The html_special_chars did not seem to work for Vietnamese
  text
  I tried to convert, so something seems to get wrong with just reading an
  array of strings and converting the strings and putting them in defines.
 
 
 
 
 
  PHP files can contain utf-8, and in-fact is the preference of most
  developers I know of.
 
  Thanks,
  Ash
  http://www.ashleysheridan.co.uk
 
 
 



 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php


Because the lower range of UTF-8 matches the ascii character set
(intentionally by design), you'll be able to use UTF-8 for PHP files without
problem (i.e., ascii 7-bit chars have same encoding in UTF-8.)
http://www.cl.cam.ac.uk/~mgk25/unicode.html

However, if you were to use any of the multibyte characters of UTF-8 in a
PHP file, you could run in to some trouble.  I use UTF-8 for most of my PHP
files, but I've been sticking to the ASCII subset exclusively.

Adam

-- 
Nephtali:  PHP web framework that functions beautifully
http://nephtaliproject.com

Re: [PHP] Convert UTF-8 to PHP defines

On Thu, 2010-05-27 at 12:08 -0400, Adam Richardson wrote:

 On Thu, May 27, 2010 at 9:45 AM, Guus Ellenkamp
 ellenkamp_g...@hotmail.comwrote:
 
  Thanks, but are you sure of that? I did some research a while ago and found
  that officially PHP files should be ascii and not have any specific
  character encoding. I believe it will work anyhow (did not try this one),
  but would like to stick with the standards.
 
  Ashley Sheridan a...@ashleysheridan.co.uk wrote in message
  news:1274883714.2202.228.ca...@localhost...
   On Wed, 2010-05-26 at 22:20 +0800, Guus Ellenkamp wrote:
  
   We use PHP defines for defining text in different languages. As far as I
   know PHP files are supposed to be ASCII, not UTF-8 or something like
   that.
   What I want to make is a conversion program that would convert a given
   UTF-8
   file with the format
  
   definetext1=this is a text in random UTF-8, probably arabic or similar
   text
   definetext2=this is another text in random UTF-8, probably arabic or
   similar
   text
  
   into a file with the following defines
  
  
  define('definetext1',chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
  
  define('definetext2,chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
  
   Not sure if I'm using the correct chr/ord function, but I hope the above
   is
   clear enough to make clear what I'm looking for. Basically the output
   file
   should be ascii and not contain any utf-8.
  
   Any advise? The html_special_chars did not seem to work for Vietnamese
   text
   I tried to convert, so something seems to get wrong with just reading an
   array of strings and converting the strings and putting them in defines.
  
  
  
  
  
   PHP files can contain utf-8, and in-fact is the preference of most
   developers I know of.
  
   Thanks,
   Ash
   http://www.ashleysheridan.co.uk
  
  
  
 
 
 
  --
  PHP General Mailing List (http://www.php.net/)
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 Because the lower range of UTF-8 matches the ascii character set
 (intentionally by design), you'll be able to use UTF-8 for PHP files without
 problem (i.e., ascii 7-bit chars have same encoding in UTF-8.)
 http://www.cl.cam.ac.uk/~mgk25/unicode.html
 
 However, if you were to use any of the multibyte characters of UTF-8 in a
 PHP file, you could run in to some trouble.  I use UTF-8 for most of my PHP
 files, but I've been sticking to the ASCII subset exclusively.
 
 Adam
 


I don't use the higher range of characters often, but I do sometimes use
them for things like the graphical glyphs (½✉✆, etc) I know I could do
those with regular text and the Wingdings font, but that's not available
on every computer, and breaks the semantic meaning behind the glyphs.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Convert UTF-8 to PHP defines

2010-05-27 Thread tedd


At 5:13 PM +0100 5/27/10, Ashley Sheridan wrote:


I don't use the higher range of characters often, but I do sometimes use
them for things like the graphical glyphs (12), etc) I know I could do
those with regular text and the Wingdings font, but that's not available
on every computer, and breaks the semantic meaning behind the glyphs.

Thanks,
Ash



Ash:

I read briefly on the css discuss list there is a 
movement to force download of fonts (i.e., char 
sets) to make layouts work. Apparently some 
browsers allow for that but I have not read up on 
it and I may have the wrong impression, but that 
was my take.


For the exception of evil fonts, it seemed like a good idea.

Cheers,

tedd
--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Convert UTF-8 to PHP defines

2010-05-27 Thread Bob McConnell

From: Ashley Sheridan

On Thu, 2010-05-27 at 12:08 -0400, Adam Richardson wrote:

 On Thu, May 27, 2010 at 9:45 AM, Guus Ellenkamp
 ellenkamp_g...@hotmail.comwrote:
 
  Thanks, but are you sure of that? I did some research a while ago and found
  that officially PHP files should be ascii and not have any specific
  character encoding. I believe it will work anyhow (did not try this one),
  but would like to stick with the standards.
 
  Ashley Sheridan a...@ashleysheridan.co.uk wrote in message
  news:1274883714.2202.228.ca...@localhost...
   On Wed, 2010-05-26 at 22:20 +0800, Guus Ellenkamp wrote:
  
   We use PHP defines for defining text in different languages. As far as I
   know PHP files are supposed to be ASCII, not UTF-8 or something like
   that.
   What I want to make is a conversion program that would convert a given
   UTF-8
   file with the format
  
   definetext1=this is a text in random UTF-8, probably arabic or similar
   text
   definetext2=this is another text in random UTF-8, probably arabic or
   similar
   text
  
   into a file with the following defines
  
  
  define('definetext1',chr(t_value).chr(h_value).chr(i_value)...
 chr(x_value).chr(t_value));
  
  define('definetext2,chr(t_value).chr(h_value).chr(i_value)...
 chr(x_value).chr(t_value));
  
   Not sure if I'm using the correct chr/ord function, but I hope the above
   is
   clear enough to make clear what I'm looking for. Basically the output
   file
   should be ascii and not contain any utf-8.
  
   Any advise? The html_special_chars did not seem to work for Vietnamese
   text
   I tried to convert, so something seems to get wrong with just reading an
   array of strings and converting the strings and putting them in defines.
  
   PHP files can contain utf-8, and in-fact is the preference of most
   developers I know of.
  
 
 Because the lower range of UTF-8 matches the ascii character set
 (intentionally by design), you'll be able to use UTF-8 for PHP files without
 problem (i.e., ascii 7-bit chars have same encoding in UTF-8.)
 http://www.cl.cam.ac.uk/~mgk25/unicode.html
 
 However, if you were to use any of the multibyte characters of UTF-8 in a
 PHP file, you could run in to some trouble.  I use UTF-8 for most of my PHP
 files, but I've been sticking to the ASCII subset exclusively.

 I don't use the higher range of characters often, but I do sometimes use
 them for things like the graphical glyphs (½✉✆, etc) I know I could do
 those with regular text and the Wingdings font, but that's not available
 on every computer, and breaks the semantic meaning behind the glyphs.

What higher range? ASCII only defined 128 values, the bottom 32 being control 
characters that don't print. Anything outside of that is not ASCII, but a 
proprietary extension. In particular, the glyphs usually associated with 0-32 
and 128-255 are IBM specific and not guaranteed to be present outside of their 
original video ROM. So only the first 128 characters map directly into UTF-8.

Bob McConnell

Ref: pp 25-29 The Programmer's PC Sourcebook, 1988, Thom Hogan, Microsoft Press

RE: [PHP] Convert UTF-8 to PHP defines

On Thu, 2010-05-27 at 14:06 -0400, Bob McConnell wrote:

 From: Ashley Sheridan
 
 On Thu, 2010-05-27 at 12:08 -0400, Adam Richardson wrote:
 
  On Thu, May 27, 2010 at 9:45 AM, Guus Ellenkamp
  ellenkamp_g...@hotmail.comwrote:
  
   Thanks, but are you sure of that? I did some research a while ago and 
   found
   that officially PHP files should be ascii and not have any specific
   character encoding. I believe it will work anyhow (did not try this one),
   but would like to stick with the standards.
  
   Ashley Sheridan a...@ashleysheridan.co.uk wrote in message
   news:1274883714.2202.228.ca...@localhost...
On Wed, 2010-05-26 at 22:20 +0800, Guus Ellenkamp wrote:
   
We use PHP defines for defining text in different languages. As far 
as I
know PHP files are supposed to be ASCII, not UTF-8 or something like
that.
What I want to make is a conversion program that would convert a given
UTF-8
file with the format
   
definetext1=this is a text in random UTF-8, probably arabic or similar
text
definetext2=this is another text in random UTF-8, probably arabic or
similar
text
   
into a file with the following defines
   
   
   define('definetext1',chr(t_value).chr(h_value).chr(i_value)...
  chr(x_value).chr(t_value));
   
   define('definetext2,chr(t_value).chr(h_value).chr(i_value)...
  chr(x_value).chr(t_value));
   
Not sure if I'm using the correct chr/ord function, but I hope the 
above
is
clear enough to make clear what I'm looking for. Basically the output
file
should be ascii and not contain any utf-8.
   
Any advise? The html_special_chars did not seem to work for Vietnamese
text
I tried to convert, so something seems to get wrong with just reading 
an
array of strings and converting the strings and putting them in 
defines.
   
PHP files can contain utf-8, and in-fact is the preference of most
developers I know of.
   
  
  Because the lower range of UTF-8 matches the ascii character set
  (intentionally by design), you'll be able to use UTF-8 for PHP files 
  without
  problem (i.e., ascii 7-bit chars have same encoding in UTF-8.)
  http://www.cl.cam.ac.uk/~mgk25/unicode.html
  
  However, if you were to use any of the multibyte characters of UTF-8 in a
  PHP file, you could run in to some trouble.  I use UTF-8 for most of my PHP
  files, but I've been sticking to the ASCII subset exclusively.
 
  I don't use the higher range of characters often, but I do sometimes use
  them for things like the graphical glyphs (½✉✆, etc) I know I could do
  those with regular text and the Wingdings font, but that's not available
  on every computer, and breaks the semantic meaning behind the glyphs.
 
 What higher range? ASCII only defined 128 values, the bottom 32 being control 
 characters that don't print. Anything outside of that is not ASCII, but a 
 proprietary extension. In particular, the glyphs usually associated with 0-32 
 and 128-255 are IBM specific and not guaranteed to be present outside of 
 their original video ROM. So only the first 128 characters map directly into 
 UTF-8.
 
 Bob McConnell
 
 Ref: pp 25-29 The Programmer's PC Sourcebook, 1988, Thom Hogan, Microsoft 
 Press


The higher range of utf8 characters that don't map to ascii values.

Thanks,
Ash
http://www.ashleysheridan.co.uk

RE: [PHP] Convert UTF-8 to PHP defines

2010-05-27 Thread tedd


At 7:11 PM +0100 5/27/10, Ashley Sheridan wrote:

On Thu, 2010-05-27 at 14:06 -0400, Bob McConnell wrote:
  From: Ashley Sheridan
   I don't use the higher range of characters often, but I do sometimes use

  them for things like the graphical glyphs (12), etc) I know I could do
  those with regular text and the Wingdings font, but that's not available
  on every computer, and breaks the semantic meaning behind the glyphs.

 What higher range? ASCII only defined 128 
values, the bottom 32 being control characters 
that don't print. Anything outside of that is 
not ASCII, but a proprietary extension. In 
particular, the glyphs usually associated with 
0-32 and 128-255 are IBM specific and not 
guaranteed to be present outside of their 
original video ROM. So only the first 128 
characters map directly into UTF-8.


 Bob McConnell

 Ref: pp 25-29 The Programmer's PC Sourcebook, 
1988, Thom Hogan, Microsoft Press



The higher range of utf8 characters that don't map to ascii values.

Thanks,
Ash


Bob:

I understood what Ash was referring re his 
higher range statement, but his second 
statement was somewhat confusing.


ASCII is defined as characters having a value of 
0-127 DEC (00-7F HEX). The higher range of 
128-255 DEC (80-FF HEX) have been loosely 
characterized as extended ASCII but have not 
been officially declared such. Both M$ and Apple 
have their own characters appearing the range and 
have used different character for different 
things -- thus problems arose is using either. I 
do not know if the problem was ever resolved. 
It's probably best to never use such characters.


The Unicode database uses the same lower 
character values (i.e., code points) as does 
ASCII, namely 0-127, and thus UFT-8 (8-bit 
variable width encoding) is really a super-set 
which includes the sub-set of ASCII.


The Wingdings font that Ash refers to is the 
really the Dingbat char set in Unicode, as 
shown here:


http://www.unicode.org/charts/PDF/U2700.pdf

These are real characters that can be used for 
all sorts of things including url's, for example:


http://xn--gci.com

Please forgive the PUNYCODE url, but IE does not 
recognize other than ASCII characters in url's, 
whereas Safari will show the url correctly. 
Clearly, Safari has the upper hand in resolving 
other than English issues -- perhaps that's why 
their overseas profits last year exceeded their 
domestic -- but I digress.


The use of UFT-8 encoding in everything (web and 
php) should present much less problems globally 
than it is trying to fight it.


Here's some references that may help:

[1] http://webstandardsgroup.org/
[2] http://www.w3.org/People/Ishida/
[3] http://www.w3.org/International
[4] http://shiflett.org/archive/177
[5] http://en.wikipedia.org/wiki/Universal_character_set
[6] http://www.unicode.org/

Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Convert UTF-8 to PHP defines

2010-05-27 Thread Bob McConnell

From: tedd

 The Unicode database uses the same lower 
 character values (i.e., code points) as does 
 ASCII, namely 0-127, and thus UFT-8 (8-bit 
 variable width encoding) is really a super-set 
 which includes the sub-set of ASCII.
 
 The Wingdings font that Ash refers to is the 
 really the Dingbat char set in Unicode, as 
 shown here:
 
 The use of UFT-8 encoding in everything (web and 
 php) should present much less problems globally 
 than it is trying to fight it.

Thanks tedd,

The real question is whether unicode is even relevant now that the UTF
series is available. I see no reason to have to deal with two competing
specifications, when one of them is more than adequate for the job and
the other is not even finished yet. That's like the old days when a few
users demanded we support both ASCII and EBCDIC. That didn't get very
far either.

Bob McConnell

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Convert UTF-8 to PHP defines

On Thu, 2010-05-27 at 15:28 -0400, Bob McConnell wrote:

 From: tedd
 
  The Unicode database uses the same lower 
  character values (i.e., code points) as does 
  ASCII, namely 0-127, and thus UFT-8 (8-bit 
  variable width encoding) is really a super-set 
  which includes the sub-set of ASCII.
  
  The Wingdings font that Ash refers to is the 
  really the Dingbat char set in Unicode, as 
  shown here:
  
  The use of UFT-8 encoding in everything (web and 
  php) should present much less problems globally 
  than it is trying to fight it.
 
 Thanks tedd,
 
 The real question is whether unicode is even relevant now that the UTF
 series is available. I see no reason to have to deal with two competing
 specifications, when one of them is more than adequate for the job and
 the other is not even finished yet. That's like the old days when a few
 users demanded we support both ASCII and EBCDIC. That didn't get very
 far either.
 
 Bob McConnell
 


Bob, UTF is unicode (Unicode Transformation Format)

Interesting enough to note, and not sure if Tedd knows this or not (he
probably does!) but Chrome has a nice feature for those punycode URLs;
it suggests the actual real URL instead once you type the domain in. Not
sure about Safari right now, couldn't be bothered to fire up a VM just
to check. I would assume Firefox handles these URLs well enough too.

Tedd, does that URL actually go anywhere, as I got nothing when I tried
visiting it, both the actual URL and the punycode version.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Convert UTF-8 to PHP defines

2010-05-27 Thread Guus Ellenkamp

And I need(ed) this stuff especially for non-ASCII characters like Chinese, 
Arabic and stuff :)

Ashley Sheridan a...@ashleysheridan.co.uk wrote in message 
news:1274976794.2202.274.ca...@localhost...
On Thu, 2010-05-27 at 12:08 -0400, Adam Richardson wrote:

 On Thu, May 27, 2010 at 9:45 AM, Guus Ellenkamp
 ellenkamp_g...@hotmail.comwrote:

  Thanks, but are you sure of that? I did some research a while ago and 
  found
  that officially PHP files should be ascii and not have any specific
  character encoding. I believe it will work anyhow (did not try this 
  one),
  but would like to stick with the standards.
 
  Ashley Sheridan a...@ashleysheridan.co.uk wrote in message
  news:1274883714.2202.228.ca...@localhost...
   On Wed, 2010-05-26 at 22:20 +0800, Guus Ellenkamp wrote:
  
   We use PHP defines for defining text in different languages. As far 
   as I
   know PHP files are supposed to be ASCII, not UTF-8 or something like
   that.
   What I want to make is a conversion program that would convert a 
   given
   UTF-8
   file with the format
  
   definetext1=this is a text in random UTF-8, probably arabic or 
   similar
   text
   definetext2=this is another text in random UTF-8, probably arabic or
   similar
   text
  
   into a file with the following defines
  
  
  define('definetext1',chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
  
  define('definetext2,chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
  
   Not sure if I'm using the correct chr/ord function, but I hope the 
   above
   is
   clear enough to make clear what I'm looking for. Basically the output
   file
   should be ascii and not contain any utf-8.
  
   Any advise? The html_special_chars did not seem to work for 
   Vietnamese
   text
   I tried to convert, so something seems to get wrong with just reading 
   an
   array of strings and converting the strings and putting them in 
   defines.
  
  
  
  
  
   PHP files can contain utf-8, and in-fact is the preference of most
   developers I know of.
  
   Thanks,
   Ash
   http://www.ashleysheridan.co.uk
  
  
  
 
 
 
  --
  PHP General Mailing List (http://www.php.net/)
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 Because the lower range of UTF-8 matches the ascii character set
 (intentionally by design), you'll be able to use UTF-8 for PHP files 
 without
 problem (i.e., ascii 7-bit chars have same encoding in UTF-8.)
 http://www.cl.cam.ac.uk/~mgk25/unicode.html

 However, if you were to use any of the multibyte characters of UTF-8 in a
 PHP file, you could run in to some trouble.  I use UTF-8 for most of my 
 PHP
 files, but I've been sticking to the ASCII subset exclusively.

 Adam



I don't use the higher range of characters often, but I do sometimes use
them for things like the graphical glyphs (½??, etc) I know I could do
those with regular text and the Wingdings font, but that's not available
on every computer, and breaks the semantic meaning behind the glyphs.

Thanks,
Ash
http://www.ashleysheridan.co.uk





-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert UTF-8 to PHP defines

2010-05-27 Thread Guus Ellenkamp

I would like if you stick to the original issue: can a PHP source file be in 
utf-8. It's not about the output, that is properly supported.

Think it would be a good idea anyhow that PHP would support utf-8 source 
files as it seems utf-8 is going to be the de-facto standard for text files 
anyhow.

Ashley Sheridan a...@ashleysheridan.co.uk wrote in message 
news:1274988834.2202.285.ca...@localhost...
 On Thu, 2010-05-27 at 15:28 -0400, Bob McConnell wrote:

 From: tedd

  The Unicode database uses the same lower
  character values (i.e., code points) as does
  ASCII, namely 0-127, and thus UFT-8 (8-bit
  variable width encoding) is really a super-set
  which includes the sub-set of ASCII.
 
  The Wingdings font that Ash refers to is the
  really the Dingbat char set in Unicode, as
  shown here:
 
  The use of UFT-8 encoding in everything (web and
  php) should present much less problems globally
  than it is trying to fight it.

 Thanks tedd,

 The real question is whether unicode is even relevant now that the UTF
 series is available. I see no reason to have to deal with two competing
 specifications, when one of them is more than adequate for the job and
 the other is not even finished yet. That's like the old days when a few
 users demanded we support both ASCII and EBCDIC. That didn't get very
 far either.

 Bob McConnell



 Bob, UTF is unicode (Unicode Transformation Format)

 Interesting enough to note, and not sure if Tedd knows this or not (he
 probably does!) but Chrome has a nice feature for those punycode URLs;
 it suggests the actual real URL instead once you type the domain in. Not
 sure about Safari right now, couldn't be bothered to fire up a VM just
 to check. I would assume Firefox handles these URLs well enough too.

 Tedd, does that URL actually go anywhere, as I got nothing when I tried
 visiting it, both the actual URL and the punycode version.

 Thanks,
 Ash
 http://www.ashleysheridan.co.uk


 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Convert UTF-8 to PHP defines

2010-05-26 Thread Guus Ellenkamp

We use PHP defines for defining text in different languages. As far as I 
know PHP files are supposed to be ASCII, not UTF-8 or something like that. 
What I want to make is a conversion program that would convert a given UTF-8 
file with the format

definetext1=this is a text in random UTF-8, probably arabic or similar text
definetext2=this is another text in random UTF-8, probably arabic or similar 
text

into a file with the following defines

define('definetext1',chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
define('definetext2,chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));

Not sure if I'm using the correct chr/ord function, but I hope the above is 
clear enough to make clear what I'm looking for. Basically the output file 
should be ascii and not contain any utf-8.

Any advise? The html_special_chars did not seem to work for Vietnamese text 
I tried to convert, so something seems to get wrong with just reading an 
array of strings and converting the strings and putting them in defines. 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert UTF-8 to PHP defines

2010-05-26 Thread Ashley Sheridan

On Wed, 2010-05-26 at 22:20 +0800, Guus Ellenkamp wrote:

 We use PHP defines for defining text in different languages. As far as I 
 know PHP files are supposed to be ASCII, not UTF-8 or something like that. 
 What I want to make is a conversion program that would convert a given UTF-8 
 file with the format
 
 definetext1=this is a text in random UTF-8, probably arabic or similar text
 definetext2=this is another text in random UTF-8, probably arabic or similar 
 text
 
 into a file with the following defines
 
 define('definetext1',chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
 define('definetext2,chr(t_value).chr(h_value).chr(i_value)...chr(x_value).chr(t_value));
 
 Not sure if I'm using the correct chr/ord function, but I hope the above is 
 clear enough to make clear what I'm looking for. Basically the output file 
 should be ascii and not contain any utf-8.
 
 Any advise? The html_special_chars did not seem to work for Vietnamese text 
 I tried to convert, so something seems to get wrong with just reading an 
 array of strings and converting the strings and putting them in defines. 
 
 
 


PHP files can contain utf-8, and in-fact is the preference of most
developers I know of.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] convert a string into an array

2010-04-09 Thread Rene Veerman

it's about telepathy. mass-telepathy ;)

telepathic pressure.
death threats through telepathy, of which i've had quite a few in past weeks..

fear begets fear begets disease...

but thanks for the compliment ;)

On Mon, Apr 5, 2010 at 6:53 AM, Nathan Rixham nrix...@gmail.com wrote:
 you sure you're only smoking cigarettes?

 has to be one of the most random replies to any php thread I've ever
 seen - awesome!

 regards

 Rene Veerman wrote:
 yea i'm not the only one with those type of problems. sometimes times
 slows down in my room so much not even my speakers sound normal
 anymore; equipment that doesn't work (despite being crappy and known
 by it's patterns of refusal to work; still EXTRA abnormal since about
 a week or so)...

 it sounds like the who's reading my passwords with me while i type 'm
 in... === 'is there anyone looking over my shoulder despite no living
 humans even in my entire properly locked room (with strong walls)'

 the idea here is; take a break. work on a different project for a week
 or so, but the best idea is; move around through the country side and
 realize that your car will get gas at every gasstation... check your
 atm cards, but not your online banking account status, just to buy a
 pack of cigarettes with an atm card. and then, buy not 1 or 2 packs of
 your favorite smokes(cigarettes in this case), but buy 10 packs with
 that card, and make sure you have enough good old cash that you know
 to be truely valid (coins are best) to get just 2 large packs of
 cigarettes..

 things like that will give you the confidence you need to proceed on
 your project i think..

 the #1 rule i use (when you dont yet have any need for a #0 rule or a
 #-1 rule (dont add those lightly and never on a whim or hope of being
 saved from death in the next 5 minutes)) is: truely honest living
 humans should never use the same type of lie construct in the same
 type of situation for the second time within at least 1 to 3 weeks..
 but hey, necessity may require you to break any rule...

 rules? only guidelines are usefull ;) (pirates of the caribean #1 movie)


 On Sat, Apr 3, 2010 at 1:05 AM, Andre Polykanine an...@oire.org wrote:
 Hello everyone,

 It's quite simple but I'm still stuck.
 What I need is the following: I have an array as a parameter of my
 custom function. However, I'd like to allow users to enter a string
 instead of an array. In this case (if the parameter is a string), it
 must be replaced with an array containing only one item - actually,
 that string.
 What I'm doing gives me (presumably) errors;
 function Send ($tonames, $toemails, $subject, $message) {
 ...
 if ((!is_array($tonames)) || (!is_array($toemails))) {
 $tonames[]=$tonames;
 $toemails[]=$toemails;
 }

 I can't give the new array a new name since I address it further in a
 loop as my function's parameter... hope you understand what I'm
 saying)
 Thanks!

 --
 With best regards from Ukraine,
 Andre
 Http://oire.org/ - The Fantasy blogs of Oire
 Skype: Francophile; WlmMSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
 jabber.org
 Yahoo! messenger: andre.polykanine; ICQ: 191749952
 Twitter: http://twitter.com/m_elensule


 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php







-- 
-
Greetings from Rene7705,

I have made some free open source webcomponents designed
and written by me available through:
http://code.google.com/u/rene7705/ , or
http://mediabeez.ws (latest dev versions, currently offline)
-

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] convert a string into an array

2010-04-09 Thread Rene Veerman

On Mon, Apr 5, 2010 at 4:09 PM, Ashley Sheridan 
a...@ashleysheridan.co.ukwrote:

   On Mon, 2010-04-05 at 05:53 +0100, Nathan Rixham wrote:

 you sure you're only smoking cigarettes?

 has to be one of the most random replies to any php thread I've ever
 seen - awesome!

 regards

 Rene Veerman wrote:
  yea i'm not the only one with those type of problems. sometimes times
  slows down in my room so much not even my speakers sound normal
  anymore; equipment that doesn't work (despite being crappy and known
  by it's patterns of refusal to work; still EXTRA abnormal since about
  a week or so)...
 
  it sounds like the who's reading my passwords with me while i type 'm
  in... === 'is there anyone looking over my shoulder despite no living
  humans even in my entire properly locked room (with strong walls)'
 
  the idea here is; take a break. work on a different project for a week
  or so, but the best idea is; move around through the country side and
  realize that your car will get gas at every gasstation... check your
  atm cards, but not your online banking account status, just to buy a
  pack of cigarettes with an atm card. and then, buy not 1 or 2 packs of
  your favorite smokes(cigarettes in this case), but buy 10 packs with
  that card, and make sure you have enough good old cash that you know
  to be truely valid (coins are best) to get just 2 large packs of
  cigarettes..
 
  things like that will give you the confidence you need to proceed on
  your project i think..
 
  the #1 rule i use (when you dont yet have any need for a #0 rule or a
  #-1 rule (dont add those lightly and never on a whim or hope of being
  saved from death in the next 5 minutes)) is: truely honest living
  humans should never use the same type of lie construct in the same
  type of situation for the second time within at least 1 to 3 weeks..
  but hey, necessity may require you to break any rule...
 
  rules? only guidelines are usefull ;) (pirates of the caribean #1 movie)
 
 
  On Sat, Apr 3, 2010 at 1:05 AM, Andre Polykanine an...@oire.org wrote:
  Hello everyone,
 
  It's quite simple but I'm still stuck.
  What I need is the following: I have an array as a parameter of my
  custom function. However, I'd like to allow users to enter a string
  instead of an array. In this case (if the parameter is a string), it
  must be replaced with an array containing only one item - actually,
  that string.
  What I'm doing gives me (presumably) errors;
  function Send ($tonames, $toemails, $subject, $message) {
  ...
  if ((!is_array($tonames)) || (!is_array($toemails))) {
  $tonames[]=$tonames;
  $toemails[]=$toemails;
  }
 
  I can't give the new array a new name since I address it further in a
  loop as my function's parameter... hope you understand what I'm
  saying)
  Thanks!
 
  --
  With best regards from Ukraine,
  Andre
  Http://oire.org/ http://oire.org/ - The Fantasy blogs of Oire
  Skype: Francophile; WlmMSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
  jabber.org
  Yahoo! messenger: andre.polykanine; ICQ: 191749952
  Twitter: http://twitter.com/m_elensule
 
 
  --
  PHP General Mailing List (http://www.php.net/)
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 




 Virus maybe?

   Thanks,
 Ash
 http://www.ashleysheridan.co.uk



yup, i'm on the global anti-t-viral team.
and as such more often a target of deaththreats through telepathy than most
other humans in my (economic) position.

however, if you dont believe in telepathy; KEEP IT THAT WAY :)))

hearing voices is only the snow on the tip of the iceberg when it comes to
telepathy (between (living) humans and non-human intelligences..

and i'll really try to make this my last telepathy-related post to this
list, this year at least...

-- 
-
Greetings from Rene7705,

I have made some free open source webcomponents designed
and written by me available through:
http://code.google.com/u/rene7705/ , or
http://mediabeez.ws (latest dev versions, currently offline)
-

Re: [PHP] convert a string into an array

2010-04-05 Thread Ashley Sheridan

On Mon, 2010-04-05 at 05:53 +0100, Nathan Rixham wrote:

 you sure you're only smoking cigarettes?
 
 has to be one of the most random replies to any php thread I've ever
 seen - awesome!
 
 regards
 
 Rene Veerman wrote:
  yea i'm not the only one with those type of problems. sometimes times
  slows down in my room so much not even my speakers sound normal
  anymore; equipment that doesn't work (despite being crappy and known
  by it's patterns of refusal to work; still EXTRA abnormal since about
  a week or so)...
  
  it sounds like the who's reading my passwords with me while i type 'm
  in... === 'is there anyone looking over my shoulder despite no living
  humans even in my entire properly locked room (with strong walls)'
  
  the idea here is; take a break. work on a different project for a week
  or so, but the best idea is; move around through the country side and
  realize that your car will get gas at every gasstation... check your
  atm cards, but not your online banking account status, just to buy a
  pack of cigarettes with an atm card. and then, buy not 1 or 2 packs of
  your favorite smokes(cigarettes in this case), but buy 10 packs with
  that card, and make sure you have enough good old cash that you know
  to be truely valid (coins are best) to get just 2 large packs of
  cigarettes..
  
  things like that will give you the confidence you need to proceed on
  your project i think..
  
  the #1 rule i use (when you dont yet have any need for a #0 rule or a
  #-1 rule (dont add those lightly and never on a whim or hope of being
  saved from death in the next 5 minutes)) is: truely honest living
  humans should never use the same type of lie construct in the same
  type of situation for the second time within at least 1 to 3 weeks..
  but hey, necessity may require you to break any rule...
  
  rules? only guidelines are usefull ;) (pirates of the caribean #1 movie)
  
  
  On Sat, Apr 3, 2010 at 1:05 AM, Andre Polykanine an...@oire.org wrote:
  Hello everyone,
 
  It's quite simple but I'm still stuck.
  What I need is the following: I have an array as a parameter of my
  custom function. However, I'd like to allow users to enter a string
  instead of an array. In this case (if the parameter is a string), it
  must be replaced with an array containing only one item - actually,
  that string.
  What I'm doing gives me (presumably) errors;
  function Send ($tonames, $toemails, $subject, $message) {
  ...
  if ((!is_array($tonames)) || (!is_array($toemails))) {
  $tonames[]=$tonames;
  $toemails[]=$toemails;
  }
 
  I can't give the new array a new name since I address it further in a
  loop as my function's parameter... hope you understand what I'm
  saying)
  Thanks!
 
  --
  With best regards from Ukraine,
  Andre
  Http://oire.org/ - The Fantasy blogs of Oire
  Skype: Francophile; WlmMSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
  jabber.org
  Yahoo! messenger: andre.polykanine; ICQ: 191749952
  Twitter: http://twitter.com/m_elensule
 
 
  --
  PHP General Mailing List (http://www.php.net/)
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 


Virus maybe?

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] convert a string into an array

2010-04-04 Thread Rene Veerman

yea i'm not the only one with those type of problems. sometimes times
slows down in my room so much not even my speakers sound normal
anymore; equipment that doesn't work (despite being crappy and known
by it's patterns of refusal to work; still EXTRA abnormal since about
a week or so)...

it sounds like the who's reading my passwords with me while i type 'm
in... === 'is there anyone looking over my shoulder despite no living
humans even in my entire properly locked room (with strong walls)'

the idea here is; take a break. work on a different project for a week
or so, but the best idea is; move around through the country side and
realize that your car will get gas at every gasstation... check your
atm cards, but not your online banking account status, just to buy a
pack of cigarettes with an atm card. and then, buy not 1 or 2 packs of
your favorite smokes(cigarettes in this case), but buy 10 packs with
that card, and make sure you have enough good old cash that you know
to be truely valid (coins are best) to get just 2 large packs of
cigarettes..

things like that will give you the confidence you need to proceed on
your project i think..

the #1 rule i use (when you dont yet have any need for a #0 rule or a
#-1 rule (dont add those lightly and never on a whim or hope of being
saved from death in the next 5 minutes)) is: truely honest living
humans should never use the same type of lie construct in the same
type of situation for the second time within at least 1 to 3 weeks..
but hey, necessity may require you to break any rule...

rules? only guidelines are usefull ;) (pirates of the caribean #1 movie)


On Sat, Apr 3, 2010 at 1:05 AM, Andre Polykanine an...@oire.org wrote:
 Hello everyone,

 It's quite simple but I'm still stuck.
 What I need is the following: I have an array as a parameter of my
 custom function. However, I'd like to allow users to enter a string
 instead of an array. In this case (if the parameter is a string), it
 must be replaced with an array containing only one item - actually,
 that string.
 What I'm doing gives me (presumably) errors;
 function Send ($tonames, $toemails, $subject, $message) {
 ...
 if ((!is_array($tonames)) || (!is_array($toemails))) {
 $tonames[]=$tonames;
 $toemails[]=$toemails;
 }

 I can't give the new array a new name since I address it further in a
 loop as my function's parameter... hope you understand what I'm
 saying)
 Thanks!

 --
 With best regards from Ukraine,
 Andre
 Http://oire.org/ - The Fantasy blogs of Oire
 Skype: Francophile; WlmMSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
 jabber.org
 Yahoo! messenger: andre.polykanine; ICQ: 191749952
 Twitter: http://twitter.com/m_elensule


 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] convert a string into an array

2010-04-04 Thread Nathan Rixham

you sure you're only smoking cigarettes?

has to be one of the most random replies to any php thread I've ever
seen - awesome!

regards

Rene Veerman wrote:
 yea i'm not the only one with those type of problems. sometimes times
 slows down in my room so much not even my speakers sound normal
 anymore; equipment that doesn't work (despite being crappy and known
 by it's patterns of refusal to work; still EXTRA abnormal since about
 a week or so)...
 
 it sounds like the who's reading my passwords with me while i type 'm
 in... === 'is there anyone looking over my shoulder despite no living
 humans even in my entire properly locked room (with strong walls)'
 
 the idea here is; take a break. work on a different project for a week
 or so, but the best idea is; move around through the country side and
 realize that your car will get gas at every gasstation... check your
 atm cards, but not your online banking account status, just to buy a
 pack of cigarettes with an atm card. and then, buy not 1 or 2 packs of
 your favorite smokes(cigarettes in this case), but buy 10 packs with
 that card, and make sure you have enough good old cash that you know
 to be truely valid (coins are best) to get just 2 large packs of
 cigarettes..
 
 things like that will give you the confidence you need to proceed on
 your project i think..
 
 the #1 rule i use (when you dont yet have any need for a #0 rule or a
 #-1 rule (dont add those lightly and never on a whim or hope of being
 saved from death in the next 5 minutes)) is: truely honest living
 humans should never use the same type of lie construct in the same
 type of situation for the second time within at least 1 to 3 weeks..
 but hey, necessity may require you to break any rule...
 
 rules? only guidelines are usefull ;) (pirates of the caribean #1 movie)
 
 
 On Sat, Apr 3, 2010 at 1:05 AM, Andre Polykanine an...@oire.org wrote:
 Hello everyone,

 It's quite simple but I'm still stuck.
 What I need is the following: I have an array as a parameter of my
 custom function. However, I'd like to allow users to enter a string
 instead of an array. In this case (if the parameter is a string), it
 must be replaced with an array containing only one item - actually,
 that string.
 What I'm doing gives me (presumably) errors;
 function Send ($tonames, $toemails, $subject, $message) {
 ...
 if ((!is_array($tonames)) || (!is_array($toemails))) {
 $tonames[]=$tonames;
 $toemails[]=$toemails;
 }

 I can't give the new array a new name since I address it further in a
 loop as my function's parameter... hope you understand what I'm
 saying)
 Thanks!

 --
 With best regards from Ukraine,
 Andre
 Http://oire.org/ - The Fantasy blogs of Oire
 Skype: Francophile; WlmMSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
 jabber.org
 Yahoo! messenger: andre.polykanine; ICQ: 191749952
 Twitter: http://twitter.com/m_elensule


 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] convert a string into an array

2010-04-02 Thread Andre Polykanine

Hello everyone,

It's quite simple but I'm still stuck.
What I need is the following: I have an array as a parameter of my
custom function. However, I'd like to allow users to enter a string
instead of an array. In this case (if the parameter is a string), it
must be replaced with an array containing only one item - actually,
that string.
What I'm doing gives me (presumably) errors;
function Send ($tonames, $toemails, $subject, $message) {
...
if ((!is_array($tonames)) || (!is_array($toemails))) {
$tonames[]=$tonames;
$toemails[]=$toemails;
}

I can't give the new array a new name since I address it further in a
loop as my function's parameter... hope you understand what I'm
saying)
Thanks!

-- 
With best regards from Ukraine,
Andre
Http://oire.org/ - The Fantasy blogs of Oire
Skype: Francophile; WlmMSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
jabber.org
Yahoo! messenger: andre.polykanine; ICQ: 191749952
Twitter: http://twitter.com/m_elensule


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] convert a string into an array

2010-04-02 Thread Jim Lucas

Andre Polykanine wrote:
 Hello everyone,
 
 It's quite simple but I'm still stuck.
 What I need is the following: I have an array as a parameter of my
 custom function. However, I'd like to allow users to enter a string
 instead of an array. In this case (if the parameter is a string), it
 must be replaced with an array containing only one item - actually,
 that string.
 What I'm doing gives me (presumably) errors;
 function Send ($tonames, $toemails, $subject, $message) {
 ...
 if ((!is_array($tonames)) || (!is_array($toemails))) {
 $tonames[]=$tonames;
 $toemails[]=$toemails;
 }
 
 I can't give the new array a new name since I address it further in a
 loop as my function's parameter... hope you understand what I'm
 saying)
 Thanks!
 

Do something like this:

$tonames  = (is_array($tonames)  ? $tonames  : array($tonames) );
$toemails = (is_array($toemails) ? $toemails : array($toemails));

-- 
Jim Lucas
NOC Manager
541-323-9113
BendTel, Inc.
http://www.bendtel.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers forequivalent PCRE functions


Paul M Foster pa...@quillandmouse.com wrote in message 
news:20091109030235.gh3...@quillandmouse.com...
 On Sun, Nov 08, 2009 at 06:30:37PM -0500, Robert Cummings wrote:

 Also, why support
 two libraries for which one is obviously inferior in speed and
 functionality?


 Because Tony's Radicore framework has a bunch of ereg* calls in it. ;-}

Just like a lot of other people's work.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

 Paul

 -- 
 Paul M. Foster 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions


Robert Cummings rob...@interjinn.com wrote in message 
news:4af76e1f.2050...@interjinn.com...
 Tony Marston wrote:
 Robert Cummings rob...@interjinn.com wrote in message
 Then you've got several options:
 1) Don't upgrade PHP.
 Not an acceptable option.

 2) Pick a different hosting provider.
 Not an acceptable optional.

 3) Fix your scripts.
 The scripts aren't broken. It's PHP 6 that's going to be broken.
 I think you're missing the point of a full version increase. This is not 
 a minor or micro version change... script breakage is *expected*.

 But breakage should be kept to an absolute minimum, and developer 
 laziness or incompetence is not an acceptable excuse.

 Not quite true... major version moves are an opportunity to make a break 
 for freedom. All there needs to be is an upgrade path... and that is 
 clearly in play right now with the warning indicating that POSIX regex 
 functions are being deprecated.

But a lot of people won't see those warnings until they run 5.3.0 for the 
first time. It is common practice, at least in all the other languages that 
I have used, that is something is going to be removed that it is marked as 
deprecated at the start of the previous release, not at the end. So marking 
the POIX functions as deprecated should have happened in 5.0, not 5.3.

 You don't think PHP should support legacy cruft in the core forever do 
 you?

 Widely use regex functions are not legacy cruft. Besides, who decides 
 what is cruft and should be removed from the language?

 They most certainly are cruft.

That is just your opinion. Other people think that PHP should be rewritten 
so that it appears more like their favourite language. Among the suggestions 
I have seen are:
- make all variables statically typed instead of dynamically typed.
- remove all procedural functions and make the language pure OO.

Who decides if they are right?

.. hence the reason they are being removed. The people who decide what is, 
and is not, cruft are the very same people who are writing the code. If you 
are not happy with this then there's the age old saying in open source... 
put up or shut up.

I can't because I don't program in C. So I shall do the nextbest thing - 
complain at every opporunity.

 If unicode support is slopped onto the current POSIX regex functions 
 won't that then make them non-POSIX? Food for thought. Also, why support 
 two libraries for which one is obviously inferior in speed and 
 functionality?

 That is why I suggested that instead of dropping the POSIX functions 
 entirely and seriously annoying lots of users, that they should simply be 
 rewritten as wrappers for the PCRE functions. In that way all the calls 
 to ereg_* would still work, but all they would do is immediately call the 
 relevant preg_* function. The small amount of effort that tghis would 
 take would kill two birds with one stone:

 (1) There would be only one regex engine to support, which would be PCRE.
 (2) Lots of developers would be spared the hassle of modifying their code 
 as all the calls to POSIX functions would still work as expected because 
 the language would redirect to the PCRE function automatically.

 This would probably be worse than removing the POSIX functions.
 POSIX and PCRE I daresay are not completely compatible.

probably and daresay mean that you are just guessing. According to some 
people who know what they are talking about there is a one-for-one 
comparison between each POSIX and each PCRE function.

 At least when you remove the POSIX functions then the problem space is 
 well defined.

And lots of sers will be pissed off because they won'tbe able to upgrade to 
PHP 6 without major programmer intervention.

 Suddenly having POSIX regex functions that are really wrappers around PCRE 
 functions may introduce subtle differences in output for the same horde of 
 users but without the same explicability.

may introduce? There you go, guessng again. Can you point out *any* POSIX 
function that cannot be converted into PCRE?

 I am not suggesting that the POSIX functions be rewritten to deal with 
 unicode as that would require a huge amount of effort, but by redirecting 
 al POSIX calls to the equivalent PCRE function would have the same effect 
 for far less effort.

 The choice is simple - either a small amount of effort from a small 
 number of developers, or a large amount of effort from a large number of 
 seriously pissed-off users. Do the maths. It's not rocket science.

 This isn't a mathematical problem. It's a question of correctness.

Lot's of PHP users, myself included, do not think that it is correct to 
remove widely used functionality just beause the developers are too lazy to 
do a proper job.

 I wasn't happy to hear POSIX regex functions were going either, but when I 
 heard the reasoning I did the best thing I could... I fixed my code to 
 prepare for the inevitable.

So you had to fix what wasn't broken just to circumvent a stupid decision by 
the PHP

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09 Thread Ashley Sheridan

On Mon, 2009-11-09 at 00:23 +, Tony Marston wrote:

 developer laziness 
 or incompetence is not an acceptable excuse.


Exactly, so fix your scripts!

I do wonder though, what hosting company you use that would just upgrade
to PHP6 without warning on you and 'break' your scripts, yet at the same
time would not allow you to install what you call an 'amateur fudge'. I
can't think of any hosting company that would care so little about their
customers.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions


Ashley Sheridan a...@ashleysheridan.co.uk wrote in message 
news:1257764339.1076.56.ca...@localhost...
 On Mon, 2009-11-09 at 00:23 +, Tony Marston wrote:

 developer laziness
 or incompetence is not an acceptable excuse.


 Exactly, so fix your scripts!

But my scripts aren't broken! It's PHP 6 that is broken.

 I do wonder though, what hosting company you use that would just upgrade
 to PHP6 without warning on you and 'break' your scripts,

How many hosting companies write to all their account holders to ask 
permission before upgrading PHP, not just from 4 to 5, but all the releases 
in between? Very few of them, if any, in my experience.

 yet at the same
 time would not allow you to install what you call an 'amateur fudge'. I
 can't think of any hosting company that would care so little about their
 customers.

Some hosting companies won't allow you to use htaccess files, refuse to 
install any optional extension, let alone one from the PECL or PEAR 
repositories. Some of them won't give you more than one MySQL database. 
Different companies provide different levels of service. The only thing that 
the DO have in common is that they charge you for it.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

 Thanks,
 Ash
 http://www.ashleysheridan.co.uk


 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09 Thread David Otton

2009/11/9 Tony Marston t...@marston-home.demon.co.uk:

 So you wouldn't trust the PHP developers to write simple code which takes
 each POSIX function and redirects it to a PCRE function? I have more faith
 in their ability than I do yours.

If it's as simple as you claim, why don't you mock-up your solution in
PHP, rather than C? You'll get taken more seriously if you have
working code that someone can write unit tests against.

If your solution doesn't get any traction with the core team, you'll
still be able to offer it to the community as a simple download, just
include this at the top of your script to fix ereg*() not found
problems. That would be really useful to all those people whose cause
you are championing.

(BTW, the reference implementation for PHP is... PHP. There isn't an
ISO standard or anything here. How PHP6 behaves is correct, because
it's PHP6).

(BTW^2 - you're on the wrong list for this. If you want to influence
the guys who make the decisions you need to take this to
php-internals, where the heavyweights hang out).

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09 Thread Tim Thorburn


Tony Marston wrote:
How many hosting companies write to all their account holders to ask 
permission before upgrading PHP, not just from 4 to 5, but all the releases 
in between? Very few of them, if any, in my experience.
  
I've no idea what horrible hosting companies you've had experiences 
with, however all of the companies I've used in the last few years have 
had an option to move back and forth between PHP4 and PHP5 in the event 
that certain scrips/frameworks/apps/whatever required one version over 
the other.  What makes you think these companies won't do the same thing 
when they finally decide to add PHP6 to their servers?  I doubt very 
many reputable hosting companies would simply upgrade to the latest 
flavor of PHP/Apache/MySQL/anything simply because it was released this 
morning without doing ample internal testing; if you or your clients are 
using one that does this - I'd advise you look elsewhere.


Whenever PHP6 reaches a stable release build, it will still be quite 
some time before its offered as an option to any mainstream shared 
hosting service - this should leave you ample time to adapt to incoming 
changes.  Failing that, you always have the option of purchasing your 
own server or VPS from any number of hosts to configure as you see fit.  
Or you can explain your moral outrage to potential clients detailing 
your refusal to work because you disagree with a proposed change that 
won't see the light of day for years to come; your call.


Incessant whining under the guise of expressing your own opinion isn't 
going to make everything better.  Sorry.

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions


David Otton phpm...@jawbone.freeserve.co.uk wrote in message 
news:193d27170911090331k7ecbe69cl1dd30651273e7...@mail.gmail.com...
 2009/11/9 Tony Marston t...@marston-home.demon.co.uk:

 So you wouldn't trust the PHP developers to write simple code which takes
 each POSIX function and redirects it to a PCRE function? I have more 
 faith
 in their ability than I do yours.

 If it's as simple as you claim, why don't you mock-up your solution in
 PHP, rather than C?

Because I can't do that until I install PHP 6, but as I never play with beta 
software waiting for it to go live will be too late.

 You'll get taken more seriously if you have
 working code that someone can write unit tests against.

 If your solution doesn't get any traction with the core team, you'll
 still be able to offer it to the community as a simple download, just
 include this at the top of your script to fix ereg*() not found
 problems. That would be really useful to all those people whose cause
 you are championing.

 (BTW, the reference implementation for PHP is... PHP. There isn't an
 ISO standard or anything here. How PHP6 behaves is correct, because
 it's PHP6).

 (BTW^2 - you're on the wrong list for this. If you want to influence
 the guys who make the decisions you need to take this to
 php-internals, where the heavyweights hang out).

I have tried subscribing to the internals list, but none of my postings ever 
appears. I've tried looking at the PHP wiki, but I cannot see any method of 
creating an RFC.

I have, however, created a request in php_compat in the PEAR system at 
http://pear.php.net/bugs/bug.php?id=16769

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09 Thread Paul Fierro

On 11/9/09 8:56 AM, Tony Marston t...@marston-home.demon.co.uk wrote:

 I have tried subscribing to the internals list, but none of my postings ever
 appears.

That's unfortunate as you missed this thread:

http://marc.info/?t=12553625831r=1w=2

Paul



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09 Thread David Otton

2009/11/9 Tony Marston t...@marston-home.demon.co.uk:

 Because I can't do that until I install PHP 6, but as I never play with beta
 software waiting for it to go live will be too late.

Not sure why not. If it's just the name collision, call them
alt_ereg*() until ereg*() goes away. In fact, it's much easier to
write unit tests against your new functions if the old functions are
still hanging around.

 I've tried looking at the PHP wiki, but I cannot see any method of
 creating an RFC.

Well, the RFCs are here, but you probably already found them:
http://wiki.php.net/rfc (register is in the bottom-right corner).

Can't help you with your php-internals problem, I'm afraid. Tried
emailing the list manager?

 I have, however, created a request in php_compat in the PEAR system at
 http://pear.php.net/bugs/bug.php?id=16769

Fair enough. Good luck.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09 Thread Ashley Sheridan

On Mon, 2009-11-09 at 15:49 +, David Otton wrote:

 2009/11/9 Tony Marston t...@marston-home.demon.co.uk:
 
  Because I can't do that until I install PHP 6, but as I never play with beta
  software waiting for it to go live will be too late.
 
 Not sure why not. If it's just the name collision, call them
 alt_ereg*() until ereg*() goes away. In fact, it's much easier to
 write unit tests against your new functions if the old functions are
 still hanging around.
 
  I've tried looking at the PHP wiki, but I cannot see any method of
  creating an RFC.
 
 Well, the RFCs are here, but you probably already found them:
 http://wiki.php.net/rfc (register is in the bottom-right corner).
 
 Can't help you with your php-internals problem, I'm afraid. Tried
 emailing the list manager?
 
  I have, however, created a request in php_compat in the PEAR system at
  http://pear.php.net/bugs/bug.php?id=16769
 
 Fair enough. Good luck.
 


And what about something like this as an internal wrapper:

if(!function_exists('ereg_*'))
{
function ereg_*()
{

}
}

And you should at least try to test the code you write for your clients
on PHP6 if that is where it is going to be hosted before servers are
upgraded, even if it's just to find out if it will break and give you
time to fix it. Hell, you could probably charge for that if the client
absolutely has to be on a PHP6 server, as something like that would fall
outside the scope of future maintenance, unless of course you wrote your
code in full knowledge of the change that would happen in PHP6.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09 Thread Robert Cummings


Tony Marston wrote:
Ashley Sheridan a...@ashleysheridan.co.uk wrote in message 
news:1257764339.1076.56.ca...@localhost...

On Mon, 2009-11-09 at 00:23 +, Tony Marston wrote:


developer laziness
or incompetence is not an acceptable excuse.


Exactly, so fix your scripts!


But my scripts aren't broken! It's PHP 6 that is broken.


Actually when PHP 6 comes out... it will be your scripts that are 
broken. The language doesn't adapt to you for every version change. YOU 
adapt to the language, otherwise YOUR scripts ARE broken.


Some hosting companies won't allow you to use htaccess files, refuse to 
install any optional extension, let alone one from the PECL or PEAR 
repositories. Some of them won't give you more than one MySQL database. 
Different companies provide different levels of service. The only thing that 
the DO have in common is that they charge you for it.


Then switch hosting company. Or pony up the extra $5 or $10 per month or 
so for a VPS that gives you root access and all the configurability you 
could want. Lack of choice is NOT the fault of PHP.


Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

The POSIX regex functions are currently marked as DEPRECATED in 5.3.0 and 
are due to be removed completely in PHP 6. I propose that instead of being 
dropped they be converted into wrappers for the equivalent PCRE functions.



It does not matter how long various people have been preaching in various 
unofficial channels that users should switch to using the PCRE functions 
(preg_*) instead of the POSIX ones (ereg_*) as many users simply do not 
access those channels. The first time that a significant number of users 
will become aware of this is when they switch to 5.3.0 or later, and they 
will be very, very upset. Some users do not test their applications against 
each new PHP version as it comes out, they just use whatever version their 
hosting company provides them with.



It does not matter that the PHP developers cannot find someone to upgrade 
the POSIX functions, it does not matter that the same functionality can be 
provided with the PCRE functions, all the users will know is that their 
scripts, some of which have been running for many years, will suddenly not 
work and will need serious programming effort before they can run again.



You know how long it took for sites to upgrade from PHP 4 to 5 because of 
the backward compatibility issues, so imagine even more resistance and a 
slower uptake for PHP 6. The POSIX functions have been a core part of the 
language since the early days of PHP, so to suddenly dump them for no good 
reason will alienate and upset a large number of people. When I say no good 
reason I mean from the user's point of view. The fact that it is taking 
(has taken?) considerable effort to get the PCRE functions working with 
Unicode for PHP 6, and no-one is prepared to spend similar effort on the 
POSIX functions, may make it seem in the users eyes that the PHP developers 
are either lazy or incompetent.



It does not matter that the PHP developers are unpaid volunteers - that is 
no reason for shoddy workmanship. If they can't do the job properly they 
shouldn't do it at all. BC breaks, especially on a range of functions which 
have been a core part of the language for many, many years, do not go down 
well with the users, and remember that it is the incredibly large number of 
people who use PHP, not the efforts of the developers, that has made it such 
a popular language. So annoying large numbers of users will create a PR 
disaster.



If the PCRE functions have been made to work with Unicode, and each of the 
POSIX functions has a PCRE equivalent, then surely an intelligent move would 
be to convert all the POSIX functions into simple wrappers for their PCRE 
equivalents. So instead of spending huge amounts of effort in making the 
POSIX functions work with Unicode you simply cut out the code behind each 
POSIX function and replace it to a call to the relevant PCRE function.



This should only require a relatively small amount of developer effort which 
should be balanced against the huge amount that would otherwise be required 
in userland. If the PHP developers are not prepared to undertake this small 
amount of effort then they should be prepared for considerable amounts of 
fallout from lots of unhappy users.



I would strongly suggest that a start be made on this as soon as possible so 
that the changeover to PCRE wrappers can be fully tested and debugged before 
PHP 6 goes live. This will make the changeover from POSIX to PCRE totally 
transparent, and will be greatly appreciated in userland.


-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08 Thread John Black

The same can be said about the removal of magic_quotes(), it will break 
A LOT of old scripts.
I am in the same boat, I did not keep up to date with the PHP developer 
plans and just found out about ereg when I installed PHP 5.3.


I think it was handled properly by displaying warning messages before 
actually removing it. It will give people enough time to update their 
scripts or weed out the old and insecure scripts.


Yes, it will create some headache but, AFAIK, it is for the better.

--
John
Intelligent Life
http://xkcd.com/638/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

It is for the better? How can you justify that? It is a problem that will 
cause a lot of headaches for a lot of users, yet the solution which I have 
proposed will remove that problem with only very little effort, yet still 
leave only one regex engine which has to be supported in PHP 6.

You have to balance out the small bit of effort required in implementing 
this solution against the huge amount of effort required in changing 
thousands, if not millions of scripts.

For the PHP developers to say we can't be bothered to update the POSIX 
functions to deal with unicode, so we've decided to drop them from PHP 
entirely even though it will break lots of scripts will not go down well in 
userland.


-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

John Black s...@network-technologies.org wrote in message 
news:4af70120.1040...@network-technologies.org...
 The same can be said about the removal of magic_quotes(), it will break A 
 LOT of old scripts.
 I am in the same boat, I did not keep up to date with the PHP developer 
 plans and just found out about ereg when I installed PHP 5.3.

 I think it was handled properly by displaying warning messages before 
 actually removing it. It will give people enough time to update their 
 scripts or weed out the old and insecure scripts.

 Yes, it will create some headache but, AFAIK, it is for the better.

 -- 
 John
 Intelligent Life
 http://xkcd.com/638/ 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08 Thread Eddie Drapkin

On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
t...@marston-home.demon.co.uk wrote:
 It is for the better? How can you justify that? It is a problem that will
 cause a lot of headaches for a lot of users, yet the solution which I have
 proposed will remove that problem with only very little effort, yet still
 leave only one regex engine which has to be supported in PHP 6.

 You have to balance out the small bit of effort required in implementing
 this solution against the huge amount of effort required in changing
 thousands, if not millions of scripts.

 For the PHP developers to say we can't be bothered to update the POSIX
 functions to deal with unicode, so we've decided to drop them from PHP
 entirely even though it will break lots of scripts will not go down well in
 userland.


 --
 Tony Marston
 http://www.tonymarston.net
 http://www.radicore.org

 John Black s...@network-technologies.org wrote in message
 news:4af70120.1040...@network-technologies.org...
 The same can be said about the removal of magic_quotes(), it will break A
 LOT of old scripts.
 I am in the same boat, I did not keep up to date with the PHP developer
 plans and just found out about ereg when I installed PHP 5.3.

 I think it was handled properly by displaying warning messages before
 actually removing it. It will give people enough time to update their
 scripts or weed out the old and insecure scripts.

 Yes, it will create some headache but, AFAIK, it is for the better.

 --
 John
 Intelligent Life
 http://xkcd.com/638/



 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



The plan, as far as I am aware, is to move POSIX regular expressions
into PECL as of PHP6.  If you can fix your scripts by simply running
pecl install ereg what's all the hee-hawing about?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

That's an amateur fudge, not a professional fix. Besides, what happens if 
your hosting company won't let you install PECL extensions?

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

Eddie Drapkin oorza...@gmail.com wrote in message 
news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...
 On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
 t...@marston-home.demon.co.uk wrote:
 It is for the better? How can you justify that? It is a problem that 
 will
 cause a lot of headaches for a lot of users, yet the solution which I 
 have
 proposed will remove that problem with only very little effort, yet still
 leave only one regex engine which has to be supported in PHP 6.

 You have to balance out the small bit of effort required in implementing
 this solution against the huge amount of effort required in changing
 thousands, if not millions of scripts.

 For the PHP developers to say we can't be bothered to update the POSIX
 functions to deal with unicode, so we've decided to drop them from PHP
 entirely even though it will break lots of scripts will not go down well 
 in
 userland.


 --
 Tony Marston
 http://www.tonymarston.net
 http://www.radicore.org

 John Black s...@network-technologies.org wrote in message
 news:4af70120.1040...@network-technologies.org...
 The same can be said about the removal of magic_quotes(), it will break 
 A
 LOT of old scripts.
 I am in the same boat, I did not keep up to date with the PHP developer
 plans and just found out about ereg when I installed PHP 5.3.

 I think it was handled properly by displaying warning messages before
 actually removing it. It will give people enough time to update their
 scripts or weed out the old and insecure scripts.

 Yes, it will create some headache but, AFAIK, it is for the better.

 --
 John
 Intelligent Life
 http://xkcd.com/638/



 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



 The plan, as far as I am aware, is to move POSIX regular expressions
 into PECL as of PHP6.  If you can fix your scripts by simply running
 pecl install ereg what's all the hee-hawing about? 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08 Thread Eddie Drapkin

On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
t...@marston-home.demon.co.uk wrote:
 That's an amateur fudge, not a professional fix. Besides, what happens if
 your hosting company won't let you install PECL extensions?

 --
 Tony Marston
 http://www.tonymarston.net
 http://www.radicore.org

 Eddie Drapkin oorza...@gmail.com wrote in message
 news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...
 On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
 t...@marston-home.demon.co.uk wrote:
 It is for the better? How can you justify that? It is a problem that
 will
 cause a lot of headaches for a lot of users, yet the solution which I
 have
 proposed will remove that problem with only very little effort, yet still
 leave only one regex engine which has to be supported in PHP 6.

 You have to balance out the small bit of effort required in implementing
 this solution against the huge amount of effort required in changing
 thousands, if not millions of scripts.

 For the PHP developers to say we can't be bothered to update the POSIX
 functions to deal with unicode, so we've decided to drop them from PHP
 entirely even though it will break lots of scripts will not go down well
 in
 userland.


 --
 Tony Marston
 http://www.tonymarston.net
 http://www.radicore.org

 John Black s...@network-technologies.org wrote in message
 news:4af70120.1040...@network-technologies.org...
 The same can be said about the removal of magic_quotes(), it will break
 A
 LOT of old scripts.
 I am in the same boat, I did not keep up to date with the PHP developer
 plans and just found out about ereg when I installed PHP 5.3.

 I think it was handled properly by displaying warning messages before
 actually removing it. It will give people enough time to update their
 scripts or weed out the old and insecure scripts.

 Yes, it will create some headache but, AFAIK, it is for the better.

 --
 John
 Intelligent Life
 http://xkcd.com/638/



 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



 The plan, as far as I am aware, is to move POSIX regular expressions
 into PECL as of PHP6.  If you can fix your scripts by simply running
 pecl install ereg what's all the hee-hawing about?



 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



Then you've got several options:
1) Don't upgrade PHP.
2) Pick a different hosting provider.
3) Fix your scripts.

You talk about a professional fix.  The right fix is to remove the
depracated elements from your scripts before upgrading PHP, which
realistically shouldn't be that big of a deal for the vast majority of
expressions.  Rather than accept the change and just fix your scripts,
you propose a problem that breaks a lot of other things and introduces
way more problems than it solves.

You're not the first person to post this exact same tantrum on this
list and the response has always been: fix your scripts or don't
upgrade.  Seeing as PHP 6 is a long ways away you've got plenty of
time to fix your scripts and it's not like this is being sprung
overnight, so do the real professional thing and upgrade your scripts,
if you want to upgrade (when 6 is released).  Breaking BC happens.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions


Eddie Drapkin oorza...@gmail.com wrote in message 
news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com...
On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
t...@marston-home.demon.co.uk wrote:
 That's an amateur fudge, not a professional fix. Besides, what happens if
 your hosting company won't let you install PECL extensions?

 --
 Tony Marston
 http://www.tonymarston.net
 http://www.radicore.org

 Eddie Drapkin oorza...@gmail.com wrote in message
 news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...
 On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
 t...@marston-home.demon.co.uk wrote:
 It is for the better? How can you justify that? It is a problem that
 will
 cause a lot of headaches for a lot of users, yet the solution which I
 have
 proposed will remove that problem with only very little effort, yet 
 still
 leave only one regex engine which has to be supported in PHP 6.

 You have to balance out the small bit of effort required in implementing
 this solution against the huge amount of effort required in changing
 thousands, if not millions of scripts.

 For the PHP developers to say we can't be bothered to update the POSIX
 functions to deal with unicode, so we've decided to drop them from PHP
 entirely even though it will break lots of scripts will not go down 
 well
 in
 userland.


 --
 Tony Marston
 http://www.tonymarston.net
 http://www.radicore.org

 John Black s...@network-technologies.org wrote in message
 news:4af70120.1040...@network-technologies.org...
 The same can be said about the removal of magic_quotes(), it will break
 A
 LOT of old scripts.
 I am in the same boat, I did not keep up to date with the PHP developer
 plans and just found out about ereg when I installed PHP 5.3.

 I think it was handled properly by displaying warning messages before
 actually removing it. It will give people enough time to update their
 scripts or weed out the old and insecure scripts.

 Yes, it will create some headache but, AFAIK, it is for the better.

 --
 John
 Intelligent Life
 http://xkcd.com/638/



 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



 The plan, as far as I am aware, is to move POSIX regular expressions
 into PECL as of PHP6. If you can fix your scripts by simply running
 pecl install ereg what's all the hee-hawing about?



 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



 Then you've got several options:
 1) Don't upgrade PHP.

Not an acceptable option.

 2) Pick a different hosting provider.

Not an acceptable optional.

 3) Fix your scripts.

The scripts aren't broken. It's PHP 6 that's going to be broken.

 You talk about a professional fix.  The right fix is to remove the
 depracated elements

My whole argument is that they shouldn't have been deprecated in the first 
place.

 from your scripts before upgrading PHP, which
 realistically shouldn't be that big of a deal for the vast majority of
 expressions.

It is going to be a VERY big deal for all hose users who suddenly finf that 
their scripts won't run in PHP 6.

 Rather than accept the change and just fix your scripts,

It's not a change, it's a removal of core functions that have worked 
flawlessly for years. Both the POSIX and the PCRE functions needed to be 
updated to work with unicode, but the developers couldn't be bothered to 
update both. The only reason that the POSIX have been deprecated is because 
the PHP developers are either too lazy or too incompetent to provide a 
proper fix.

 you propose a problem that breaks a lot of other things and introduces
 way more problems than it solves.

 You're not the first person to post this exact same tantrum on this
l list and the response has always been: fix your scripts

The scripts aren't broken, it's PHP 6 that's broken.

 or don't upgrade.

Not an acceptable option.

 Seeing as PHP 6 is a long ways away you've got plenty of
 time to fix your scripts

Just as the PHP developers have plenty of time to do a proper job.

 and it's not like this is being sprung overnight,

To a lot of peope it will appear to be sprung overnight as the first time 
they will know that the POSIX functions have been removed is when their 
scripts don't work.

 so do the real professional thing

The professional thing would be to fix PHP 6 so that is doesn't  break 
existing scripts needlessly.

 and upgrade your scripts,
 if you want to upgrade (when 6 is released).  Breaking BC happens.

There is a difference between breaking BC because of genuinely 
insurmountable reasons, and breaking it because of pure laziness.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08 Thread Robert Cummings


Tony Marston wrote:
Eddie Drapkin oorza...@gmail.com wrote in message 
news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com...

On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
t...@marston-home.demon.co.uk wrote:

That's an amateur fudge, not a professional fix. Besides, what happens if
your hosting company won't let you install PECL extensions?

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

Eddie Drapkin oorza...@gmail.com wrote in message
news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...

On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
t...@marston-home.demon.co.uk wrote:

It is for the better? How can you justify that? It is a problem that
will
cause a lot of headaches for a lot of users, yet the solution which I
have
proposed will remove that problem with only very little effort, yet 
still

leave only one regex engine which has to be supported in PHP 6.

You have to balance out the small bit of effort required in implementing
this solution against the huge amount of effort required in changing
thousands, if not millions of scripts.

For the PHP developers to say we can't be bothered to update the POSIX
functions to deal with unicode, so we've decided to drop them from PHP
entirely even though it will break lots of scripts will not go down 
well

in
userland.


--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

John Black s...@network-technologies.org wrote in message
news:4af70120.1040...@network-technologies.org...

The same can be said about the removal of magic_quotes(), it will break
A
LOT of old scripts.
I am in the same boat, I did not keep up to date with the PHP developer
plans and just found out about ereg when I installed PHP 5.3.

I think it was handled properly by displaying warning messages before
actually removing it. It will give people enough time to update their
scripts or weed out the old and insecure scripts.

Yes, it will create some headache but, AFAIK, it is for the better.

--
John
Intelligent Life
http://xkcd.com/638/



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



The plan, as far as I am aware, is to move POSIX regular expressions
into PECL as of PHP6. If you can fix your scripts by simply running
pecl install ereg what's all the hee-hawing about?



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php





Then you've got several options:
1) Don't upgrade PHP.


Not an acceptable option.


2) Pick a different hosting provider.


Not an acceptable optional.


3) Fix your scripts.


The scripts aren't broken. It's PHP 6 that's going to be broken.


I think you're missing the point of a full version increase. This is not 
a minor or micro version change... script breakage is *expected*. You 
don't think PHP should support legacy cruft in the core forever do you? 
If unicode support is slopped onto the current POSIX regex functions 
won't that then make them non-POSIX? Food for thought. Also, why support 
two libraries for which one is obviously inferior in speed and 
functionality?


Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions