Re: [PHP-DEV] PHP 6

[Chen Ze]

On Sat, Mar 13, 2010 at 2:34 AM, Derick Rethans der...@php.net wrote:
 On Fri, 12 Mar 2010, Hannes Magnusson wrote:

 On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi m...@mozo.jp wrote:
  I'd love to see my brand-new mbstring implementation in the release.
  Dropping mbstring completely won't be any good because lots of
  applications rely on it, but I don't really want to maintain the funky
  library bundled with it.

 Thats actually one of the ideas we had on IRC.
 That mbstring patch and more ext/intl features should be enough to
 solve the unicode problem.

 Sorry, but that is not true. intl and mbstring can provide functionality
 to deal with UTF 8 string manipulation functions, they can not provide
 proper Unicode support. Proper Unicode support is *not* only just
 dealing with UTF-8 strings. Proper Unicode support includes dealing with
 file streams, with different encodings, with localiztion, with sorting,
 with locales, with formatting numbers. Offloading this to extensions
 makes Unicode support an add-on hack, and not a language feature. I am
 not saying that intl and mbstring aren't *useful*, but they definitely
 do not solve the unicode problem.


I think unicode should only care for string handling. Formatting
numbers should not be the thing that unicode cares. Unicode is a
standard for text, not for text or number formatting.

Back to the days we don't have unicode, the number formatting have
already existed. It even exists when computer was not invented.

That is same for sorting.

When we think about Unicode, we should think about those really
related to Unicode,like file system. Number formatting and sorting are
other things which intl cares.

For the unicode, I think we should implement something like:

$chars=new mchar($bytes,$bytes_encoding);
echo $chars;//output encoding
foreach ($chars as $char) {
  echo $char;//output single utf-16/utf-8 char (depends on default
output encoding)
}
echo $chars-bytes('gbk');

$chars-outputEncoding('gbk');
echo $chars;

ini_set('mchar_output_encoding','gbk');
echo $chars;

ini_set('mchar_filesystem_encoding','gbk');
echo $chars-filepath();

 regards,
 Derick

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
aka Surf Chen
http://chenze.name/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Lester Caine]

Chen Ze wrote:

On Sat, Mar 13, 2010 at 2:34 AM, Derick Rethansder...@php.net  wrote:

On Fri, 12 Mar 2010, Hannes Magnusson wrote:


On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumim...@mozo.jp  wrote:

I'd love to see my brand-new mbstring implementation in the release.
Dropping mbstring completely won't be any good because lots of
applications rely on it, but I don't really want to maintain the funky
library bundled with it.


Thats actually one of the ideas we had on IRC.
That mbstring patch and more ext/intl features should be enough to
solve the unicode problem.


Sorry, but that is not true. intl and mbstring can provide functionality
to deal with UTF 8 string manipulation functions, they can not provide
proper Unicode support. Proper Unicode support is *not* only just
dealing with UTF-8 strings. Proper Unicode support includes dealing with
file streams, with different encodings, with localiztion, with sorting,
with locales, with formatting numbers. Offloading this to extensions
makes Unicode support an add-on hack, and not a language feature. I am
not saying that intl and mbstring aren't *useful*, but they definitely
do not solve the unicode problem.



I think unicode should only care for string handling. Formatting
numbers should not be the thing that unicode cares. Unicode is a
standard for text, not for text or number formatting.

Back to the days we don't have unicode, the number formatting have
already existed. It even exists when computer was not invented.

That is same for sorting.

When we think about Unicode, we should think about those really
related to Unicode,like file system. Number formatting and sorting are
other things which intl cares.

For the unicode, I think we should implement something like:

$chars=new mchar($bytes,$bytes_encoding);
echo $chars;//output encoding
foreach ($chars as $char) {
   echo $char;//output single utf-16/utf-8 char (depends on default
output encoding)
}
echo $chars-bytes('gbk');

$chars-outputEncoding('gbk');
echo $chars;

ini_set('mchar_output_encoding','gbk');
echo $chars;

ini_set('mchar_filesystem_encoding','gbk');
echo $chars-filepath();


I think this probably highlights the fundamental difference of opinions on 
Unicode?

Handling unicode CONTENT is not the problem here. People nowadays expect to be 
able to use their own language to write code, and create functions using words 
that they recognize. In databases, table and field names are now expected to 
support unicode, rather than just handling unicode data pumped into ascii titled 
fields.


Personally I'm quite happy with just using ascii names for things, but more and 
more overseas customers provide contact details in 'strange' character sets that 
only unicode can handle, and handling THAT in PHP5 is not a problem. It's when 
people start building databases with unicode metadata and expect the tools 
interfacing with that to understand unicode as well.


It was my understanding that PHP6 was intended to provide international users 
with something that they could use in their own native language? Unicode titled 
files with unicode titled classes and functions.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Pierre Joye]

On Sat, Mar 13, 2010 at 10:07 AM, Chen Ze surfc...@gmail.com wrote:
 I think unicode should only care for string handling. Formatting
 numbers should not be the thing that unicode cares. Unicode is a
 standard for text, not for text or number formatting.

That's a totally wrong statement. Please read Unicode specs, there are
clear references to formatting as well as many other areas. It is
impossible to split the unicode scripts from the way we process or use
them (output, formatting, sorting, searching, conversions, etc.).

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Jordi Boggiano]

On Sat, Mar 13, 2010 at 12:09 PM, Lester Caine les...@lsces.co.uk wrote:
 It was my understanding that PHP6 was intended to provide international
 users with something that they could use in their own native language?
 Unicode titled files with unicode titled classes and functions.

Please get your facts straight about the current PHP, this is
perfectly valid code that runs fine, it contains a russian class name,
chinese method name and arabic variable name.

class ѮѠф {
  function 艾弗($ـجــج) {
return strtoupper($ـجــج);
  }
}

$obj = new ѮѠф;
echo $obj-艾弗('test'); // outputs TEST

I attached a copy of the code in a file in case your mail client
doesn't handle unicode as good as php ;)

The PHP6 unicode support was to have unicode strings being handled
natively by all functions, for example to have strlen() working fine
on a UTF-32 encoded string while currently one must use mb_strlen() to
get the correct result.

Cheers,
Jordi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Array access for UTF-strings (Was: PHP 6 as we know it suddenly died?)

[Keryx Web]

2010-03-12 18:36, Tomas Kuliavas skrev:

Keryx Web rašė:

2. If so, what will happen to array access in strings that are de
facto Unicode? Will the more clunky mb_substr() be the only option?


What will happen to array access in unicode strings, if code wants to
access them in bytes? Will some backwards incompatible binary be the
only option?

You want unicode strings. I want backwards compatibility which goes
further than php 5.2.1. I want to write bytes in hexadecimal notation. I
need both unicode aware and byte based functions.



Yours is a power user request, mine is a concern for the newbies.

PHP has gotten to where it is because it has been easy to pick up and 
new users will feel productive from day one.


I can say with 100 % certainty that new users will be SEVERELY confused 
if they use array access and get individual bytes from a multibyte 
encoded string.


Easy defaults for the newcomers and power tools for power users is a 
much better approach than the other way around.


To all:

I note that my question is still unanswered.


--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Array access for UTF-strings (Was: PHP 6 as we know it suddenly died?)

[Hannes Magnusson]

On Sat, Mar 13, 2010 at 14:59, Keryx Web webmas...@keryx.se wrote:
 To all:

 I note that my question is still unanswered.


Ask again in a year. We simply do not know.

-Hannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Moriyoshi Koizumi]

On Sat, Mar 13, 2010 at 8:09 PM, Lester Caine les...@lsces.co.uk wrote:
 Handling unicode CONTENT is not the problem here. People nowadays expect to
 be able to use their own language to write code, and create functions using
 words that they recognize. In databases, table and field names are now
 expected to support unicode, rather than just handling unicode data pumped
 into ascii titled fields.

 Personally I'm quite happy with just using ascii names for things, but more
 and more overseas customers provide contact details in 'strange' character
 sets that only unicode can handle, and handling THAT in PHP5 is not a
 problem. It's when people start building databases with unicode metadata and
 expect the tools interfacing with that to understand unicode as well.

 It was my understanding that PHP6 was intended to provide international
 users with something that they could use in their own native language?
 Unicode titled files with unicode titled classes and functions.

I doubt that many people are gonna start using non-latin characters
for the identifiers, as long as most of those generally use the
alphabetic keyboard, with which I cannot type any Japanese words as
fast as alphanumerics. In addition, I think RTL languages such as
Arabic aren't supposed to use with latin punctuation marks in a
programming language in the first place.

Moriyoshi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Moriyoshi Koizumi]

On Sat, Mar 13, 2010 at 6:07 PM, Chen Ze surfc...@gmail.com wrote:
 I think unicode should only care for string handling. Formatting
 numbers should not be the thing that unicode cares. Unicode is a
 standard for text, not for text or number formatting.

 Back to the days we don't have unicode, the number formatting have
 already existed. It even exists when computer was not invented.

 That is same for sorting.

 When we think about Unicode, we should think about those really
 related to Unicode,like file system. Number formatting and sorting are
 other things which intl cares.

 For the unicode, I think we should implement something like:

 $chars=new mchar($bytes,$bytes_encoding);
 echo $chars;//output encoding
 foreach ($chars as $char) {
      echo $char;//output single utf-16/utf-8 char (depends on default
 output encoding)
 }
 echo $chars-bytes('gbk');

 $chars-outputEncoding('gbk');
 echo $chars;

 ini_set('mchar_output_encoding','gbk');
 echo $chars;

 ini_set('mchar_filesystem_encoding','gbk');
 echo $chars-filepath();


I don't totally agree with what is being said here, but I guess we
don't have to make Unicode a first-class value.  Once operator
overloading is supported, Unicode strings can be represented as
objects, like Python does although  I didn't have a look at past
discussion on this topic.

Moriyoshi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Pierre Joye]

On Sat, Mar 13, 2010 at 3:13 PM, Moriyoshi Koizumi m...@mozo.jp wrote:

 I don't totally agree with what is being said here, but I guess we
 don't have to make Unicode a first-class value.  Once operator
 overloading is supported, Unicode strings can be represented as
 objects, like Python does although  I didn't have a look at past
 discussion on this topic.

Operators overloading, while being a cool feature, should not be
associated with Unicoderelated features. Or we are going to do the
exact same mistakes than before, way too many changes, features, work
to even get a visible deadline for the next major release.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading

[Richard Quadling]

On 13 March 2010 01:50, Chris Trahey christra...@gmail.com wrote:
 Perhaps a new concept in class-based OO programming, I'm not sure.

 Depending on your perspective you could call it ancestor overloading (or
 upstream overloading) or class underloading.


 We are increasingly developing with the aid of frameworks  libraries. In
 fact, this idea came from my current project using the Zend Framework.

 These libraries, while greatly extensible, are also fairly self-extending.
 That is, they include many classes that extend many classes, which is great.

 As consumers of these libraries, we can extend the classes and consume the
 API however we please, but there is one sticking point.

 We cannot change classes that many other classes extend without extending or
 changing each child class and then making sure that our code uses the new
 class.


 For a concrete example, I was working with the Zend_Form_Element subclasses,
 and I realized that I wanted to change some of the default behavior (in
 Zend_Form_Element).

 - at this point I will assume the reader understands why I wouldn't want to
 just start changing the Zend library files -

 There are many subclasses of Zend_Form_Element. If you want to change the
 default behavior for all of them, you have 3 choices currently:

 1. Directly edit the Zend_Form_Element file in the library, -bad for updates
  other projects that use the library

 2. subclass Zend_Form_Element and change declaration of the descendants to
 extend new class - same problems

 3. extend each child class and implement those subclasses in your app code
 -very tedious and TONS of repeated code, breaks consistency of API for
 developers.


 There could be a better way, if we could insert a class into the family
 tree.

 And that's the heart of this idea, so I'll repeat it:

 * insert a class into the family tree *


 Image we do it using an alternative keyword to extends, such as
 overloads.


 Example:


 class Library_Class { }

 class Library_Subclass extends Library_Class {}

 and then:

 class My_LibClass_Overload overloads Library_Class{}


 Now new instances of Library_Subclass actually extend My_LibClass_Overload,
 which extends Library_Class. The developer would then code
 My_LibClass_Overload as if it were declared like this:

 class Library_Class {}

 class My_LibClass_Overload extends Library_Class {}

 class Library_Subclass extends My_LibClass_Overload {}


 But indeed the declaration of Library_Subclass would *not* have to change.


 This way developers could extend default functionality and have *existing*
 library classes pick up the new functionality without redeclaring anything
 in the library.

 Downstream classes would still override any methods that they redeclare. If
 you wanted to have end-point classes in the library have different behavior,
 you would overload them instead, such as

 class My_LibSubclass_Overload overloads Lib_Subclass {}


 The benefit is that the application code can still consume standard
 classes, such as Library_Subclass and not need to know or care about the
 extended functionality.


 Going back to my concrete example, my code could then still use
 Zend_Form_Element_Text, but benefit from the modifications I added, without
 me having to touch the library code.


 I hope I've explained clearly what this could look like. I'm a younger
 developer, so forgive me if I'm rough on the terminology -perhaps
 overload/underload is not the best word for this functionality. Also, I'm
 not sure if there are other class-based OO languages that allow this kind of
 behavior... Prototypal languages perhaps, as is the case with javascript and
 the Obj.prototype which (combined with anonymous functions) allows you to
 extend the base functionality of other objects that extend it.


 Thank you for your comments and thoughts!


 Chris Trahey



I had exactly the same issue with Zend_Soap_AutoDiscover. This class
uses Zend_Soap_Wsdl to create the WSDL file for a SOAP service.

The class was hard coded. The AutoDiscover class allowed you to supply
a class name to handle complex types, but not in conjunction with xsd
scalar types. The Zend_Soap_Wsdl class handled php - xsd types and
read docblocks for that.

But if the docblock had an xsd type (xsd:datetime, xsd:token, etc.)
which are used to tell the consumer what the type is, then there was
no way to get these in.

So, I created this patch
http://framework.zend.com/code/changelog/Zend_Framework?cs=21379 (diff
http://framework.zend.com/code/browse/Zend_Framework/standard/trunk/library/Zend/Soap/AutoDiscover.php?r1=20096r2=21379)
which allows me to supply an alternative class name in a similar
fashion to being able to supply a complex type handler class name.

This was the easiest route I could find and the least impacting (full
BC exists).

The amendment I made to allow a subclass to be used as an alternative
is a one off hit, so maybe this technique could be used for Zend_Form
(I assume this is the class you 

Re: [PHP-DEV] PHP 6

[Moriyoshi Koizumi]

Surprisingly, It can be done quite easily with the current object
handler infrastructure.

Moriyoshi

On Sun, Mar 14, 2010 at 12:08 AM, Pierre Joye pierre@gmail.com wrote:
 On Sat, Mar 13, 2010 at 3:13 PM, Moriyoshi Koizumi m...@mozo.jp wrote:

 I don't totally agree with what is being said here, but I guess we
 don't have to make Unicode a first-class value.  Once operator
 overloading is supported, Unicode strings can be represented as
 objects, like Python does although  I didn't have a look at past
 discussion on this topic.

 Operators overloading, while being a cool feature, should not be
 associated with Unicoderelated features. Or we are going to do the
 exact same mistakes than before, way too many changes, features, work
 to even get a visible deadline for the next major release.

 Cheers,
 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

diff --git a/Zend/zend.h b/Zend/zend.h
index 38f461c..0ffcb1a 100644
--- a/Zend/zend.h
+++ b/Zend/zend.h
@@ -442,6 +442,7 @@ struct _zend_class_entry {
union _zend_function *__call;
union _zend_function *__callstatic;
union _zend_function *__tostring;
+   union _zend_function *__concat;
union _zend_function *serialize_func;
union _zend_function *unserialize_func;
 
diff --git a/Zend/zend_API.c b/Zend/zend_API.c
index 5433dc1..e0dcd73 100644
--- a/Zend/zend_API.c
+++ b/Zend/zend_API.c
@@ -1799,7 +1799,7 @@ ZEND_API int zend_register_functions(zend_class_entry 
*scope, const zend_functio
int count=0, unload=0;
HashTable *target_function_table = function_table;
int error_type;
-   zend_function *ctor = NULL, *dtor = NULL, *clone = NULL, *__get = NULL, 
*__set = NULL, *__unset = NULL, *__isset = NULL, *__call = NULL, *__callstatic 
= NULL, *__tostring = NULL;
+   zend_function *ctor = NULL, *dtor = NULL, *clone = NULL, *__get = NULL, 
*__set = NULL, *__unset = NULL, *__isset = NULL, *__call = NULL, *__callstatic 
= NULL, *__tostring = NULL, *__concat = NULL;
char *lowercase_name;
int fname_len;
char *lc_class_name = NULL;
@@ -1929,6 +1929,8 @@ ZEND_API int zend_register_functions(zend_class_entry 
*scope, const zend_functio
__unset = reg_function;
} else if ((fname_len == 
sizeof(ZEND_ISSET_FUNC_NAME)-1)  !memcmp(lowercase_name, 
ZEND_ISSET_FUNC_NAME, sizeof(ZEND_ISSET_FUNC_NAME))) {
__isset = reg_function;
+   } else if ((fname_len == 
sizeof(ZEND_CONCAT_FUNC_NAME)-1)  !memcmp(lowercase_name, 
ZEND_CONCAT_FUNC_NAME, sizeof(ZEND_CONCAT_FUNC_NAME))) {
+   __concat = reg_function;
} else {
reg_function = NULL;
}
@@ -1967,6 +1969,7 @@ ZEND_API int zend_register_functions(zend_class_entry 
*scope, const zend_functio
scope-__set = __set;
scope-__unset = __unset;
scope-__isset = __isset;
+scope-__concat = __concat;
if (ctor) {
ctor-common.fn_flags |= ZEND_ACC_CTOR;
if (ctor-common.fn_flags  ZEND_ACC_STATIC) {
@@ -2030,6 +2033,12 @@ ZEND_API int zend_register_functions(zend_class_entry 
*scope, const zend_functio
}
__isset-common.fn_flags = ~ZEND_ACC_ALLOW_STATIC;
}
+   if (__concat) {
+   if (__concat-common.fn_flags  ZEND_ACC_STATIC) {
+   zend_error(error_type, Method %s::%s() cannot 
be static, scope-name, __concat-common.function_name);
+   }
+   __concat-common.fn_flags = ~ZEND_ACC_ALLOW_STATIC;
+   }
efree(lc_class_name);
}
return SUCCESS;
diff --git a/Zend/zend_compile.c b/Zend/zend_compile.c
index 13b6c55..91cd34a 100644
--- a/Zend/zend_compile.c
+++ b/Zend/zend_compile.c
@@ -1267,6 +1267,10 @@ void zend_do_begin_function_declaration(znode 
*function_token, znode *function_n
} else if ((name_len == 
sizeof(ZEND_TOSTRING_FUNC_NAME)-1)  (!memcmp(lcname, ZEND_TOSTRING_FUNC_NAME, 
sizeof(ZEND_TOSTRING_FUNC_NAME)-1))) {
if (fn_flags  ((ZEND_ACC_PPP_MASK | 
ZEND_ACC_STATIC) ^ ZEND_ACC_PUBLIC)) {
zend_error(E_WARNING, The magic method 
__toString() must have public visibility and cannot be static);
+}
+   } else if ((name_len == 
sizeof(ZEND_CONCAT_FUNC_NAME)-1)  (!memcmp(lcname, ZEND_CONCAT_FUNC_NAME, 
sizeof(ZEND_CONCAT_FUNC_NAME)-1))) {
+   if (fn_flags  ((ZEND_ACC_PPP_MASK | 
ZEND_ACC_STATIC) ^ ZEND_ACC_PUBLIC)) {
+   zend_error(E_WARNING, The magic method 
 ZEND_CONCAT_FUNC_NAME  must have public visibility and 

Re: [PHP-DEV] PHP 6

[Moriyoshi Koizumi]

It looks like I stripped off too much. Attached is the right one.

Moriyoshi

On Sun, Mar 14, 2010 at 12:41 AM, Moriyoshi Koizumi m...@mozo.jp wrote:
 Surprisingly, It can be done quite easily with the current object
 handler infrastructure.

 Moriyoshi

 On Sun, Mar 14, 2010 at 12:08 AM, Pierre Joye pierre@gmail.com wrote:
 On Sat, Mar 13, 2010 at 3:13 PM, Moriyoshi Koizumi m...@mozo.jp wrote:

 I don't totally agree with what is being said here, but I guess we
 don't have to make Unicode a first-class value.  Once operator
 overloading is supported, Unicode strings can be represented as
 objects, like Python does although  I didn't have a look at past
 discussion on this topic.

 Operators overloading, while being a cool feature, should not be
 associated with Unicoderelated features. Or we are going to do the
 exact same mistakes than before, way too many changes, features, work
 to even get a visible deadline for the next major release.

 Cheers,
 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org


diff --git a/Zend/zend.h b/Zend/zend.h
index 38f461c..0ffcb1a 100644
--- a/Zend/zend.h
+++ b/Zend/zend.h
@@ -442,6 +442,7 @@ struct _zend_class_entry {
union _zend_function *__call;
union _zend_function *__callstatic;
union _zend_function *__tostring;
+   union _zend_function *__concat;
union _zend_function *serialize_func;
union _zend_function *unserialize_func;
 
diff --git a/Zend/zend_API.c b/Zend/zend_API.c
index 5433dc1..e0dcd73 100644
--- a/Zend/zend_API.c
+++ b/Zend/zend_API.c
@@ -1799,7 +1799,7 @@ ZEND_API int zend_register_functions(zend_class_entry 
*scope, const zend_functio
int count=0, unload=0;
HashTable *target_function_table = function_table;
int error_type;
-   zend_function *ctor = NULL, *dtor = NULL, *clone = NULL, *__get = NULL, 
*__set = NULL, *__unset = NULL, *__isset = NULL, *__call = NULL, *__callstatic 
= NULL, *__tostring = NULL;
+   zend_function *ctor = NULL, *dtor = NULL, *clone = NULL, *__get = NULL, 
*__set = NULL, *__unset = NULL, *__isset = NULL, *__call = NULL, *__callstatic 
= NULL, *__tostring = NULL, *__concat = NULL;
char *lowercase_name;
int fname_len;
char *lc_class_name = NULL;
@@ -1929,6 +1929,8 @@ ZEND_API int zend_register_functions(zend_class_entry 
*scope, const zend_functio
__unset = reg_function;
} else if ((fname_len == 
sizeof(ZEND_ISSET_FUNC_NAME)-1)  !memcmp(lowercase_name, 
ZEND_ISSET_FUNC_NAME, sizeof(ZEND_ISSET_FUNC_NAME))) {
__isset = reg_function;
+   } else if ((fname_len == 
sizeof(ZEND_CONCAT_FUNC_NAME)-1)  !memcmp(lowercase_name, 
ZEND_CONCAT_FUNC_NAME, sizeof(ZEND_CONCAT_FUNC_NAME))) {
+   __concat = reg_function;
} else {
reg_function = NULL;
}
@@ -1967,6 +1969,7 @@ ZEND_API int zend_register_functions(zend_class_entry 
*scope, const zend_functio
scope-__set = __set;
scope-__unset = __unset;
scope-__isset = __isset;
+   scope-__concat = __concat;
if (ctor) {
ctor-common.fn_flags |= ZEND_ACC_CTOR;
if (ctor-common.fn_flags  ZEND_ACC_STATIC) {
@@ -2030,6 +2033,12 @@ ZEND_API int zend_register_functions(zend_class_entry 
*scope, const zend_functio
}
__isset-common.fn_flags = ~ZEND_ACC_ALLOW_STATIC;
}
+   if (__concat) {
+   if (__concat-common.fn_flags  ZEND_ACC_STATIC) {
+   zend_error(error_type, Method %s::%s() cannot 
be static, scope-name, __concat-common.function_name);
+   }
+   __concat-common.fn_flags = ~ZEND_ACC_ALLOW_STATIC;
+   }
efree(lc_class_name);
}
return SUCCESS;
diff --git a/Zend/zend_compile.c b/Zend/zend_compile.c
index 13b6c55..91cd34a 100644
--- a/Zend/zend_compile.c
+++ b/Zend/zend_compile.c
@@ -1267,6 +1267,10 @@ void zend_do_begin_function_declaration(znode 
*function_token, znode *function_n
} else if ((name_len == 
sizeof(ZEND_TOSTRING_FUNC_NAME)-1)  (!memcmp(lcname, ZEND_TOSTRING_FUNC_NAME, 
sizeof(ZEND_TOSTRING_FUNC_NAME)-1))) {
if (fn_flags  ((ZEND_ACC_PPP_MASK | 
ZEND_ACC_STATIC) ^ ZEND_ACC_PUBLIC)) {
zend_error(E_WARNING, The magic method 
__toString() must have public visibility and cannot be static);
+}
+   } else if ((name_len == 
sizeof(ZEND_CONCAT_FUNC_NAME)-1)  (!memcmp(lcname, ZEND_CONCAT_FUNC_NAME, 
sizeof(ZEND_CONCAT_FUNC_NAME)-1))) {
+   if (fn_flags  ((ZEND_ACC_PPP_MASK | 

Re: [PHP-DEV] PHP 6

[Pierre Joye]

On Sat, Mar 13, 2010 at 4:41 PM, Moriyoshi Koizumi m...@mozo.jp wrote:
 Surprisingly, It can be done quite easily with the current object
 handler infrastructure.

I don't think It is about how easy it can be done using only object
but about opening the pandora box while trying to figure out higher
priorities (and get them released).


Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] SVN Account Request: ariva

[Christopher Jones]

Arunas Ivanauskas wrote:

Fixing bugs, developing the PHP runtime, can contribute ~10h/w


Hi Arunas,

It would be great to have your help.

There is some information on getting started in
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/README.SUBMITTING_PATCH?view=markup

Chris

--
Email: christopher.jo...@oracle.comTel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/   Free PHP Book: http://tinyurl.com/UGPOM

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Keryx Web]

Hi again

Trying to drive home this message I am starting a new thread.

Mini-summary: The next *major* edition of PHP must be 7, not 6.

Summary:

A. There seem to be universal agreement that the up until last week 
branch of PHP called trunk was going to be PHP 6 is a dead end and not 
the way into the future. (I'll call this PHP 6.old from now on.


B. Instead a more incremental approach is better, according to the 
consensus. (I'll call this PHP.next.)


C. BUT: There is a ton of articles and slides and blog posts describing 
PHP 6.old on the net already.


D. If there will be a new major edition of PHP with the version number 
6, not based on PHP 6.old but PHP.next it will take a huge amount of 
time for the old resources to disappear from Google search results and 
peoples minds.


E (for ergo): The next major version of PHP must be called 7, to avoid 
confusion. Could we not at least agree on this?


This is not a technical decision. It is a pedagogic decision.

It is not a decision about if we are going from 5.3 to 7 directly or if 
there should be a 5.4 release in between. Nor is it a decision about 
timetable or features.


(And it is an appropriate slap to publishers who have put out books with 
PHP 6 in their title, just for marketing purposes.)


OK?


You may stop reading now because I've made my point. Here comes a little 
fairy tale illustrating it further.


A fairy tale from real life.

Once upon a time there was a proposal for ECMAScript 4. Then along came 
Douglas Crockford and said this is bad. Then Microsoft said we concur.


And Mozilla and Adobe said: You are letting us down. You had promised 
to support ECMAScript 4 and you have a hidden agenda.


And there was some name calling.

And people were pissed.

But then they talked to each other, and reached an agreement. There 
should be ES 3.1 first and ES 4 later.


But they interpreted the agreement differently. Which made people pissed 
again.


And work continued on the two branches, which were now incompatible with 
each other.


But then they talked to each other again, and reached an agreement - again.

And - poff - ECMAScript 4 was gone.

And ECMAScript 3.1 became fifth edition, because changes were to large 
for a point release.


And the future became Harmony, which might become 6th edition, once 
it's done.


And everybody is happy :-)

To make my point absolutely clear, this is the analogy:

ES 4   = PHP 6.old
ES 3.1 = PHP 5.4
ES 5   = PHP 7

And for those who have missed it, here is the story retold by Brendan Eich:
http://developer.yahoo.com/yui/theater/video.php?v=eich-yuiconf2009-harmony

And retold by Doug C:
http://developer.yahoo.com/yui/theater/video.php?v=crockford-yuiconf2009-state


--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Derick Rethans]

On Thu, 11 Mar 2010, Rasmus Lerdorf wrote:

 So I think Lukas and others are right, let's move the PHP 6 trunk to a 
 branch since we are still going to need a bunch of code from it and 
 move development to trunk and start exploring lighter and more 
 approachable ways to attack Unicode.  We have a few already.  
 Enhanced mbstring and ext/intl.  Let's see some good ideas around that 
 and work on those in trunk.  Other features necessarily need to play 
 along with these in the same branch.  I refuse to go down the path of 
 a 5.4 branch and a separate Unicode branch again.
 
 The main focus here needs to be to get everyone working in the same 
 branch.

I am also in favour for getting back to one branch for new development. 
And that branch should be trunk. However, I am a little bit reluctant 
to just kill all Unicode support. I don't think we can get around the 
fact that propr Unicode support is going to be even more important in 
the future than it already is today. However, we can also not get around 
the fact that the current state of Unicode-in-PHP isn't the most ideal 
situation.

I do however think that most of the current approaches of adding Unicode 
support into PHP 6 (current trunk) have the proper ideas behind that, 
but I do think that in some cases we went slightly overboard of 
supporting Unicode everywhere with the new unicode type. For example, 
we don't really need to have this for variable or function names or 
support every encoding for writing scripts in. (We do 
need to *support* Unicode there, but not with the unicode string type.) 
Another example is that we perhaps don't have to support every encoding 
out there.

So I would suggest the following things to do:

- get rid of Jani's play branch
- move trunk to branches/FIRST_UNICODE_IDEA
- put 5.2 in security fix only mode
- pht 5.3 in bug fix only mode
- start adding new features (traits, Ilia's scalar typehint patch, 
  output buffering things) to the new trunk cloned from 5.3.
- in the meanwhile, start working on patching in back Unicode support, 
  but in small steps. Exactly which things, and how we'd have to find 
  out. But I do think it needs to be a *core* language feature, and not 
  simply solved by extensions. We also need to make sure everybody 
  understands that Unicode isn't just about encodings, or charsets and 
  that thre are differences between that. Education is going to be 
  important (and adding Unicode back in small bits would certainly help 
  there).

As I now have plenty of time to work on things, I'd be happy to act as 
RM, and wouldn't mind working on roadmaps and sorting out what good bits 
we have/had, and which things we don't want to port back into the new 
trunk. Depending on how things go, this could become 5.4 or 6 or 
something else.

with kind regards,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Derick Rethans]

On Sat, 13 Mar 2010, Moriyoshi Koizumi wrote:

 Huh? mbstring has been capable of handling lots of encodings other
 than UTF-8 since it was introduced.

I meant to say that mbstring does string manipulation functions, not 
full unicode support.

Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Johannes Schlüter]

Hi,

On Sat, 2010-03-13 at 11:57 -0500, Derick Rethans wrote:
 So I would suggest the following things to do:
 
 - get rid of Jani's play branch
 - move trunk to branches/FIRST_UNICODE_IDEA
 - put 5.2 in security fix only mode
 - pht 5.3 in bug fix only mode
 - start adding new features (traits, Ilia's scalar typehint patch, 
   output buffering things) to the new trunk cloned from 5.3.
 - in the meanwhile, start working on patching in back Unicode support, 
   but in small steps. Exactly which things, and how we'd have to find 
   out. But I do think it needs to be a *core* language feature, and not 
   simply solved by extensions. We also need to make sure everybody 
   understands that Unicode isn't just about encodings, or charsets and 
   that thre are differences between that. Education is going to be 
   important (and adding Unicode back in small bits would certainly help 
   there).

+1

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Moriyoshi Koizumi]

On Sun, Mar 14, 2010 at 1:57 AM, Derick Rethans der...@php.net wrote:

 - in the meanwhile, start working on patching in back Unicode support,
  but in small steps. Exactly which things, and how we'd have to find
  out. But I do think it needs to be a *core* language feature, and not
  simply solved by extensions. We also need to make sure everybody
  understands that Unicode isn't just about encodings, or charsets and
  that thre are differences between that. Education is going to be
  important (and adding Unicode back in small bits would certainly help
  there).

Unicode isn't just about a coded character set, but a whole lot of
specifications that are essential in handling various kinds of texts
within an application.  But, I don't really think it reinforces the
reason Unicode functionality needs to be part of core language.

Moriyoshi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading

[Paul E Chandler III]

It seems to me that you could transparently sub-class any framework's base 
classes with an autoloader implementation... without needing to alter the code 
that consumes them. You could also inject the code as part of your build  
test automation. Perhaps you could even make due with an AOP extension to PHP.

On Mar 12, 2010, at 5:50 PM, Chris Trahey wrote:

 Perhaps a new concept in class-based OO programming, I'm not sure.
 
 Depending on your perspective you could call it ancestor overloading (or
 upstream overloading) or class underloading.
 
 
 We are increasingly developing with the aid of frameworks  libraries. In
 fact, this idea came from my current project using the Zend Framework.
 
 These libraries, while greatly extensible, are also fairly self-extending.
 That is, they include many classes that extend many classes, which is great.
 
 As consumers of these libraries, we can extend the classes and consume the
 API however we please, but there is one sticking point.
 
 We cannot change classes that many other classes extend without extending or
 changing each child class and then making sure that our code uses the new
 class.
 
 
 For a concrete example, I was working with the Zend_Form_Element subclasses,
 and I realized that I wanted to change some of the default behavior (in
 Zend_Form_Element).
 
 - at this point I will assume the reader understands why I wouldn't want to
 just start changing the Zend library files -
 
 There are many subclasses of Zend_Form_Element. If you want to change the
 default behavior for all of them, you have 3 choices currently:
 
 1. Directly edit the Zend_Form_Element file in the library, -bad for updates
  other projects that use the library
 
 2. subclass Zend_Form_Element and change declaration of the descendants to
 extend new class - same problems
 
 3. extend each child class and implement those subclasses in your app code
 -very tedious and TONS of repeated code, breaks consistency of API for
 developers.
 
 
 There could be a better way, if we could insert a class into the family
 tree.
 
 And that's the heart of this idea, so I'll repeat it:
 
 * insert a class into the family tree *
 
 
 Image we do it using an alternative keyword to extends, such as
 overloads.
 
 
 Example:
 
 
 class Library_Class { }
 
 class Library_Subclass extends Library_Class {}
 
 and then:
 
 class My_LibClass_Overload overloads Library_Class{}
 
 
 Now new instances of Library_Subclass actually extend My_LibClass_Overload,
 which extends Library_Class. The developer would then code
 My_LibClass_Overload as if it were declared like this:
 
 class Library_Class {}
 
 class My_LibClass_Overload extends Library_Class {}
 
 class Library_Subclass extends My_LibClass_Overload {}
 
 
 But indeed the declaration of Library_Subclass would *not* have to change.
 
 
 This way developers could extend default functionality and have *existing*
 library classes pick up the new functionality without redeclaring anything
 in the library.
 
 Downstream classes would still override any methods that they redeclare. If
 you wanted to have end-point classes in the library have different behavior,
 you would overload them instead, such as
 
 class My_LibSubclass_Overload overloads Lib_Subclass {}
 
 
 The benefit is that the application code can still consume standard
 classes, such as Library_Subclass and not need to know or care about the
 extended functionality.
 
 
 Going back to my concrete example, my code could then still use
 Zend_Form_Element_Text, but benefit from the modifications I added, without
 me having to touch the library code.
 
 
 I hope I've explained clearly what this could look like. I'm a younger
 developer, so forgive me if I'm rough on the terminology -perhaps
 overload/underload is not the best word for this functionality. Also, I'm
 not sure if there are other class-based OO languages that allow this kind of
 behavior... Prototypal languages perhaps, as is the case with javascript and
 the Obj.prototype which (combined with anonymous functions) allows you to
 extend the base functionality of other objects that extend it.
 
 
 Thank you for your comments and thoughts!
 
 
 Chris Trahey
 
 Web Applications Developer
 
 Database Administrator
 
 CSISD [Technology]
 
 
 footnote: I sent this message from a different address and it did not show
 up. I tested sending to internals-h...@lists.php.net and did not get a
 response -so I assume there is an outgoing issue on my other server's side.
 Forgive me if this message shows up again.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Lukas Kahwe Smith]

On 13.03.2010, at 17:57, Derick Rethans wrote:

 I do however think that most of the current approaches of adding Unicode 
 support into PHP 6 (current trunk) have the proper ideas behind that, 
 but I do think that in some cases we went slightly overboard of 
 supporting Unicode everywhere with the new unicode type. For example, 
 we don't really need to have this for variable or function names or 
 support every encoding for writing scripts in. (We do 
 need to *support* Unicode there, but not with the unicode string type.) 
 Another example is that we perhaps don't have to support every encoding 
 out there.

Right, dropping the current trunk doesnt mean that we should forget about 
unicode. However we need to find a balance between ease of use, performance 
(especially for those who do not need better unicode support) and release 
timeframe.

 So I would suggest the following things to do:
 
 - get rid of Jani's play branch
 - move trunk to branches/FIRST_UNICODE_IDEA
 - put 5.2 in security fix only mode
 - pht 5.3 in bug fix only mode
 - start adding new features (traits, Ilia's scalar typehint patch, 
  output buffering things) to the new trunk cloned from 5.3.

+1

As for the exact features to merge, lets first start with formulating a plan 
about what we want to see in the next release. I also think it makes sense to 
base the number and scope if the features on a rough idea of when we want to 
see this next release. In order to put together that release plan i guess we 
should have an RM defined first. I think Andi said the same thing on IRC 
yesterday.

I can certainly see you as RM, but i would like to propose another newer guy 
for the job:
David Soria Parra

That being said, I also think that the model of a co-RM that focuses on the 
less technical aspects as proven itself with 5.3. not only does it mean the 
work load is spread over two shoulders, it also means that developers can get 
answers quicker (especially as we are all sometimes swamped with work or god 
forbid go on vacation). I am willing to take the co-RM role again. I can also 
see Philip in this role. But I think the more important question is to find the 
technical RM and if the technical RM feels like he can use the support he can 
just appoint a co-RM.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Rasmus Lerdorf]

On 03/13/2010 08:57 AM, Derick Rethans wrote:
 On Thu, 11 Mar 2010, Rasmus Lerdorf wrote:
 
 So I think Lukas and others are right, let's move the PHP 6 trunk to a 
 branch since we are still going to need a bunch of code from it and 
 move development to trunk and start exploring lighter and more 
 approachable ways to attack Unicode.  We have a few already.  
 Enhanced mbstring and ext/intl.  Let's see some good ideas around that 
 and work on those in trunk.  Other features necessarily need to play 
 along with these in the same branch.  I refuse to go down the path of 
 a 5.4 branch and a separate Unicode branch again.

 The main focus here needs to be to get everyone working in the same 
 branch.
 
 I am also in favour for getting back to one branch for new development. 
 And that branch should be trunk. However, I am a little bit reluctant 
 to just kill all Unicode support. I don't think we can get around the 
 fact that propr Unicode support is going to be even more important in 
 the future than it already is today. However, we can also not get around 
 the fact that the current state of Unicode-in-PHP isn't the most ideal 
 situation.

You know I am not in favour of killing Unicode.  We can't kill
Unicode.  We live in a Unicode world, like it or not.  We just need to
reset the effort and do it in smaller steps.  So, setting aside the
current trunk in a branch and slowly bringing the good bits and pieces
from it into the development branch in a way that doesn't alienate
everyone should be the goal here.

 - get rid of Jani's play branch

I don't think Jani has messed up anything in that branch yet, so that
could be the new trunk.  It's just cloned from 5.3 exactly like you are
proposing.

 As I now have plenty of time to work on things, I'd be happy to act as 
 RM, and wouldn't mind working on roadmaps and sorting out what good bits 
 we have/had, and which things we don't want to port back into the new 
 trunk. Depending on how things go, this could become 5.4 or 6 or 
 something else.

Cool, theoretically I have plenty of time right now as well, although in
practice that doesn't seem to be the case.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Olivier Hill]

On Sat, Mar 13, 2010 at 11:57 AM, Derick Rethans der...@php.net wrote:

 As I now have plenty of time to work on things, I'd be happy to act as
 RM, and wouldn't mind working on roadmaps and sorting out what good bits
 we have/had, and which things we don't want to port back into the new
 trunk. Depending on how things go, this could become 5.4 or 6 or
 something else.

If you are proposing it and have time to do it, I think you being the
RM for the Unicode stuff (and whatever version number this is) is
going to be the only way to move the Unicode forward.

As for Lukas idea, I agree having two RMs (or co-RM) elimitates
problems we had in the past.

We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the development focus needs to be towards new features AND Unicode,
not having the new feature branch, and the siberia branch with Unicode
support.

Anyway, might be useless email, but I'm +1 on Derick's ideas (and +10
on PHP5.2 security patches only. Some people don't even realize PHP
5.3 is out, need to move on now)

Best regards,
Olivier
-- 
http://www.olivierhill.ca/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Rasmus Lerdorf]

On 03/13/2010 08:55 AM, Keryx Web wrote:
 Hi again
 
 Trying to drive home this message I am starting a new thread.
 
 Mini-summary: The next *major* edition of PHP must be 7, not 6.
 
 Summary:
 
 A. There seem to be universal agreement that the up until last week
 branch of PHP called trunk was going to be PHP 6 is a dead end and not
 the way into the future. (I'll call this PHP 6.old from now on.
 
 B. Instead a more incremental approach is better, according to the
 consensus. (I'll call this PHP.next.)
 
 C. BUT: There is a ton of articles and slides and blog posts describing
 PHP 6.old on the net already.
 
 D. If there will be a new major edition of PHP with the version number
 6, not based on PHP 6.old but PHP.next it will take a huge amount of
 time for the old resources to disappear from Google search results and
 peoples minds.
 
 E (for ergo): The next major version of PHP must be called 7, to avoid
 confusion. Could we not at least agree on this?
 
 This is not a technical decision. It is a pedagogic decision.
 
 It is not a decision about if we are going from 5.3 to 7 directly or if
 there should be a 5.4 release in between. Nor is it a decision about
 timetable or features.
 
 (And it is an appropriate slap to publishers who have put out books with
 PHP 6 in their title, just for marketing purposes.)
 
 OK?

No, not ok.  We will call the next release whatever we like.  People who
have written books or articles about PHP 6 inferring they knew what the
final state of PHP 6 would be were misguided.  We never got to the point
of a final feature set much less a release date.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Alain Williams]

On Sat, Mar 13, 2010 at 10:33:59AM -0800, Rasmus Lerdorf wrote:

 No, not ok.  We will call the next release whatever we like.  People who
 have written books or articles about PHP 6 inferring they knew what the
 final state of PHP 6 would be were misguided.  We never got to the point
 of a final feature set much less a release date.

+1

I occasionally teach PHP courses and mention up  coming features,
but always with the caveat: nothing is set in stone until it hits the streets.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include std_disclaimer.h

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6

[Eric Stewart]

On Sat, Mar 13, 2010 at 11:57 AM, Derick Rethans der...@php.net wrote:

 On Thu, 11 Mar 2010, Rasmus Lerdorf wrote:

  So I think Lukas and others are right, let's move the PHP 6 trunk to a
  branch since we are still going to need a bunch of code from it and
  move development to trunk and start exploring lighter and more
  approachable ways to attack Unicode.  We have a few already.
  Enhanced mbstring and ext/intl.  Let's see some good ideas around that
  and work on those in trunk.  Other features necessarily need to play
  along with these in the same branch.  I refuse to go down the path of
  a 5.4 branch and a separate Unicode branch again.
 
  The main focus here needs to be to get everyone working in the same
  branch.

 I am also in favour for getting back to one branch for new development.
 And that branch should be trunk. However, I am a little bit reluctant
 to just kill all Unicode support. I don't think we can get around the
 fact that propr Unicode support is going to be even more important in
 the future than it already is today. However, we can also not get around
 the fact that the current state of Unicode-in-PHP isn't the most ideal
 situation.

 I do however think that most of the current approaches of adding Unicode
 support into PHP 6 (current trunk) have the proper ideas behind that,
 but I do think that in some cases we went slightly overboard of
 supporting Unicode everywhere with the new unicode type. For example,
 we don't really need to have this for variable or function names or
 support every encoding for writing scripts in. (We do
 need to *support* Unicode there, but not with the unicode string type.)
 Another example is that we perhaps don't have to support every encoding
 out there.

 So I would suggest the following things to do:

 - get rid of Jani's play branch
 - move trunk to branches/FIRST_UNICODE_IDEA
 - put 5.2 in security fix only mode
 - pht 5.3 in bug fix only mode
 - start adding new features (traits, Ilia's scalar typehint patch,
  output buffering things) to the new trunk cloned from 5.3.
 - in the meanwhile, start working on patching in back Unicode support,
  but in small steps. Exactly which things, and how we'd have to find
  out. But I do think it needs to be a *core* language feature, and not
  simply solved by extensions. We also need to make sure everybody
  understands that Unicode isn't just about encodings, or charsets and
  that thre are differences between that. Education is going to be
  important (and adding Unicode back in small bits would certainly help
  there).

 As I now have plenty of time to work on things, I'd be happy to act as
 RM, and wouldn't mind working on roadmaps and sorting out what good bits
 we have/had, and which things we don't want to port back into the new
 trunk. Depending on how things go, this could become 5.4 or 6 or
 something else.

 with kind regards,
 Derick

 --
 http://derickrethans.nl | http://xdebug.org
 Like Xdebug? Consider a donation: http://xdebug.org/donate.php
 twitter: @derickr and @xdebug

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


+1 Single Development Branch and move 6.0 branch to UNICODE_FIRST_ATTEMPT
+1 Derick RM to spearhead a more progressive approach to implementing
Unicode support.

Eric Lee Stewart

Re: [PHP-DEV] PHP 6

[Pierre Joye]

hi,

On Sat, Mar 13, 2010 at 7:13 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:

 - get rid of Jani's play branch

 I don't think Jani has messed up anything in that branch yet, so that
 could be the new trunk.  It's just cloned from 5.3 exactly like you are
 proposing.

Not exactly, there are commits done in 5.3 since the creation of this
branch. I would suggest to simply kill it, create trunk from PHP_5_3
and then Jani can merge the OB API patch again.


 Cool, theoretically I have plenty of time right now as well, although in
 practice that doesn't seem to be the case.

I'm in favour of David as we need fresh blood, he has no history or
conflict, very neutral on all aspects and has a very good tech
knowledge of the core as well as many extensions. He has also time to
fully assume this role. And Lukas as co-lead, for the reasons he
explained in his reply.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Sebastian Bergmann]

Rasmus Lerdorf wrote:
 No, not ok.  We will call the next release whatever we like.  People who
 have written books or articles about PHP 6 inferring they knew what the
 final state of PHP 6 would be were misguided.  We never got to the point
 of a final feature set much less a release date.

 +1

 Authors that wrote, publishers that published and readers that bought
 books on PHP 6 need to be ... punished ;-)

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Stefan Marr]

On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote:

 Rasmus Lerdorf wrote:
 No, not ok.  We will call the next release whatever we like.  People who
 have written books or articles about PHP 6 inferring they knew what the
 final state of PHP 6 would be were misguided.  We never got to the point
 of a final feature set much less a release date.
 
 +1
 
 Authors that wrote, publishers that published and readers that bought
 books on PHP 6 need to be ... punished ;-)
Is that wise and well-considered or something the community might regret in the 
long run?

Best regards
Stefan


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Sebastian Bergmann]

Stefan Marr wrote:
 Is that wise and well-considered or something the community might 
 regret in the long run?

 The books in question have not been written by community members
 (because those know better). I think there are so many PHP 6 books on
 the market because greedy publishers want to release old content under
 a new title and use a version bump (that has not happened yet) to cover
 up this fact.

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Lukas Kahwe Smith]

On 13.03.2010, at 22:52, Stefan Marr wrote:

 
 On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote:
 
 Rasmus Lerdorf wrote:
 No, not ok.  We will call the next release whatever we like.  People who
 have written books or articles about PHP 6 inferring they knew what the
 final state of PHP 6 would be were misguided.  We never got to the point
 of a final feature set much less a release date.
 
 +1
 
 Authors that wrote, publishers that published and readers that bought
 books on PHP 6 need to be ... punished ;-)
 Is that wise and well-considered or something the community might regret in 
 the long run?


Nobody needs to be punished and I think Rasmus stayed clear of such words for a 
reason. The name of the next version is not really all that relevant more if 
the next version will be a minor bump (aka x.y+1) or a major (aka x+1.y).

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Marco Tabini]

Hey Sebastian—

On 2010-03-13, at 4:55 PM, Sebastian Bergmann wrote:

 Stefan Marr wrote:
 Is that wise and well-considered or something the community might 
 regret in the long run?
 
 The books in question have not been written by community members
 (because those know better). I think there are so many PHP 6 books on
 the market because greedy publishers want to release old content under
 a new title and use a version bump (that has not happened yet) to cover
 up this fact.

Well said! In all fairness, though, this doesn't change the fact that the books 
exist—and that their keyword trolling is eventually going to hurt those who 
look for information on PHP 6, if that's what the final product is going to be 
called.

But, really, who cares about a name while there isn't even a spec? The name 
should be the last thing that needs to be considered—literally, so that the 
trolls don't have an opportunity to flood the market with opportunistic titles 
until the new version is well defined and ready to go. Calling it “trunk” at 
this point ought to be more than enough, IMO.


—Mt.

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Sebastian Bergmann]

Lukas Kahwe Smith wrote:
 Nobody needs to be punished

 My choice of words was bad, sorry.

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Philip Olson]

On Mar 13, 2010, at 1:56 PM, Lukas Kahwe Smith wrote:

 
 On 13.03.2010, at 22:52, Stefan Marr wrote:
 
 
 On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote:
 
 Rasmus Lerdorf wrote:
 No, not ok.  We will call the next release whatever we like.  People who
 have written books or articles about PHP 6 inferring they knew what the
 final state of PHP 6 would be were misguided.  We never got to the point
 of a final feature set much less a release date.
 
 +1
 
 Authors that wrote, publishers that published and readers that bought
 books on PHP 6 need to be ... punished ;-)
 Is that wise and well-considered or something the community might regret in 
 the long run?
 
 
 Nobody needs to be punished and I think Rasmus stayed clear of such words for 
 a reason. The name of the next version is not really all that relevant more 
 if the next version will be a minor bump (aka x.y+1) or a major (aka x+1.y).

The PHP manual refers to PHP 6 over 200 times, and there are probably a few 
people who've written code that takes this information into account. I'm not 
saying the proposal in this thread is a solution or needed, but there is a 
valid concern here.

The PHP manual will be updated once this is figured out, with extra care 
ensuring unicode and PHP 6 information is current. All suggestions for how to 
handle this today are welcome.

Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Stefan Marr]

On 13 Mar 2010, at 22:55, Sebastian Bergmann wrote:

 Stefan Marr wrote:
 Is that wise and well-considered or something the community might 
 regret in the long run?
 
 The books in question have not been written by community members
 (because those know better). I think there are so many PHP 6 books on
 the market because greedy publishers want to release old content under
 a new title and use a version bump (that has not happened yet) to cover
 up this fact.
Even if that is the fact, first, I disagree with your definition of community, 
and second, how does a PHP beginner know about that? These are the people which 
will be confused.

Anyway, that is a political discussion, and I share the concerns raised in this 
thread.


What ever the decision on that matter will be, it should be properly documented 
together with the goals for 'The Next Big Thing'.
And, well, I think, a proper RFC would be the way to go, to document the 
goals/roadmap and have to have a base for discussion. 

Best regards
Stefan





 
 -- 
 Sebastian BergmannCo-Founder and Principal Consultant
 http://sebastian-bergmann.de/   http://thePHP.cc/
 
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading

[Abraham Block]

This is a good use of the decorator pattern. Let's say you don't like the
way Zend_Form_Element filters form names. You can decorate it with a Your
own class which overrides this, and whenever you add a new element to your
form, decorate it with this class.

On Sat, Mar 13, 2010 at 10:10 AM, Richard Quadling rquadl...@googlemail.com
 wrote:

 On 13 March 2010 01:50, Chris Trahey christra...@gmail.com wrote:
  Perhaps a new concept in class-based OO programming, I'm not sure.
 
  Depending on your perspective you could call it ancestor overloading (or
  upstream overloading) or class underloading.
 
 
  We are increasingly developing with the aid of frameworks  libraries. In
  fact, this idea came from my current project using the Zend Framework.
 
  These libraries, while greatly extensible, are also fairly
 self-extending.
  That is, they include many classes that extend many classes, which is
 great.
 
  As consumers of these libraries, we can extend the classes and consume
 the
  API however we please, but there is one sticking point.
 
  We cannot change classes that many other classes extend without extending
 or
  changing each child class and then making sure that our code uses the new
  class.
 
 
  For a concrete example, I was working with the Zend_Form_Element
 subclasses,
  and I realized that I wanted to change some of the default behavior (in
  Zend_Form_Element).
 
  - at this point I will assume the reader understands why I wouldn't want
 to
  just start changing the Zend library files -
 
  There are many subclasses of Zend_Form_Element. If you want to change the
  default behavior for all of them, you have 3 choices currently:
 
  1. Directly edit the Zend_Form_Element file in the library, -bad for
 updates
   other projects that use the library
 
  2. subclass Zend_Form_Element and change declaration of the descendants
 to
  extend new class - same problems
 
  3. extend each child class and implement those subclasses in your app
 code
  -very tedious and TONS of repeated code, breaks consistency of API for
  developers.
 
 
  There could be a better way, if we could insert a class into the family
  tree.
 
  And that's the heart of this idea, so I'll repeat it:
 
  * insert a class into the family tree *
 
 
  Image we do it using an alternative keyword to extends, such as
  overloads.
 
 
  Example:
 
 
  class Library_Class { }
 
  class Library_Subclass extends Library_Class {}
 
  and then:
 
  class My_LibClass_Overload overloads Library_Class{}
 
 
  Now new instances of Library_Subclass actually extend
 My_LibClass_Overload,
  which extends Library_Class. The developer would then code
  My_LibClass_Overload as if it were declared like this:
 
  class Library_Class {}
 
  class My_LibClass_Overload extends Library_Class {}
 
  class Library_Subclass extends My_LibClass_Overload {}
 
 
  But indeed the declaration of Library_Subclass would *not* have to
 change.
 
 
  This way developers could extend default functionality and have
 *existing*
  library classes pick up the new functionality without redeclaring
 anything
  in the library.
 
  Downstream classes would still override any methods that they redeclare.
 If
  you wanted to have end-point classes in the library have different
 behavior,
  you would overload them instead, such as
 
  class My_LibSubclass_Overload overloads Lib_Subclass {}
 
 
  The benefit is that the application code can still consume standard
  classes, such as Library_Subclass and not need to know or care about the
  extended functionality.
 
 
  Going back to my concrete example, my code could then still use
  Zend_Form_Element_Text, but benefit from the modifications I added,
 without
  me having to touch the library code.
 
 
  I hope I've explained clearly what this could look like. I'm a younger
  developer, so forgive me if I'm rough on the terminology -perhaps
  overload/underload is not the best word for this functionality. Also, I'm
  not sure if there are other class-based OO languages that allow this kind
 of
  behavior... Prototypal languages perhaps, as is the case with javascript
 and
  the Obj.prototype which (combined with anonymous functions) allows you to
  extend the base functionality of other objects that extend it.
 
 
  Thank you for your comments and thoughts!
 
 
  Chris Trahey



 I had exactly the same issue with Zend_Soap_AutoDiscover. This class
 uses Zend_Soap_Wsdl to create the WSDL file for a SOAP service.

 The class was hard coded. The AutoDiscover class allowed you to supply
 a class name to handle complex types, but not in conjunction with xsd
 scalar types. The Zend_Soap_Wsdl class handled php - xsd types and
 read docblocks for that.

 But if the docblock had an xsd type (xsd:datetime, xsd:token, etc.)
 which are used to tell the consumer what the type is, then there was
 no way to get these in.

 So, I created this patch
 http://framework.zend.com/code/changelog/Zend_Framework?cs=21379 (diff

 

[PHP-DEV] Implementing fdopen in PHP

[Dennis Hotson]

Hi all,

It's my first post, so go easy on me. :-)

I'm trying to implement PHP support for github's erlang RPC server called
ernie.
So basically I've been porting the following ruby code to PHP:
http://github.com/mojombo/ernie/blob/master/lib/ernie.rb

The problem I'm having is on line 127-128:
  input = IO.new(3)

I believe this is equivalent to fdopen() in C, but there doesn't appear to
be any way to do this in PHP.

So basically, I'm a bit stuck and looking for advice on how to proceed.
Should I implement this in core PHP or as an extension? What's the best way
to get a function like this into PHP?

Regards,
Dennis Hotson

[PHP-DEV] Where are we ACTUALLY on Unicode?

[Lester Caine]

From Andrei Zmievski last year 

In PHP 6, everything by default will be Unicode, such as default string 
types, said PHP core developer Andrei Zmievski during a keynote presentation at the 2009 
Zend/PHP conference in San Jose, Calif.  The PHP 6 platform also will feature the ability 
to use Unicode characters for identifiers.


I must say that I was still under the impression that USING Unicode in PHP5 was 
not possible? I know that with care some language related constructs can be 
used, but thought that these are not readily transferred between installations? 
I presume that the 'examples' of internationalization actually only work because 
PHP5 see them as a strange ascii string? Rather than a true unicode string? And 
if you see them as 'unicode' it is because 'your email client can handle them' 
rather than because PHP5 is?


From my own view point, as I have said, using strange names for identifiers 
will probably not happen, but I am now using using Unicode to store customer 
names and other data which in the past have been messed up when 'code pages' 
were being used. I can nowadays simply cut and past those details from paypal or 
wherever and use them, but if I access that data directly from PHP5 things 
become a little hit or miss. Quite often content gets corrupted because it has 
not been 'unmangeled and remangled' when the database just handles it transparently.


What I am probably asking is what was the brick wall PHP6 hit. I was under the 
impression that there was no agreement on 'switchable or only' to unicode core? 
( And those who did write PHP6 books seemed to have their own views on which way 
the discussions would go ;) ).


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

[William A. Rowe Jr.]

If Unicode were the solution, the PHP project was on the right page with 6.0.
Sure there remained work to do, but...

How long did it take to realize UTF16 wasn't the end of the story?  UCS-4 is
the minimum to solve this, and we all agree that 32 bits aren't storing a single
char in the western world, no way, no how.

The UTF-8 solution is probably the right answer... you maintain 95% of char *UTF
behavior, and you gain international character representation.  The only Unicode
OS I can think of offhand is NT, and of course they hit the UCS-4 problem early.
They found this out 15+ years ago.

Sure it doesn't appear as atomic, one Xword per char, but the existing library
frameworks contain most of the string processing that is required.  There is no
16-bit network transmission API that I can think of, you are still devolving to
UTF-8 for client results.

To move forward with accepting -and preferring- UTF-8 as the representation of
characters throughout PHP, recognizing UTF-8 for char-length representations,
and so forth, would do wonders to move forwards.  And 8-bit octet data can be
set aside in the same data structures.  It is the straightforward answer, which
is probably why Linux did not repeat Windows NT decision, and adopted utf-8.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Req #51295: busyTimeout method for SQLite3

[Mark Karpeles]

Hello,

I've been encountering a problem with SELECT queries and SQLite3 as load
was growing on my system. From times to times I was getting this error:

Warning: SQLite3Stmt::execute(): Unable to execute statement: database
is locked

After searching on google I saw I should call sqlite3_busy_timeout() and
found out that there was no way to call it from the SQLite3 extension
(which is new to PHP 5.3.x).

Here's a patch that will add this method to the SQLite3 class:

http://bugs.php.net/51295
https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch

Any comment welcome.


Mark


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3

[Jess Portnoy]

Hello Mark,

Note that while indeed sqlite3_busy_timeout() is not extended by the 
SQLite3 and PDO_SQLITE extensions, it is called internally in 
ext/pdo_sqlite/sqlite_driver.c.
I think it is a good idea to extend it but also, that if you do, it 
should probably also be done for PDO_SQLITE as it may be useful there as 
well.


May the source be with you,
Best regards,
Jess Portnoy



Mark Karpeles wrote:

Hello,

I've been encountering a problem with SELECT queries and SQLite3 as load
was growing on my system. From times to times I was getting this error:

Warning: SQLite3Stmt::execute(): Unable to execute statement: database
is locked

After searching on google I saw I should call sqlite3_busy_timeout() and
found out that there was no way to call it from the SQLite3 extension
(which is new to PHP 5.3.x).

Here's a patch that will add this method to the SQLite3 class:

http://bugs.php.net/51295
https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch

Any comment welcome.


Mark


  


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php