[PHP-DEV] PHP 4 Bug Summary Report
PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (624 total including feature requests) ===[*Compile Issues]== 43389 Open configure ignoring --without-cdb flag ===[Apache2 related]== 38670 Open Whole 4.4.x branch has problem with open_basedir option nested from Apache2 ===[Arrays related]=== 31114 Assigned foreach modify array (works with PHP 5.1) 37451 Open array_multisort fails to trigger by val copy of data (works in PHP = 5.1) 39764 Suspended array_key_exists inconsistent behavior 42177 Open Warning array_merge_recursive(): recursion detected comes again... ===[CGI related]== 42180 Open php in fastcgi environment periodicaly get 90% of CPU ===[Class/Object related]= 39254 Open Refcount error with static variables and object references (PHP4 only) ===[Date/time related] 43472 Open strtotime(first Sunday ... does not work in command line ===[Documentation problem] 29045 Suspended gzopen for URL 36663 Open unexpected difference between zlib.output_compression and ob_gzhandler ===[FDF related]== 34811 Assigned fdf_get_value max size ===[Feature/Change Request]=== 3066 Open Parameter for dns functions to select different DNS 3799 Suspended default_charset brings small incompatibility 3830 Open Function to timeout/break off a function 5007 Analyzed enable no-resolve mode for here docs 5169 Open Missing recursive behavior 5311 Analyzed implement checkdnsrr() and getmxrr() on windows 5575 Open open_basedir to ~ 5601 Analyzed @function() should not turn of error reporting for critical errors 5804 Open parser error if any spaces follow indentifier in with here doc syntax 5883 Assigned --enable-trans-sid modification request 5954 Open Informix can't reliably figure if a text result column is NULL 5975 Open version of strip_tags() that specifies tags to strip (instead of tags to keep) 6118 Open Can not supress runtime warnings on foreach 6268 Open ternary op return only by value 6399 Open checkdate should be able to validate a time as well as a date (timestamp) 6427 Open func_get_arg() does not support references 6503 Open no support for multiple resultset query? 6512 Analyzed sort() Does not sort stings as expected 6574 Open SMTP functions via IMAP c-client library 6680 Open regexps (ereg*) ignores locale settings 6911 Open Problem with array_merge(_recursive) 6927 Suspended 6932 Open Filesize / File_exists and include_path 6993 Open uninstalling is a pain in the ass 7006 Open preg_replace ( string pattern, array replacement, string subject ); 7028 Analyzed xml=shared and wddx do not work together 7132 Assigned fsockopen doesn't report dns lookup failure 7398 Open Stored procedure error return values not passed through 7507 Open Better ODBC error reporting/fetching 7541 Open please consider also support HPUX shl_* 7553 Open RFC: Uplevel Block structure 7559 Open zend_hash_get_current_key_ex returning persistent strings 7578 Open next() and current() do not return referenceing arrays 7808 Open variable value triggerd by function 7923 Analyzed htmlentities doesn't work for ISO 8859-2 7930 Open List() constructor reference assignment 8100 Assigned extract(), extra feature 8108 Analyzed implement trans-sid as output handler 8295 Open absolute path in extension= directive in php.ini not recognized 8395 Open register_shutdown_function() error 8397 Open Multi-results sets are not suppported 8427 Analyzed Unwanted references 8428 Open continue doesn't pass thru a switch statement 8595 Open More effective parsing of list() (+other) 8640 Open enumeration type 8685 Open heredoc: remove column 1 closing identifier requirement 8809 Open Cookieless session with Header redirects 8827 Open PHP_AUTH_PW stores password when using External Authentication 8855 Open session_start should return also FALSE 8897 Open Significant portions of the InterBase API have no PHP representation. 8948 Open readline_completion_function enhance 9095 Open colon/semicolon delimitd extension_dir ? 9195 Analyzed Default class function arguments 9262 Analyzed Inconsistency in the implementation of here-docs 9266 Analyzed Unable to load 14 of php's extensions 9308 Open Allow Unix to use Win32 only mail options
Re: [PHP-DEV] E_DEPRECATED for 5.3
On 16.02.2008, at 02:14, Lars Strojny wrote:
I've heard that E_DEPRECATED is still missing nevertheless its
introduction is planned for 5.3. So I've wrote it [1] based on a
slightly outdated patch by Felipe. The patch is so far complete, as
far
Thx!
as I can tell, but one thing I'm wondering about is whether we should
trigger E_DEPRECATED warnings if the related ini-settings are present
(magic_quotes_gpc, magic_quotes_runtime, register_globals). I would
say
yes, but I need some advice where to do that.
like others have said .. yes .. these should emit deprecated warnings.
For the docs team: I've added links in the E_DEPRECATED messages to
http://php.net/{migrate}#deprecated func. The {migrate}-part can
later be easily replaced once the appendix to the migration guide
which
explains how to deal with this deprecations is set up.
very cool!
»Aber das Verhältnis von Leben und Produktion, das jenes
real herabsetzt zur ephemeren Erscheinung von dieser, ist
snip
please do follow the mailinglist rules and keep your signature to 2
lines max:
http://php.net/reST/php-src/README.MAILINGLIST_RULES
in that context i would like to also remind people that they could be
doing a better job at quoting. this is not about perfection (which is
probably hard to define on this anyways), but just try to remember
that a few seconds of effort will save a couple thousand people at
least as many seconds.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_DEPRECATED for 5.3
Hi Lukas, Am Montag, den 18.02.2008, 10:33 +0100 schrieb Lukas Kahwe Smith: [... deprecated ini settings ...] like others have said .. yes .. these should emit deprecated warnings. Would be great if someone could give me a hint where this should be done. I'm pretty new to the php-src, so I need some advice. [...] please do follow the mailinglist rules and keep your signature to 2 lines max: http://php.net/reST/php-src/README.MAILINGLIST_RULES Sorry, seems like a read the rules not carefully enough. Going to use another signature from now on. cu, Lars -- Lars Strojny Senior Software Developer MediaVentures GmbH (http://mediaventures.de) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net Num Status Summary (57 total including feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[Apache2 related]== 42209 Open fail on make for sapi/apache2handler/apache_config.lo 44083 Open virtual() not outputting results if zlib ouptut compression is on ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Assigned array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy 44043 Open Enforcing a method without specifying the arguments ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api ===[Feature/Change Request]=== 20377 Open php_admin_value affects _only_ .htaccess 27618 Open curl_multi_info_read does not appear to work 28261 Open Lifting reserved keyword restriction for method names 29479 Suspended changing current process name 34211 Open PDO_OCI: Allow for data type TIMESTAMP(0) WITH LOCAL TIME ZONE 34252 Open Base functions extension and refactoring 34527 Open trim functions extension 34775 Open parse_url() provide better error description on failure 34882 Open Unable to access *original* posted variable name with dot in 35309 Open Database connection pooling 37081 Open Make the include-errors mention faulty permissions 37380 Open DOMDocument-createAttribute[NS] can't set value 37546 Open DOMDocumentFragment-appendXML namespace support 38622 Open Proposed new security scheme for shared hosting (safe mode substitute) 38946 Open pecl/docblock should be merged into ext/tokenizer 40013 Open php_uname() doesnt return nodename 40499 Open filter sapi does not register any highlightning filter 41019 Assigned auto update feature for FastCGI for IIS 41602 Open POSIX functions on Windows using Cygwin Library 42727 Open Zend doesn't fail with syntax error 42922 Open request for 64bit numbers in php6 43743 Open Unicode Error Mode That Throws Exceptions On Error ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir) 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[MySQL related] 44076 Open mysql_result returns nothing with blob 44082 Open mysqlnd driver doesn't connect to remote hosts ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket 42079 Open pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated) ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Scripting Engine problem]= 33487 Assigned Memory allocated for objects created in object methods is not released 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe 43408 Assigned get_called_class not working as expected
Re: [PHP-DEV] [RFC] Conditional INI support
On 16.02.2008, at 11:05, Marcus Boerger wrote: Hello Steph, so here's my take on the matters. For 5.4 we collect ideas and implement them. So that 5.4 comes out with mostly PECL. I guess we can collect action items on Lukas' wiki. Well maybe we should target this stuff for PHP6 for the time being. A possible PHP 5.4 would then be a collection of PHP6 todo items that we want to fast track, or are you guys already certain about PHP 5.4? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP mail() header patch for SafeMode
Hi All, I'm working for an hosting company, we have a lot of PHP users and see regularly that one of the scripts from our users is hacked. Result?, a lot of spam on the net, and a lot of work the find the spamming scripts on the servers. If you have a PHP script that sends mail, the recipient of the mail message will only see which server it was sent from. There will normally be no record of who originated the message, or which script on the server actually caused it to be sent. This can make it difficult to trace misuse, even if you have comprehensive mail and webserver logs. I think it should be usefull to add the PHP mail() header patch from Steve Bennett in safemode by default. The header could be in the form: X-PHP-Script: servernamephp-self for remote-addr For example: X-PHP-Script: www.example.com/~user/testapp/send-mail.php for 10.0.0.1 The patch can be found at: http://www.lancs.ac.uk/~steveb/patches/php-mail-header-patch/ Best Regards, Paul van Brouwershaven -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP mail() header patch for SafeMode
Hey, Paul van Brouwershaven wrote: I think it should be usefull to add the PHP mail() header patch from Steve Bennett in safemode by default. I wonder how this would go along with: http://www.php.net/~derick/meeting-notes.html#safe-mode I don't know if this still applies, it's from 2005 ... - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP mail() header patch for SafeMode
Hi Paul, Am Montag, den 18.02.2008, 12:06 +0100 schrieb Paul van Brouwershaven: [...] I think it should be usefull to add the PHP mail() header patch from Steve Bennett in safemode by default. As safemode is going to be (finally!) removed in PHP 6, I would propose not to make this dependent on safe-mode. I would rather allow this feature to be enabled separetely in the php.ini. Something like mail.extra_log_header (not the perfect name, I know) would work. [...] cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] PHP mail() header patch for SafeMode
2008/2/18, Paul van Brouwershaven [EMAIL PROTECTED]: Enabling it from the php.ini would also be a good option, the main point is to get some help with tracking the spam source in a shared hosted environment. IIRC Ilia had a better patch for this, I dont know why it hasnt been merged into PHP core. -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP mail() header patch for SafeMode
Lukas Kahwe Smith wrote: Are you aware of the following: http://ilia.ws/archives/149-mail-logging-for-PHP.html The idea is the same, but why is this not in the core? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP mail() header patch for SafeMode
On 18.02.2008, at 15:04, Paul van Brouwershaven wrote: Hi Lars Markus, Lars Strojny wrote: As safemode is going to be (finally!) removed in PHP 6, I would propose not to make this dependent on safe-mode. I would rather allow this feature to be enabled separetely in the php.ini. Something like mail.extra_log_header (not the perfect name, I know) would work. [...] Enabling it from the php.ini would also be a good option, the main point is to get some help with tracking the spam source in a shared hosted environment. Are you aware of the following: http://ilia.ws/archives/149-mail-logging-for-PHP.html regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP mail() header patch for SafeMode
Hi Lars Markus, Lars Strojny wrote: As safemode is going to be (finally!) removed in PHP 6, I would propose not to make this dependent on safe-mode. I would rather allow this feature to be enabled separetely in the php.ini. Something like mail.extra_log_header (not the perfect name, I know) would work. [...] Enabling it from the php.ini would also be a good option, the main point is to get some help with tracking the spam source in a shared hosted environment. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous functions
Hi All,
I second this. Can we please re-open the discussion on anonymous
functions as well as closures. That would be an awesome feature.
create_function is a bit ugly semantically to be sufficient for all
anonymous function needs.
Thanks,
Mat
KOYAMA Tetsuji wrote:
Hi lists,
Is this discussion stopping?
I want this feature in PHP. Please start to talk.
On Jan 10, 2008 7:09 PM, Ryusuke SEKIYAMA [EMAIL PROTECTED] wrote:
Hello, lists,
We have discussed about implementing anonymous functions and
closures in PHP.
However, I consider that implementing anonymous functions and
implementing lexical scopes should be discussed separately.
# Even though I like closure. ;-)
So I wrote anonymous function patch for PHP 5.3 and 6.0.
Patches (inlcude tests):
for PHP 5.3: http://www.opendogs.org/pub/php-5.3dev-080109-anon.patch
for PHP 6.0: http://www.opendogs.org/pub/php-6.0dev-080109-anon.patch
Featues:
- Unlike create_function(), there is no need to take care of
quotes, backslashes and dollars .
- Can be used in loop, but be compiled only once.
- Supports recursive call using __FUNCTION__.
- Supports inline execution. It works like a block scope.
- Works with opcode caches.
Since I couldn't build APC against PHP 5.3, I have tested
PHP 5.2.5 + anonymous function patch and APC 3.0.16.
Example:
?php
// callback
$arr = array(5, 3, 6, 0);
usort($arr, function($a, $b){ return $a - $b; });
print_r($arr); // 0, 3, 5, 6
// assign to a variable
$lambda = function(){
echo Hello, World!\n;
};
$lambda(); // Hello, World!
// inline execution
$result = function($a, $b){
return $a + $b;
}(1, 2);
var_dump($result); // int(3)
?
The anonymous function name is composed of '\0', ZEND_ANON#serial,
filename and character position.
- Leading '\0' blocks to be displayed by get_defined_functions().
- ZEND_ANON helps determine wheter the function is anonymous or not
because '' cannot be used for user-defined function name.
- Serial number and file informations make the name unique.
- char anon_key_buf[32] is long enough because
`snprintf(anon_key_buf, 32, ZEND_ANON%llu, (unsigned long
long)UINT64_MAX)'
returns 31.
Regards,
2008/1/6, Marcus Boerger [EMAIL PROTECTED]:
Hello Stanislav,
tha makesw three then already, how about we ask around again?
Ryusuke, can you please start a new '[RFC] Square brackets shortcut' thread
to collect opinions and pass along the patch for that?
I like the anonymous function patch too. It is clean and simple. Maybe you
want to start a second '[RFC] Anonymous functions' thread with that patch.
Can you also please add tests for both?
marcus
Wednesday, January 2, 2008, 7:51:06 PM, you wrote:
the square bracket array syntax patch for PHP 5.3,
http://www.opendogs.org/pub/php-5.3dev-080101-sbar.patch
I remember we discussed that already and it was rejected then (even
though myself and Andi liked it) - did the people that objected then
change their minds?
Best regards,
Marcus
--
/**
* Ryusuke SEKIYAMA
* [EMAIL PROTECTED]
*/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-
KOYAMA, Tetsuji
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hi Chris, I'd like to see pecl4win merged into pecl.php.net (adding to Steph's idea of releasing binaries on pecl.php.net), and the Windows binaries being built from their correct branch (whatever happened to this project - it seemed so close?) What happened to this idea is there's no consensus about 'the correct branch', or about the need for tagging. Several (most?) PECL packages are developed to be completely independent of the PHP release cycle; the same code will build against all current PHP versions. I think if we keep the PECL release binaries for the current stable PHP(s) on pecl.php.net and keep the development-related stuff in CVS and on the snaps boxes, it'll make life much less confusing. PECL release binaries are only tied to a branch of PHP by the version of PHP they were built against. - Steph PS Lukas, it's okay, I killed his signature ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Steph Fox wrote: Hi Lukas, Well maybe we should target this stuff for PHP6 for the time being. A possible PHP 5.4 would then be a collection of PHP6 todo items that we want to fast track, or are you guys already certain about PHP 5.4? I'm thinking 'get the mechanisms into place in 5.4, move stuff out of core in 6.0'. This sounds practical. No idea if that makes sense to everyone, but to move out of core or not isn't even an option without a good way to distribute PECL. I'd like to see pecl4win merged into pecl.php.net (adding to Steph's idea of releasing binaries on pecl.php.net), and the Windows binaries being built from their correct branch (whatever happened to this project - it seemed so close?) Chris PS Lukas, sorry for the three line signature. -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, February 6, 2008 6:39 pm, Stanislav Malyshev wrote: This topic was already discussed here but never arrived to a conclusion, so I will raise it again. The Problem: We have $_REQUEST superglobal, which is often used to abstract GET/POST requests. However, in most cases we do not want GET/POST variables to mean the same as cookie and environment variables. We can avoid that by setting variables_order to 'GP' but then we lose _SERVER and _COOKIES which still can be very much useful. We cannot also reliably use something like 'CGP' since while it won't allow cookies to override GET/POST we still have no way of not accepting cookie that has no matching GET/POST. I think this should be cleaned up so that _REQUEST behavior would conform its use case. The proposal(s): 1. One way to fix it is to create a new .ini request_order that would control just _REQUEST. 2. Other solution would be to keep variables_order but drop 'C' parsing from _REQUEST - i.e. make _REQUEST never include cookies. I don't know how many people really need cookies together with get/post in REQUEST. 3. Yet another solution would be to make superglobals independent of variables_order - i.e. _COOKIE would always exist even if variables_order doesn't have the letter. I actually don't see any reason having JIT to remove any of the superglobals - if you don't use them, with JIT you don't pay for them. And with COOKIES it's not that it would be a big cost anyway - how many cookies could you have? Of course, it'd be more substantial change which could break some apps relying on some quirks of current behavior. So, what do you think on this? I would like to see $_REQUEST be just GET | POST I also see no reason to not keep $_GET if 'G' is missing from GPC ordering, so that would be a fine second choice. Introducing yet another php.ini setting to fix this for the number of people it affects seems a bit like the old cannon for a fly solution to this naive reader. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Mon, February 18, 2008 1:27 pm, [EMAIL PROTECTED] wrote:
?php
trait ezcReflectionReturnInfo {
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
}
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
So it's just like an include for a re-used body of 'class' code.
H.
Why not just allow 'include' here instead?
:-)
Forgive me if I'm missing something subtle/complex here, but I wonder
if a Trait is really the right answer...
Yes, the ability to add/exclude specific functions from two Traits is
gone with a simple 'include'... But so is the complexity of yet
another language construct...
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
On Wed, February 6, 2008 7:20 am, Derick Rethans wrote: On Wed, 6 Feb 2008, Sam Barrow wrote: On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote: I still we should add simple static typehints (ie. just the types that we use in the manual) - and they should behave in the same way as the other type hints that we laready have. True, but we have to consider the fact that we don't have enough support on that side. This is not some election campaign were you change what you believe in just to go get followers. So no, I will not take that into consideration. There may be no argument against scalar type hint for the same reason that nobody is arguing against me being the next Release Master. Anybody with an iota of a clue knows the latter will not happen... :-) If you're going to add type hints at all, scalar is all but useless, imho. Add int and float and so on, and I can see the utility at least, even if I'm not sure it's a good idea or not. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Fantastic. Nice RFC, nice explanation, nice design - I love it.
Can I
+1
already? :)
David
Am 18.02.2008 um 20:27 schrieb [EMAIL PROTECTED] [EMAIL PROTECTED]
marr.de:
Hi,
during last six months I've studied a language construct called
Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose
here.
The following RFC deals with the questions what Traits are, how they
are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.
Thank you for your attention and I'm looking forward to hear your
comments
:)
Kind Regards
Stefan
Request for Comments: Traits for PHP
:HTML: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
... contents::
This RFC will discuss at first the motivation for Traits describing
the
rationals
and presenting a short real world use case. The main part will
describe the
concept of Traits in detail using the syntax for Traits implemented
in a
patch
which is part of this proposal. In the end, the URL of the patch and
additional resources about Traits are given.
Introduction
*Traits* is a mechanism for code reuse in single inheritance
languages such
as PHP. A Trait is intended to reduce some limitations of single
inheritance
by enabeling a developer to reuse sets of methods freely in several
independent
classes living in different class hierarchies.
The semantics of the combination of Traits and classes is defined in
a way,
which reduces complexity and avoids the typical problems associated
with
multiple
inheritance and Mixins.
They are recognized for their potential in supporting better
composition
and reuse, hence their integration in newer versions of languages
such as Perl 6, Squeak, Scala, Slate and Fortress.
Traits have also been ported to Java and C#.
Why do we need Traits?
--
Code reuse is one of the main goals that object-oriented languages
try to
achieve
with inheritance. Unfortunately, single inheritance often forces the
developer
to take a decision in favor for either code reuse *or* conceptual
clean
class
hierarchies. To achieve code reuse, methods have either to be
duplicated or
to be moved near the root of the class hierarchy, but this hampers
understandability and maintainability of code.
To circumvent this problems multiple inheritance and Mixins have been
invented.
But both of them are complex and hard to understand. PHP5
has been explicitly designed with the clean and successful model of
Java in
mind: single inheritance, but multiple interfaces. This decision has
been
taken
to avoid the known problems of for example C++.
Traits have been invented to avoid those problems, too. They enable
designer
to build
conceptually clean class hierarchies without the need to consider
code reuse
or
complexity problems, but focusing on the real problem domain and
maintainability
instead.
Traits: A Mechanism for Fine-grained Reuse
==
A Trait is a unit of reuse much like a class, but only intended to
group
functionality in a fine-grained and consistent way. It is not
possible to
instantiate a Trait on its own. It is an addition to traditional
inheritance
and enables horizontal composition of behavior.
The following code illustrates the current implementation of an
extended
version of the PHP reflection API which provides detailed access to
doc
comment
blocks.
ReflectionMethod and ReflectionFunction are classes from the
reflection API
and
have to be extended with exactly the same code. In some situations it
would be possible to add a common base class, but in this case it is
impossible, because the extended classes are not under our control,
i.e.,
they
are implemented in third party code or even in C, like it is the
case here.
::
?php
class ezcReflectionMethod extends ReflectionMethod {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
class ezcReflectionFunction extends ReflectionFunction {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
?
With Traits it is possible to refactor this redundant code out.
::
?php
trait ezcReflectionReturnInfo {
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
}
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}
class ezcReflectionFunction extends ReflectionFunction {
use ezcReflectionReturnInfo;
/* ... */
}
?
This is just a small example of what Traits are useful for.
The next sections will discuss on more advanced techniques and
describe how
the
current implementation of Traits for PHP works.
The Flattening Property
---
As already mentioned, multiple inheritance
Re: [PHP-DEV] RFC: Traits for PHP
So it's just like an include for a re-used body of 'class' code. H. Why not just allow 'include' here instead? Well, think this would be a Mixin mechanism like in Ruby. Forgive me if I'm missing something subtle/complex here, but I wonder if a Trait is really the right answer... Yes, the ability to add/exclude specific functions from two Traits is gone with a simple 'include'... But so is the complexity of yet another language construct... The problem here is that we will need a way to handle conflicts i.e. methods defined in more than one of the includes. The mixin way is to apply one include at a time. So conflicts are solved by overriding already defined methods. But this solution is not perfect at all since there exist situations where you can not find an order for the includes which provides you with the needed method implementations. Additionally you will not notice when a method in an included hierarchy will break your semantics by overriding other methods unexpectedly. The Traits way is to enable the developers to decide on such conflicts and give them the power to re-use the methods exactly needed in this special situation, instead of doing some magic/linearization to solve conflicts. Kind Regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi David, On Feb 19, 2008 12:08 AM, David Coallier [EMAIL PROTECTED] wrote: Read the proposal, read about traits, read the thesis, read the patch, then if you still don't understand, give up, and if you do understand, you can complain. If you don't understand, ask. If you still don't understand ask again. That's more the concept of RFC and open discussions. The goal of a RFC is to get comments (yes, the C in RFC means comments). Let discuss this request only now and don't begin pointless bitching session, that's counter productive. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Annotations
Hey everyone,
I have thought about a new feature for some days now. The initial plan
was to create a new keyword deprecated which should simply trigger a
warning when the right error level was set. This could have been
combined with the E_DEPRECATED level from 5.3 (maybe, otherwise
E_STRICT).
The goal was to have a possibility for PHP projects to mark some
functions, classes or methods as no longer recommend to use. The first
step would be to set this new keyword, and after some releases the
developers could remove this item. Just as it is handled in PHP itself.
I know that there is a phpDoc property for this, but when you execute
your code you'll never realize that.
I've talked to some colleagues about this feature and I was told that
e.g. Java has annotations for that. I've tried to get familiar with
this concept, and came to the following idea:
PHP would need a new syntax feature to specify them:
@deprecated public static function test( $params ) {}
With a new function, set_annotation_handler( name, callback )
developers could register there own handler for every type of needed
annotation. I would recommended to register a default handler for
deprecated, which should trigger just a simple warning.
The first parameter of the callback should contain an array which
looks similar to the one from debug_backtrace. As an addition it
should report which function/method/class contained this annotation.
Parameters should be also possible, like they are in Java. It would
allow e.g.
@deprecated('2.34') public static function test( $params ) {}
and the callback would receive the specified parameters as additional
parameters:
function my_ deprecated_handler( $annotation, $version ) {
trigger_error( 'Will be removed in version ' . $version );
}
I'm sorry, but I think this patch is a far above my possibilities for
developing a patch on my own. Maybe someone else likes the idea, and
has some time to implement it. PHP 5.3 would be really nice ;o)
Thanks for reading, feel free to give me any type of comments
Best Regards
Tobias
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] RFC: Traits for PHP
On Monday 18 February 2008, Richard Lynch wrote:
On Mon, February 18, 2008 1:27 pm, [EMAIL PROTECTED] wrote:
?php
trait ezcReflectionReturnInfo {
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
}
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
So it's just like an include for a re-used body of 'class' code.
H.
Why not just allow 'include' here instead?
:-)
Because include requires the code in question to live in another file, which I
don't always want.
It sounds interesting to me, and I can definitely see the value. I think I'd
suggest having multiple included traits override each other, however, so
that:
trait A {
function foo() { echo A; }
}
trait B {
function foo() { echo B; }
}
class C {
use A;
use B;
}
$c = new C();
$c-foo(); // prints B since that came second.
That said, the conventional OOP mechanism to get the same result would, I
think, look something like this:
interface iface {
function foo();
function bar();
}
class I implements iface {
function foo() { ... }
function bar() { ... }
}
class A implements iface {
protected $iface;
function __construct() {
$this-iface = new I();
}
function foo() { return $this-iface-foo(); }
function bar() { return $this-iface-bar(); }
}
The class/interface method takes a little more typing and an extra function
call on the stack, but otherwise what is the advantage of Traits over this
method? (Really, I'm genuinely curious.)
You also note that this mechanism has no runtime impact. That's unfortunate,
because I'd find the ability to add methods to an object at runtime
conditionally based on some other value far more useful in my work. :-)
Especially since, as above, there seems to be a way to implement this
functionality now as-is with a little more typing, yet runtime modification
is still impossible without eval() and similar scary stuff.
Vis, I'd find the following more useful in the code I write:
trait Baby {
function crawl() { ... }
}
trait Teen {
function complain() { ... }
}
class Person {
protected $age;
function __construct($age) {
$this-age = $age;
if ($this-age = 3) {
$this-addTrait('Baby');
}
if ($this-age =13 $this-age =19) {
$this-addTrait(Teen');
}
}
}
$p[1] = new Person(19);
$p[1]-complain();
$p[2] = new Person(1);
$p[2]-crawl();
foreach ($p as $person) {
if ($p instanceof Teen) {
$person-complain();
$person-parent-ground($person);
}
}
I don't know if that's technically not feasible or technically not a Trait
anymore and therefore off topic in this thread (if it is, that's fine, let me
know and I'll shut up about it g), but that strikes me as more useful than
just runtime composition.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Larry Garfield wrote: You also note that this mechanism has no runtime impact. That's unfortunate, because I'd find the ability to add methods to an object at runtime conditionally based on some other value far more useful in my work. :-) Especially since, as above, there seems to be a way to implement this functionality now as-is with a little more typing, yet runtime modification is still impossible without eval() and similar scary stuff. The idea here is that we want to be able to cache opcodes, classes and functions and optimize them out of the runtime context so the executor can skip creating classes and functions on every single request. A lot of the traffic on this list over the past couple of months seems to ignore this basic premise. Features such as autoload and runtime object manipulation incur a huge performance hit in the sense that they change something that was free before and not only add the cost of the feature itself, but it also means the object in question now can no longer be cached and has to be created on every single request. This doesn't mean we can't consider such features, but people need to also consider the performance implications. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Monday 18 February 2008, Rasmus Lerdorf wrote: Larry Garfield wrote: You also note that this mechanism has no runtime impact. That's unfortunate, because I'd find the ability to add methods to an object at runtime conditionally based on some other value far more useful in my work. :-) Especially since, as above, there seems to be a way to implement this functionality now as-is with a little more typing, yet runtime modification is still impossible without eval() and similar scary stuff. The idea here is that we want to be able to cache opcodes, classes and functions and optimize them out of the runtime context so the executor can skip creating classes and functions on every single request. A lot of the traffic on this list over the past couple of months seems to ignore this basic premise. Features such as autoload and runtime object manipulation incur a huge performance hit in the sense that they change something that was free before and not only add the cost of the feature itself, but it also means the object in question now can no longer be cached and has to be created on every single request. This doesn't mean we can't consider such features, but people need to also consider the performance implications. -Rasmus Indeed, those are a concern. That's why I thought the closure proposal from late December was so promising, because it appeared (to my non-C-coding eyes) to not have any runtime compilation, just indirect calling. It looks like Traits as described in the original post wouldn't have a runtime cost, but might (depending on the cost of building the code references) have a notable compile cost. Runtime would cost more, but could they be done in a non-terrible way? (I don't know; that's why I'm asking.) Is the lookup table for what functions exist within a class/object easy/fast to manipulate or slow? -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error messages for wrong coding
2008/2/19, Cristian Rodriguez [EMAIL PROTECTED]:
2008/2/19, Felipe Pena [EMAIL PROTECTED]:
Proposed:
- Shows error message (Fatal error, as happens with objects) for
integer and float variables.
http://felipe.ath.cx/diff/bug39915.diff
+1 , fatal error for consistency.
you need to handle offset of booleans too..
?php
$foo = true;
var_dump($foo[1]);
?
Index: Zend/zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.716.2.12.2.24.2.20
diff -u -p -r1.716.2.12.2.24.2.20 zend_execute.c
--- Zend/zend_execute.c 18 Feb 2008 12:11:47 - 1.716.2.12.2.24.2.20
+++ Zend/zend_execute.c 19 Feb 2008 04:22:41 -
@@ -1229,6 +1229,15 @@ static void zend_fetch_dimension_address
}
return;
break;
+ case IS_LONG:
+ zend_error_noreturn(E_ERROR, Cannot use
integer as array);
+ /* break intentionally missing */
+ case IS_DOUBLE:
+ zend_error_noreturn(E_ERROR, Cannot use float
as array);
+ /* break intentionally missing */
+ case IS_BOOL:
+ zend_error_noreturn(E_ERROR, Cannot use
boolean as array);
+ /* break intentionally missing */
default:
if (result) {
--
http://www.cristianrodriguez.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
[EMAIL PROTECTED] schrieb: The following RFC deals with the questions what Traits are, how they are used, why they are usefull and how they do look like in PHP. Thank you, Stefan, for your thorough RFC. A patch implementing this new language construct is available, too. I tested an earlier version of the patch back in December when I read (and commented on) the RFC. I like the idea of Traits and your implementation for PHP and would just love to see this make its way into PHP. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Rasmus Lerdorf schrieb: The idea here is that we want to be able to cache opcodes, classes and functions and optimize them out of the runtime context so the executor can skip creating classes and functions on every single request. Thanks to their Flattening Property, there should be no notion of traits at runtime. So once the compiler has flattened a trait into a class it is just normal oparrays APC needs to deal with. At least as far as I can see. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Rasmus Lerdorf schrieb: This was in response to the suggestion that it should be extended to do runtime conditional modification of the classes. Ah, sorry. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
