Re: [PHP-DEV] Class Properties in Interfaces?
On May 6, 2008, at 12:45 PM, Marcus Boerger wrote:
public $property {
__get = getProperty;
__set = setProperty;
}
string public function getProperty() {
return $this->_property;
}
string protected function setProperty(string $value) {}
Hi Marcus,
I prefer this approach.
One advantage is that it is compatible with existing classes that have
done the getXXX() style accessors already.
One thing That I am hoping to avoid, though, is the need to declare
these kinds of basic accessor methods at all. (the ones that do
nothing but set or read a backing property.) it seems like PHP should
be able to generate them, or just fallback into a simple property
access on the backing store, if that store is specified as part of the
property.
This should be the same as the previous example replacing setProperty
and getProperty with direct references to the backing store:
protected $_property;
public $property {
__get = $_property;
__set = $_property;
}
Or do we force people to always specify
get,set,isset und unset? Or should we only enforce get/set and have
isset
and unset emulated with them (isset()~>isset(get()),
unset()~>set(NULL))?
it would be nice to have exactly this emulation for __isset and
__unset when they are not declared.
However, leaving out the __set should make the property read only and
leaving out the __get should make the property write only (less
useful, but symmetric).
Following the C# convention for declaring properties in interfaces
would declare the previous as
interface bar {
public $property {__set; __get;}
}
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
On May 6, 2008, at 12:21 PM, Lars Strojny wrote:
I think this is too unspecific. At least the visibility, setter and/or
getter and type-hint (assuming we will have type hints) should be
defined. Otherwise defining properties in interfaces become useless as
it does not tell somebody more except "there is a property".
interface Something
{
public $property {
string public function get();
string protected function set(string $value);
}
}
Hi Lars,
It isn't necessary to specify the visibility in an interface because
all interface members are public.
Specifying the accessor methods in an interface reveals too much of
the implementation. Properties (the kind with accessor methods) are
themselves an abstract concept. You want to be able to take an
interface definition such as:
interface foo {
public $bar; // if you prefer this to abstract $foo;
}
and implement it like this:
class DoIt implements foo {
public $bar;
}
or to implement it using setters, using your notation:
class DoIt2 implements foo {
public $foo {
public function get();
protected function set($value);
}
}
The whole point of this kind of property is that the caller is never
supposed to know if they are just accessing a object instance variable
or an accessor method. This is called the uniform access principle.
http://en.wikipedia.org/wiki/Uniform_access_principle
Here is how C# handles properties in an interface:
http://msdn.microsoft.com/en-us/library/64syzecx.aspx
"The accessor of an interface property does not have a body. Thus, the
purpose of the accessors is to indicate whether the property is read-
write, read-only, or write-only."
So, yeah, "there is a property named foo" is about all an interface
should say.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
Hi Marcus,
I think this is really specifying implementation details in an
interface:
interface Coordinate {
public $coord = __get => getCoord, __set => setCoord,
__isset => hasCoord, __unset => delCoord;
public getCoord();
public setCoord($val);
public hasCoord();
public delCoord();
}
This looks to me like the best way to handle this in interfaces:
interface Coord {
abstract $coord;
}
I think this example could be simplified if the basic accessor methods
didn't have to be explicitly declared:
class MyCoord implements Coordinate {
protected $_coord; // actual storage for $coord
public $coord = __get => $_coord, __set => setCoord,
__isset => $_coord, __unset => $coord; // Satisfies
the interface
public __construct($x, $y) {
$this->coord = array($x, $y); // calls setCoord
}
public setCoord($val) {
if (!is_array($val) || count($val) != 2
|| !is_numeric($val[0]) || !is_numeric($val[1])) {
throw new UnexpectedValueException('Array(x,y) of floats
expected');
}
$this->_coord = $val;
}
}
One thing about this syntax is that it give PHP a lot of information
to optimize the performance of property access.
Or you could do this
class MyCoord implements Coordinate {
public $coord; // satisfies interface
}
The nice thing about this kind of property is that you can switch
between these two implementations over time with out changing how
callers use the interface.
Maybe there are some things that could be done with syntax on this:
public $coord = __get => $_coord, __set => setCoord,
__isset => $_coord, __unset => $coord;
Can some standard implementation of the __isset and __unset be used to
simplify this declaration to something like this?
public $coord = __get => $_coord, __set => setCoord;
or
public $coord __get $_coord __set SetCoord;
or to cut down on the underlines...
public $coord get $_coord set SetCoord;
Additionally, with this syntax, we can allow accessors to have
differing visibility, which we cannot do with virtual properties:
public $coord get $_coord protected set SetCoord; // Public property
with protected setter
There are some advantages to this with inheritance, too
class Parent {
public $foo;
}
class Child extends Parent {
protected $_foo;
public $foo get $_foo set SetFoo;
function SetFoo($value) { ... }
}
In this example, a child has added an accessor method to a property
defined on a parent without changing the parent. Something you cannot
do with virtual properties.
I think structural properties would be a useful feature.
Best Regards,
Jeff
On May 6, 2008, at 7:21 AM, Marcus Boerger wrote:
Hello John,
the main reason really is storage. If you allow storage in interfaces
then you get multiple inheritance with its virtual inheritance
(diamond
style inheritance) issue. That however onlly applies to plain
attributes
and not properties which are usually understood as attributes that
result
in function calls (getter & setter). That said, if PHP had
properties, PHP
could also allow peroperties in interfaces. So the actual question
shoul
dbe why we do not support properties. To give an idea how properties
could
look like:
interface Coordinate {
public $coord = __get => getCoord, __set => setCoord,
__isset => hasCoord, __unset => delCoord;
public getCoord();
public setCoord($val);
public hasCoord();
public delCoord();
}
class MyCoord implements Coordinate {
private $_coord = array(0, 0); // actual storage for $coord
public __construct($x, $y) {
$this->coord = array($x, $y); // calls setCoord
}
public getCoord() {
return $this->_coord;
}
public setCoord($val) {
if (!is_array($val) || count($val) != 2
|| !is_numeric($val[0]) || !is_numeric($val[1])) {
throw new UnexpectedValueException('Array(x,y) of floats
expected');
}
$this->_coord = $val;
}
public hasCoord() {
return isset($this->_coord[0]) || isset($this->_coord[1]);
}
public delCoord() {
$this->_coord = array(0, 0);
}
}
This tells me two things:
a) Pretty damn complex and in that kind of the opposite of PHP's
usual KISS
approach (Keep It Simple Safe).
b) Pretty sexy as it gives a hell lot of control and you can document
everything. Check out all the minor details and think of what that
would
allow.
My conclusion is that even it looks sexy, it might be a bit to
complex.
A much shorter thing to do might be:
interface Coord {
abstract $coord;
}
This would just somehow make sure the attribute $this->coord will be
accessible as a public attribute in the implementing class. The same
rules
as for methods would apply.
Derick and me discussed solutions around abstract/virtual attributes
a lot
in the passed. They were all refused however. But what we had in
mind also
was more about specifying attributes in an abstract way in classes
so that
they become documentable while being st
Re: [PHP-DEV] Class Properties in Interfaces?
On Apr 29, 2008, at 3:15 AM, Sebastian Bergmann wrote: John Carter -X (johncart - PolicyApp Ltd at Cisco) schrieb: could you explain why Interfaces can't have properties Because interfaces are implemented which makes no sense for attributes. Sebastian, This is true for the data storage representation of a property. But, when you add the possibility of getters and setters, a property becomes an abstraction. It would make sense that an interface declares abstractly that a property will be available while leaving it up to a class to implement it. Whether the implementation would be through a instance variable or through accessor methods is an implementation detail. This is known as the uniform access principle. http://en.wikipedia.org/wiki/Uniform_access_principle However, right now, we only have the virtual or "missing property" technique of defining accessors with __get and __set, rather than a structural syntax that could be used to verify interface implementations. (The structural way could also offer better reflection, better performance, differing visibility for getters and setters, etc.) Properties in interfaces make no sense now, but if we ever get a structural method of declaring getters and setters, they might make sense. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The "jump" operator
On Apr 4, 2008, at 4:18 AM, Derick Rethans wrote: http://youngbloods.org/essays/argument_for_goto.html has an IMO good example. It's java code, but it shows how goto can help you get rid of nesting hell. Hi Derick, The code in that example looks more like an argument for try ... finally to me than an argument for goto. I have yet to see a good case for goto (not break) that doesn't involve parsing or error handling, and we have exceptions already for error handling flow control. But, we don't have try ... finally (and java doesn't have goto). Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 17, 2007, at 10:30 PM, Larry Garfield wrote:
I'm assuming that making the function above GC-able would be a
herculean task
at this point, based on previous comments, but I do not actually
know myself.
Hi Larry,
Let me use a different example than yours.
function getAdder($x) {
return function ($y) {
lexical $x;
return $x + $y;
}
}
$plusFive = getAdder(5);
$plusTen = getAdder(10);
echo $plusFive(4); // 9
echo $plusTen(7); // 17
If the closure definition (and thus getAddr) returns a string
representing an anonymous function name, then there is no where to
hold the enclosing variable $x and no way to know when to free it.
Notice that in this example, we have two different enclosing contexts,
one where $x is 5 and one where $x is 10.
If we introduce a new variable type, a new kind of zval, then
internally, that variable can hold:
1) A reference to the local variables of getAddr. (here $x)
2) A reference to $this if the closure is declared in a method
3) A reference to the opcodes of the compiled anonymous function.
The opcodes for the closure would be compiled and squirreled away when
the script is compiled.
When getAddr is executed, a zval would be created that holds the
reference to the enclosing locals and a reference to the proper
opcodes. Note that $plusFive and $plusTen would hold two different
zvals, one for each invocation of getAddr, but that both would refer
to the same opcodes structure.
When a codeblock zval is executed, such as at $plusFive(4), the
enclosing context can be passed to the anonymous function function to
make the lexical $x statement bind to the proper variable.
When the zval in $plusFive reaches zero references, it can
subsequently free its references to the local variables of getAddr.
As far as I can see, no herculean garbage collection or reference
counting is required.
Adding a new kind of zval? Perhaps that's Herculean. I don't know.
I hope I've gotten my zval terminology right.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello,
Reading the prior discussion, I think either $_SCOPE['x'] or the
lexical $x syntax is fine for accessing local variables in the
enclosing scope. But closures also should also support $this and
static:: when the closure is defined in a method.
I think a solution for closures should add a new variable type. That
way, the code can compiled at compile time, while the enclosing
context (local variables plus $this for methods) can be captured at
run time in the new variable type. Also, when the closure value is
garbage collected, the references to the enclosing scope and object
instance can also be freed.
Additionally, the callback psuedo-type could be promoted to the new
type, with the string or array representation converted when
required. It wouldn't be necessary, but a callback literal along the
lines of Array() could also be added to make the conversion
unnecessary. I find the following to be easier to understand:
set_error_handler(Callback("foo"));
Than
set_error_handler("foo");
The current syntax would still work because of automatic type
conversion.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace access modifiers
Hello Ralph,
I don't think properties are the appropriate level to specify
namespace based access modifiers. I do think that a coarse-grained
access restriction on a class by class basis might be.
public class Foo {} // Default
private class Foo {}
(protected is meaningless because there is no inheritance for
namespaces.)
In principle, I like the idea of adding an access modifier for classes
to distinguish between a namespace's public interface and its private
features.
But, when do you check for access violations of class names? On use?
On new? What about esoteric things like reflection and the callback
pseudo-type? I just don't see how it could work in practice.
Best Regards,
Jeff
On Dec 12, 2007, at 6:19 PM, Ralph Schindler wrote:
Since everyone is in the "namespace" frame of mind, is there a
possibility of a "namespace" access modifier?
The way I envision this working is that if for example:
namespace Foo;
class Bar {
nsprotected $_someProperty = null;
}
(or some other equivalent grammer)
Would allow the property Foo::Bar::$_someProperty to be accessed
from any class that has implemented a class from the Foo namespace.
Reaching for straws or is this a possibility?
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] late static binding php6
Hi, May I suggest renaming get_called_class() to get_static_class() to correspond with the use of the static:: keyword for late binding. parent:: and get_parent_class() [no parameters] should also correspond when used in a static method context. My preference is that parent:: be late binding. I would also like to see an early bound __parent__ constant along the lines of __class__. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mid-term Update for Cycle Collector (Google Summer of Code Project)
David, On Jul 14, 2007, at 1:55 PM, Rasmus Lerdorf wrote: It is still extremely rare for code to have cyclic references. So while GC could prevent swapping in the case of a malicious user, or in the case of a coding mistake, I don't think the general case of typical code running under normal circumstances would consume less memory with GC enabled. This is a good point. On Jul 11, 2007, at 4:43 PM, David Wang wrote: On the whole suite of tests (which includes the Graph and Template tests), execution time with unmodified PHP was 12:03. With cycle collection, it was 12:43. Since test suites repeatedly build up and tear down data structures, it seems to me that these would be great stress tests for a garbage collector, but not very representative of the patterns of an average php application. Do you have any performance/memory usage numbers for something more typical like a WordPress index page request or some such thing? Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mid-term Update for Cycle Collector (Google Summer of Code Project)
On Jul 11, 2007, at 4:43 PM, David Wang wrote: On the Template test, maxmium memory usage with unmodified PHP was 1.5 GB with an execution time of 30 seconds. On the Template test, maxmium memory usage with gc was 67.3 MB with an execution time of 1 minute. ... As you can see, there is the classic time vs. memory trade-off. Hi David, Very interesting stuff. Is it possible that total server throughput with gc could actually be better than unmodified php by preventing swapping at some higher level of concurrent requests? Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Hi, Sorry, I'm coming to this discussion a bit late and perhaps I don't understand the all issues, but I think the scope of creating an ORM for PHP is probably too large. Let me suggest a smaller project that could lead to better ORM. PHP has several methods of serializing and unserializing objects to different formats: PHP serialization format using serialize/unserialize (with __sleep, __wakeup and the Serializable interface) PHP code using var_export and eval (with __set_state) JSON using json_encode and json_decode Partial support for DB Records using mysql_fetch_object or PDOStatement->fetchObject() Its safe to assume that other serialization formats are possible. All of these methods have to address the same issues with objects: How to handle protected and private properties? To call or bypass the constructor on unserialization? Can objects become involved with their own serialization? (such as __sleep, __wake, __set_state, and Serializable) Must objects become involved with their own serialization (such as with var_export and __set_state) or can you serialize unaware objects? Are object relationships and identity preserved? (only true for serialize/unserialize right now) How are classes loaded? (unserialize_callback_func and __autoload?) I think a more limited scope project would be to attempt to address these core object serialization issues across the multiple formats that PHP already provides in some consistent way. Of course, not every capability is possible or necessary with every format. Before implementing ORM in C, which would be relatively less flexible than a PHP implementation, perhaps it would be a good idea to profile the existing PHP ORM solutions and look for opportunities to implement key functions in C, while leaving the majority to user space. A possible example of such an opportunity might be some equivalent to extract() and compact() only for converting between arrays and object properties instead of arrays and local variables. Rather than implement a full blown ORM extension, perhaps implementing some object serialization enhancements would be a good alternative, or at least a good first step? Perhaps some user space ORM profiling would be a good way to find the second step? Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
On Dec 19, 2006, at 10:53 AM, Ilia Alshanetsky wrote: Bottom line is that does not, there are plenty of Perl application supposedly safe from XSS due to tainting while in reality are trivially exploitable via XSS due to the fact validation regex which does the un-tainting of data is sub-par. If you incorrectly untaint data, how is that worse than not knowing that there was a tainted data path in your code in the first place? The perfect is the enemy of the good. I think we can all agree that tainting can never be perfect. The question is it better than what we have now? Relying on developers to correctly sanitize data every time and every place is certainly not perfect. Even the best and smartest developers make mistakes sometimes. Isn't this one of the problems with safe mode? I think the purpose of a taint mode should be to help find existing security problems, not to try to prevent security violations as with safe mode. Giving developers a dynamic security auditing tool is not a bad thing. I think the real problem with a taint mode is the issue of false positives. It could end up being more annoying that the value it provides. But then, until its implemented, who can know? I do think that once taint mode is enabled, there should be no way to turn it off or get around it, except to untaint the data. It should be fatal. No E_TAINT. No half measures. A program should either pass the "taint audit" or not pass, but it shouldn't be able to opt out of the audit with an ini_set, an .htaccess file, or an error handler. Tainting should not be a mode you run in, it should be an (imperfect) audit that you pass or fail. A staged, conservative rollout as strictly an auditing feature might not even include an untaint or an is_tainted function. If you want to prevent ISPs from putting this in production, that would be one way to do it. Without untaint or is_tainted, tainting become strictly a debugging tool. If it turned out a bad idea, it would also be easily revokable. (Maybe is_tainted and untaint start out in PECL and the zval flag, function flags and fatal error only go into the core with an --enable configuration option?) I think that a tainting audit mode could be a useful tool, provided that the number of false positives turns out to be reasonable. Marking functions as sensitive or such is certainly useful. I cringe at the idea of another global mode to deal with, another ini setting or another error_reporting level. Regardless of whether this is included in PHP 6, I hope someone implements it. I want to run my programs with tainting and see what happens. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] display_errors = on
On Dec 16, 2006, at 11:54 AM, Derick Rethans wrote: On Fri, 15 Dec 2006, Andi Gutmans wrote: Time to turn it off in php.ini-dist in addition to php.ini-recommended? I would instead change them to php.ini-development and php.ini-production. In development you'd want to have this stuff on.. Yeah. What he said. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] display_errors = on
On Dec 15, 2006, at 7:47 PM, Andi Gutmans wrote: Time to turn it off in php.ini-dist in addition to php.ini-recommended? Time to rename php.ini-dist and a php.ini-recommended to more clearly represent specific usage profiles, like development and production? Perhaps the production or "recommended" profile should be the default php.ini installed? -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia Alshanetsky Sent: Friday, December 15, 2006 4:04 PM To: Stanislav Malyshev Cc: PHP internals Subject: Re: [PHP-DEV] Run-time taint support proposal On 15-Dec-06, at 7:01 PM, Stanislav Malyshev wrote: the harm. One simple exploit leading to information disclosure is to pass it an array() causing the function to generate an error exposing the script's path. You mean when running with display_errors = on? Ouch. Something that most servers do (almost 80% by recent stats). http://www.nexen.net/images/stories/phpinfos/display_errors.png Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED
On Nov 3, 2006, at 1:11 PM, Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are
common
which is true for PHP. Actually in PHP static methods are inherited as
any
other method (also true for a lot of other languages). Now given Liskov
rules you can as well add default parameter values as add new
parameters
with default values and even change type hints (when respecting the
rules
correctly). With C++ the first language has proven that changing
default
parameter values is a bad idea. There however mainly because they are
bound
at compile time based on the compile time types, which results in
default
values that are mostly not what you would expect. In PHP it might work
as
expected but then all programmers that come from langiages like C++ get
confused. Also it would disallow a few optimizer things later (going
the C++
way of compile time function invocatoin binding). The same holds for
new
additional parameters. In most languages that is no option because it
would
effectively be a different function. In PHP it would eventually work
but add
more confusion that it would help. The last point, changing type hints
in
derived class' methods, was discussed at PDM and declined. The main
reason
for that decision were that all languages we knew of do not support it
and
that most people even do not understand the rules which are quite the
opposite of what most people think.
Hi Marcus,
Enlightening explanation in a long and confusing thread.
To restate the last point for clarification, if the PHP's rules were
following Liskov's rules, this
php -d"error_reporting=8191" -r 'class Foo {} class FooBar extends Foo
{} class T {function f(FooBar $x){}} class S extends T {function f(Foo
$x){}}'
and possibly
php -d"error_reporting=8191" -r 'class T {function f(StdClass $x){}}
class S extends T {function f($x){}}'
would not be E_STRICT violations as they currently are. In both
examples the subclass weakens the parent classes' preconditions (type
hints). So PHP's E_STRICT rules are (intentionally) 'stricter' than
Liskov's rules.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
On Aug 4, 2006, at 3:23 AM, Derick Rethans wrote: - Add a new flag to methods (at the implementation level) that will allow to flag them as 'strict' Hello, Would exposing this flag to the user at method level get a bit verbose for those who want to use it? Perhaps a class level flag for all methods? Wasn't that proposed earlier? Its a long thread to follow, forgive me if I've missed something. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Long awaited line directive
On Jul 15, 2006, at 11:29 PM, Sara Golemon wrote: One minor thought I'd offer up is an option INI setting to disable creation of the opcode. This allows the #line directives to be used in dev/debug environments without causing an impact for production servers during execution. It's not a major performance hit, but it's something. Hi Sara, Why not leave it up to the user land code generator to include the directive in the debug version or generate without it in the production version? Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT
On Jul 12, 2006, at 11:56 AM, Lukas Smith wrote: Therefore my proposal would be to simply add a defined "header" to all E_STRICT messages that contains the PHP version in which this E_STRICT message was added. Hi Lukas, An alternative might be to implement numerical error code identifiers and then allocate them sequentially. Identifying error messages introduced in future versions could be done by comparing the error code number against the last defined code in a known version. I'm not sure about the importance of the use case of identifying the version introduced, but having error codes might have other merits. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Hello Stanislav,
On May 17, 2006, at 5:25 PM, Stanislav Malyshev wrote:
JM>>individual properties, just as you can in Java, C#, Ruby, Delphi,
JM>>Python, Visual Basic, Objective C, Smalltalk, and sometimes C++.
(To
JM>>the best of my knowledge.) Read only is a special case of this
JM>>capability.
This would be, however, yet another level of complexity added to the
language...
I feel that it is __get and __set that are complicated. Which is more
complicated?
class Shape {
protected $_dimension;
function __get($name) {
switch ($name) {
case 'dimension':
return $this->_dimension;
}
}
function __set($name, $value) {
switch ($name) {
case 'dimension':
if ($value < 0) {
throw new Exception('Negative dimension.');
}
$this->_dimension = $value;
}
}
}
Or
class Shape {
protected $_dimension;
property $dimension read $_dimension write setDimension();
function setDimension($value) {
if ($value < 0) {
throw new Exception('Negative dimension.');
}
$this->_dimension = $value;
}
}
I'm just using the Delphi syntax here because its what I know. I don't
want to get hung up on exact syntax. Split visibility for simple
properties could be implemented with the same syntax:
property $foo public read protected write;
In many ways I feel this is more understandable than readonly/readable.
In this syntax, visibility could be in any of three places:
[ visibility ] property $name [ visibility ] read [source]
[[visibility] write [source]];
The visibility declaration for the accessor overrides the visibility
for the property.
JM>>2. __get/__set is slow. (In the best case: about 10x slower than
simple
JM>>property, 3x slower than an accessor method call)
Slow as opposed to calling different function for different properties,
adding additional lookups on each access?
Lets look at the performance cases.
Current property performance in relative units:
100% : $obj->foo;
385% : function getFoo() { return $this->_foo; }
1050% : function __get($name) { switch ($name) { case 'foo': return
$this->_foo;}} // first case is best case scenario
property $foo public read protected write;
I presume this could be written to perform the same as any simple
property access?
property $foo read getFoo() write setFoo();
property $foo read getFoo() protected write setFoo();
No $name parameter. No switch. No guard?
I presume this would perform the same as a method call plus a property
access, 100%+385% = 485%?
Yes, this might be 5 times slower than a simple property, but when you
have to call a function, you have to call a function. It might still
be twice as fast as __get.
public property $foo read $_foo write setFoo();
If this could be implemented by aliasing $foo to $_foo, it would
probably be about the same as two property accesses? Half the speed of
a simple property access, but five times faster than the best case
scenario with __get?
While something like this may be complicated to implement internally
(zend_property_info gets more fields), I fail to see the downside from
the user's perspective. Less code. Faster code. Explicit declaration
instead of magic. Autocompletion, PHPDoc & doc comments work.
Reflection works.
I just think that split read/write visibility should be implemented as
part of a more comprehensive property solution, or at the very least in
a way that a more comprehensive solution could be implemented later.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
On May 16, 2006, at 7:28 PM, D. Dante Lorenso wrote:
I'm not familiar with this OOP concept from any other language.
Perhaps it exists, but if it doesn't, is there a reason why?
Hello,
Its hard to find a major OO language that does not have
property/accessor method support.
C#:
private int x;
public int X { get { return x; } set { x = value; } }
Ruby:
def name, def name=(x) syntax plus attr_reader, attr_writer shortcuts
http://www.rubycentral.com/book/tut_classes.html
Delphi:
Property Name : Type read Getter write Setter;
Python:
I'm not very familiar with python, but it appears to have accessor
method support:
http://www.python.org/download/releases/2.2.3/descrintro/#property
Visual Basic:
Public Property Name() As String
Get
Return NameValue
End Get
Set(ByVal Value As String)
NameValue = Value
End Set
End Property
Objective C:
Key Value Coding
http://developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueCoding/KeyValueCoding.html
Smalltalk:
name
^name
name: aValue
name := aValue
Java:
Java doesn't have a specific language syntax, but it does have a
standard for declaring accessor methods.
http://java.sun.com/products/javabeans/docs/spec.html
C++:
I'm not very familiar with C++ and I don't know what is standard, but
tool builders such as Microsoft and Borland have had to add their own
property syntax to C++.
PHP:
PHP doesn't really have accessor method support. __get and __set are
property missing handlers, not accessor methods. This leads to several
problems:
1. __get/__set are too cumbersome for simple use cases. (Hence this
thread)
2. __get/__set is slow. (In the best case: about 10x slower than
simple property, 3x slower than an accessor method call)
3. properties defined with __get/__set can only be public
4. Reflection does not work with __get/__set
5. Source code analysis does not work with __get/__set (no phpdoc,
annotations, auto completion, etc.)
6. No support for static properties via __get/__set
7. __get/__set is error prone. Mistakenly creating a simple property
of the same name disables the magic methods.
8. Some obscure design problems with inheritance not worth going into
here.
The Pandora's box of complexity was opened when PHP got __get and
__set. readonly or readable is just a bandaid that fixes one use case
of one problem, but does it in a way that doesn't help fix any of the
other problems in the future.
There is nothing wrong with simple properties in PHP just the way they
are now. There is also nothing wrong with __get or __set. They work
well when you truly need virtual properties, such as for an active
record or a proxy class.
What PHP is missing is a way to associate individual accessor methods
with individual properties, just as you can in Java, C#, Ruby, Delphi,
Python, Visual Basic, Objective C, Smalltalk, and sometimes C++. (To
the best of my knowledge.) Read only is a special case of this
capability.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: private, protected, readonly, public
On May 13, 2006, at 7:18 PM, Marcus Boerger wrote:
hehe, maybe confused with delphi or borlands c++ additons? Speaking
of
which before we add 'readonly' we should go for full property support
but
on the other hand that might be a little bit too much until php is used
with code generators and gui designers where code inspectors execute
and
manipulate source/code while developing.
Hi Marcus,
Full property support is high on my wishlist for 6.0. I was a Delphi
programmer for 5 years and miss properties. C#, Ruby, and Java all
have built in property support with accessor methods, or at least a
single standard implementation that all the tools can get behind.
__get and __set leave you in complete limbo for both source code and
reflection based tools. I think the language support has to come
before the tools.
I think this can be implemented by adding a getter and setter field to
zend_property_info, then checking for it in zend_std_read_property,
etc. Although, I'm sure there's more to it than that. Such an
implementation would probably be 3 to 4 times faster than __get(). No
switch, no $name parameter, perhaps no guard logic. Checking for a
getter or setter in zend_property_info would be a fast boolean test on
a data structure thats already available, so I believe there would be
little overhead.
Here are a few use cases and syntax suggestions...
A. Declaring a property with accessor methods:
public $foo read getFoo write setFoo;
B. Read only property with accessor method could be declared:
public $foo read getFoo;
C. A shortcut notation could automatically generate the accessor method
based on another property:
public $foo read $_foo;
// internally generated method ala C# property implementation:
// public function __get_foo() { return $this->$_foo; }
D. Similar to read only, you could have split visibility, for example,
a public getter and a protected setter:
public $foo read getFoo write protected setFoo; // Handy use case, not
crazy about this syntax
public function getFoo() { return $this->_foo; }
protected function setFoo($value) { $this->_foo = $value }
E. To avoid warnings, declare the internal storage, too:
public $foo read $_foo write setFoo, protected $_foo;
public $foo read $_foo, protected $_foo;// readonly
F. Properties with accessor methods cannot be directly initialized.
Their internal storage can, however:
public $foo read $_foo write setFoo, protected $_foo = 'bar';
G. calling unset() on a property with accessor methods could call the
setter with NULL.
H. calling isset() on a property with accessor methods returns FALSE if
the property does not exist, otherwise calls the getter and compares
against NULL for compatibility purposes. (?)
I. calling property_exists() on a property with accessor methods would
always return TRUE.
J. The setter and getter could be inspected via ReflectionProperty.
K. Unlike __get, subclass property definitions could override the
parent declarations:
class Foo { public $prop; }
class Bar extends Foo { public $prop read getProp write setProp; ... }
L. An abstract class need not declare the actual accessor methods, they
could be added as abstract by default:
abstract class Bar { public $foo read getFoo write setFoo; }
Just a few thoughts. I am sure there are other possibilities for the
same use cases.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: tests
On May 13, 2006, at 10:08 AM, Marcus Boerger wrote: Therefor we need more tests. Hi, I just wanted to point out that http://www.w3.org/XML/Test/ has thousands of XML test cases in a well defined format (XML, of course). They might be good for testing the XML processing portions of PHP. While there are likely a bunch of obscure cases that PHP would not pass, this test suite might help detect changes in XML processing between versions of PHP. Low hanging fruit? Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
On Mar 2, 2006, at 2:23 PM, Andi Gutmans wrote:
Do you expect significant BC breakage?
Hello Andi,
Here is an example where changing self to late binding would change
behavior:
class A {
static $a = "hello world";
static function getA() {
return self::$a;
}
}
class B extends A {
static function dosomething() {
echo self::getA();
}
}
B::dosomething();
If self becomes late binding, the location of self::$a jumps from A to
B, where it is undefined. Is kind of thing significant in the wild? I
don't know.
Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
On Mar 2, 2006, at 11:33 AM, Mike Lively wrote: Hi Mike, In regards to naming: 'static' wasn't my first choice either. In fact I was originally using 'this::' due to me misreading the notes from the PDM. Does 'this' work ok? I like that one. this:: and $this would both be late binding one for the class the other for the instance. It makes a lot of sense to me. I think it explains why self isn't late binding, too. very nice. this::method() this::$property this::constant get_this_class() (I doubt very strongly that anyone 'relies' on early binding for static functions...I could be wrong though.) But they do for static properties. Changing the meaning of self::$property would probably break some stuff. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
On Mar 1, 2006, at 9:50 PM, Andi Gutmans wrote: Yeah static is very confusing and I think it's a bad idea. I'm trying to think what a non-confusing way would be. Some ideas would be: a) using "class" e.g. class::method() b) change behavior of self:: to always be "virtual" and have people use class_name::method() Any other ideas? I think we should solve this issue but let's brainstorm and find the right way, both syntax wise and implementation wise (without breaking opcode caches). To me, the ideal solution would be to use __class__ for the early binding case and self for the late binding case. Are there any situations now where __class__ and self aren't the same class? To me __class__ and self are nearly redundant and it is the late binding that is completely missing. early: __class__::method() __class__::$property __class__::constant late: self::method() self::$property self::constant That seems very consistent to me and easy to explain. Unfortunately, the problem with making self late binding is that that there are potential BC breaks. Is that possibility on the table? I definitely think that self makes more sense as the late binding keyword, but I think that ship has sailed. Please correct me if I am wrong. I didn't like static at first, either, but it grew on me after a while. Self is already confusing. Without redefining it, any approach (including doing nothing) is going to involve a degree of confusion. Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
On Feb 23, 2006, at 5:06 PM, Mike Lively wrote: I also added a new function get_caller_class() which returns the name of the class that static:: would represent. I find get_caller_class() a bit confusing because it introduces new terminology (caller). May I suggest adding: get_self_class() // corresponds to self get_static_class() // corresponds to static This already exists: get_parent_class() // corresponds to parent What should get_class() return inside of a static method? I frankly don't care, because I would always use get_self_class() or get_static_class() so that the meaning was explicit. Thanks for the patch, I'm excited about this one. Oh, using the key word static doesn't bother me at all. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
On Mar 1, 2006, at 3:45 PM, Jeff Moore wrote:
static protected function configure($obj) {
$obj = 'A';
}
Oops. That should be $obj->iprop = 'A'.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
On Mar 1, 2006, at 9:37 AM, Dmitry Stogov wrote:
1) I would very like to see some real example where "static" is
necessary?
Some use cases for late static binding, tested using self on 5.1.2:
1. What class am I really?
class A {
static function myclass() {
return get_class();
}
}
class B extends A {}
echo A::myclass(); // A
echo B::myclass(); // also A
2. Template method pattern for static methods requires late binding:
class Common {
static function doit() {
self::header();
echo "The answer is 42";
self::footer();
}
// could be abstract
static function header() {}
static function footer() {}
}
class Html extends Common {
static function header() {
echo "\n";
}
static function footer() {
echo "\n";
}
}
echo html::doit(); // Sorry, no html
3. Accessing a static property with late binding:
class A {
static protected $statprop = 'A';
static function getStatprop() {
return self::$statprop;
}
}
class B extends A {
static protected $statprop = 'B';
}
echo A::getStatprop(); // A
echo B::getStatprop(); // Also A
4. Static properties are hard to get at for anything other than the
explicit class name:
class A {
static public $iprop = 'A';
}
$class = 'A';
echo $class::$iprop; // syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
5. A (non-working) singleton base class implementation combining
multiple late binding issues:
class Singleton {
public $iprop = NULL;
static protected $instance;
static public function getInstance() {
if (!isset(self::$instance)) {
$class = get_class();
$obj = new $class();
self::configure($obj);
self::$instance = $obj;
}
return self::$instance;
}
static protected function configure($obj) {
}
}
class A extends Singleton {
static protected $instance;
static protected function configure($obj) {
$obj = 'A';
}
}
var_dump(A::getInstance()->iprop); //NULL
This is an issue I would very much like to see resolved prior to 6.
Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_1) / zend.h zend_object_handlers.c zend_objects.c zend_reflection_api.c php-src NEWS
On Feb 27, 2006, at 12:49 PM, Mike Naberezny wrote: The code below echoes "it works" on PHP_5_1 and HEAD but raises a notice on the other branches. excellent! It seems this can be closed then? http://bugs.php.net/bug.php?id=29070 Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote for Zend Deep Stack Prevention (ZDSP)
On Feb 25, 2006, at 4:47 AM, Michael Vergoz wrote: You see function what need a prevention ? contact me [EMAIL PROTECTED] Hello, How about one that needs less prevention? Would this patch (or another like it) allow for the elimination of the current recursion guard for __get, etc? http://groups.google.com/group/mailing.www.php-dev/search? q=%22Why+not+allow+recursive+calls%22 Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplObjectStorage
On Jan 30, 2006, at 1:33 PM, Johannes Schlueter wrote: "SplObjectStorage" is some thing which stores objects, that can be read out of the name so it at least gives an idea and compared to your "SplUniqueObjectContainer" it's quite short. There are many ways to store objects. Arrays can store objects, too. What makes this class different? It's part of PHP 5.1.2. I didn't realize that. If I had, I probably wouldn't have posted in the first place. These things get in so fast and I rarely see any discussion on them. My goal in posting was to provoke some discussion before it was released. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplObjectStorage
On Jan 28, 2006, at 4:08 PM, Kevin Waterson wrote: To give SplObjectStorage a better name. My best suggestion is SplUniqueObjectContainer. There may be a better choice. Why not just call it Betty. Why not? "Betty" is only slightly more vague than "Storage." A vague name is nobody's friend. Here is a sitepoint thread where a use of SplObjectStorage is discussed. http://www.sitepoint.com/forums/showthread.php?t=339769 I'm just trying to point out that the class may have a broader use than the context in which it was conceived and that the name could better reflect its function. AFAIK, SplObjectStorage is targeted for PHP 6. I'm not suggesting changing something that has been in PHP for half a decade. Is this not the appropriate time and place to give feedback about API design issues? Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplObjectStorage
On Jan 27, 2006, at 10:26 PM, Marcus Boerger wrote: what the hell do you want? To give SplObjectStorage a better name. My best suggestion is SplUniqueObjectContainer. There may be a better choice. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplObjectStorage
Hi, Marcus, On Jan 27, 2006, at 1:10 PM, Marcus Boerger wrote: yes, it is a conainer and not a set. So why not call it a container instead of storage? And it cannot take anything other than php objects. That's why. SplObjectContainer? But, then, it has that uniqueness constraint. The SplObjectStorage name doesn't convey that idea at all. SplUniqueObjectContainer? From an API standpoint (rather than an implementation standpoint), I don't understand the need for the object only constraint in PHP. SplUniqueZvalContainer? SplUniqueValueContainer? SplUniqueMemberContainer? Yours, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SplObjectStorage
SplObjectStorage: "This container allows to store objects uniquly without the need to compare them one by one." Unless I'm mistaken, in Java and Mathematics, this is called a Set. "A collection that contains no duplicate elements." Is there some reason not to name the class for the general concept? Is there a reason to limit this class to object members? Best Regards, Jeff Moore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JSON inclusion in core
On Jan 21, 2006, at 11:05 AM, Lukas Smith wrote: Maybe we should try to come up with a common approach here for unserialize() as well? Along with mysql_fetch_object and its cousins? I haven't yet looked at the __set_state magic method from var_export, but isn't another side of the same coin? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] not found: libxml/parser.h
On Jan 7, 2006, at 11:54 PM, Steph Fox wrote: Jani's right. If the OS is missing a file, how's that a PHP issue? Its not, except where people assume their os is fine and think its a problem with PHP. I was wrong in my previous message. Its xmlsave.h that is missing, not parser.h. I have no idea why xmlsave.h is missing, as its in the 2.6.16 version available from www.xmlsoft.org and its also in the version available with Darwin. Anyway, this bug: http://bugs.php.net/bug.php?id=34844 is marked "no feedback" and can be marked Closed or Bogus, if you would prefer. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] not found: libxml/parser.h
Which is also true of OS X 10.3.9: http://bugs.php.net/bug.php?id=34844 Compiling PHP > 5.1 on 10.3.9 requires installing libxml because of a missing parser.h in the version provided by the OS. On Jan 6, 2006, at 4:22 PM, Jani Taskinen wrote: This file is supposed to be wherever libxml headers are installed. It means your libxml2 installation is borked. On Fri, 6 Jan 2006, Gottfried Darmann wrote: Build php 5.1.1 for win32 Several files include libxml/parser.h which is not there (in ext/libxml) This file is also not available in the latest version of libxml2 (gnome). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] supported OS/platforms
On Dec 18, 2005, at 2:12 PM, Lukas Smith wrote: Especially with the emergence of the gcov setup [5][6] we also have a nice setup to make the testing automated with pretty reports and even visual gadgets. very nice! Are there instructions anywhere for creating this report locally? Such as http://qa.php.net/running-tests.php What is the process for submitting new tests to the test suite? Best Regards, Jeff Moore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Reference of $this in 5.1
I'm running into a BC break between 5.1 and 5.0 & 4.x. It seems like some code in 5.1 to prevent re-assigning $this also prevents taking a reference of $this. The following bug report for this situation was marked Bogus: http://bugs.php.net/bug.php?id=34358 However, I would like to ask for an explanation of why $this->ref =& $this is a valid usage while $ref =& $this; is not. Thanks, Jeff Moore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Subject and Observer Interfaces
On Sep 13, 2005, at 1:37 AM, Marcus Boerger wrote: there is no way in implementing multi-whatever observer and subjects typesafe. Java does it. (However, I am most definitely NOT suggesting emulating java's solution in php.) The other thing you mentioned, sending information along, is not necessary because you have access for what you really need, at least you can give the access yourself by your design and i strongly encourage you do so. Implementation note 6 in the patterns book talks about this, labeling the two styles push and pull. Push is common, too. (for example in PRADO and PEAR.) This interface mandates pull. I'm just suggesting that this particular design for Subject and Observer is not generic. There is more to the observer pattern than these interfaces express. What is the value of defining a standard interface if it can only be used in a fraction of the common cases and impedes extension? I think that if Subject and Observer go into 5.1 as they are now, two or more of the following will happen: Most people won't be able to use them. Many people will waste time trying to use them before finding the limitations. They will have to be extended later in a way that breaks backward compatibility to get around those limitations. A parallel, more capable, more mechanism will be developed and added later. They will have to be deprecated in a future release. Is there a pressing need to have this in 5.1? Why not wait to a later release and address some of the things that people commonly want to do with the observer pattern: Additional notification information (push style). A observer that can receive more than one kind of notification. A subject that can send more than one kind of notification. Regards, Jeff Moore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Subject and Observer Interfaces
On Sep 13, 2005, at 1:35 AM, Sebastian Bergmann wrote: You can extend the interfaces ... and adapt them to your needs while retaining the possibility to use them with other code that only knows about the original Subject and Observer interfaces. Actually you can't and still be typesafe. If I extend Observer and add a changed() method, I cannot pass that new object to a standard Subject interface because that interface has no business calling the changed() method since its not on the base Observer interface that it specified. There are other problems. The two interfaces are tightly coupled and extensions are not interoperable and thats why I think they aren't generic enough to be a standard base class in PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Subject and Observer Interfaces
Would it be possible to remove the Subject and Observer interfaces or at least delay them until a later release? The problem with the Observer interface is that any class implementing it is only capable of receiving one kind of notification (update) and there is no capability to send any additional information. The problem with the Subject interface is that it can also only support one kind of observer. Together these are harsh restrictions that would limit the use of these interfaces to only the most trivial applications. These interfaces are fine as a textbook example of the observer pattern, but I don't see them as generally useful enough to have as part of the language. Regards, Jeff Moore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property Overloading RFC
On Aug 26, 2005, at 5:55 AM, Derick Rethans wrote: I'm just arguing that the current way that setters and getters are implemented is broken. Instead of keeping a broken behavior I would like to see it fixed. Derick, It is not broken its incomplete. PHP doesn't really have an implementation of getters and setters. The __get and __set are really just "property not defined" hooks, not getters and setters (accessor methods). If you take a look at a dynamic language that does does define a standard for getters and setters, Key Value Coding in Objective C, you will see what I mean. KVC defines a (complicated) search path for looking up a property: 1. Search the receiver’s class for an accessor method whose name matches the pattern -get, -, or -is, in that order. 2. If no accessor is found, and the receiver’s class method accessInstanceVariablesDirectly returns YES, the receiver is searched for an instance variable whose name matches the pattern _, _is, , or is, in that order. 3. If no appropriate accessor or instance variable is found, valueForUndefinedKey: is invoked for the receiver, and the value is returned. ObjectiveC's valueForUndefinedKey is the same as PHP's __get. What php lacks is the stage in the process that looks for accessor methods. In current PHP: 1. Search the object for an instance variable 2. If no instance variable is found, __get is invoked on the object and the value returned. I think where you are running into trouble with the property keyword is that it is targeting the wrong stage in the property name search process. It simply does not make sense to declare properties in the class for the "undefined property" (__get) stage of the search process. Right now, most people simulate accessor methods in user space using __get and __set and if statements, case statements, introspection, arrays, or a variety of other techniques. If you want to improve this process and bring it into the engine, then the place to do it is the property name search path. This is where declared properties with accessor methods should be handled. An accessor method check could be added either before or after the check for the instance variable. A new keyword isn't necessary here, a simple naming convention could suffice as in ObjectiveC. Reflection could be made aware of the naming conventions, etc. However, adding the stage before, as in ObjectiveC, seems unlikely to gain much support here because of potential BC issues with method names and performance concerns. (Although, some things will become faster, some things will become slower.) Adding the stage after also seems unlikely to gain much support here because it can be simulated fairly well right now in user space using the current __get mechanisms. (Which is exactly what we do on the WACT project.) I happen to think that a PHP standard for accessor methods would be a good thing, but adding a stage to the search path is a hard sell. Without adding a stage to the search path for property names, a property keyword such as proposed makes little sense, the current mechanisms are sufficient. I understand the problem you're trying to solve, support the need for a solution, but don't think this proposal solves the problem. Ref: http://developer.apple.com/documentation/Cocoa/Conceptual/ KeyValueCoding/index.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property Overloading RFC
On Aug 25, 2005, at 8:01 AM, Derick Rethans wrote: On Tue, 2 Aug 2005, Derick Rethans wrote: I updated the proposal: http://files.derickrethans.nl/property_overloading.html #1) It seems to me that after declaring the property with the property keyword, the property isn't so virtual anymore. #2) I think this is a good idea, but aren't double underline methods reserved for those called by PHP itself. The example shows the user calling __have_prop(). Under what circumstances would php call __have_prop()? #3) I would rather see an exception based mechanism for this, but I'll concede that as unlikely, so i'll just suggest using the standard PHP boolean values. The proposal implies TRUE & NULL would be the same, which seems inconsistent. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property Overloading RFC
On Aug 2, 2005, at 9:05 AM, Derick Rethans wrote:
Problems:
1. There is no way to document the 'virtual' properties with any of
the existing
documentation tools (such as phpdoc and doxygen)
This sounds like a tool problem, not a language problem.
2. There is no way how the magic methods know if a specific 'virtual'
property
exists or not as those properties are not declared usually - unless
you
define an array with property names as a class constant (which is
not
allowed either).
Sometimes you just want to know if a single property exists and
sometimes you want to know all the properties. There are cases where
generating the full list of properties may be overly expensive (ORM
with inheritance).
__has_property($name)
__get_property_list()
Note that some properties may be read only and some might be write
only, so perhaps incorporating intended use into the API:
__has_readable_property($name)
__has_writable_property($name)
__get_readable_properties()
__get_writable_properties();
3. There is no way for the magic methods to return a meaningfull error
when a
property doesn't "exist". Of course it is possible to throw an
error with
"trigger_error" or "throw" in case a property doesn't "exist" in a
specific
class, but the file and line numbers would not match the actually
get/set
action. debug_backtrace() can be used to retrieve the correct file
and line,
but as you have to do this for every class where you want to use
setters and
getters *and* you have to implement your own error message rendering
function this is not really a suitable option either.
I would rather see exceptions used instead of changing the established
method signature of __get and __set. What about defining a standard
PropertyNotFound exception?
While on the topic, a little wishlisting. i would like to see an
accessor method search path, much like Objective C's KeyValueCoding:
http://developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueCoding/index.html
so, this defines a read only virtual property:
class Square {
function __get_area() {
return $this->width*$this->length;
}
}
echo $sq->area;
in this case, PHP would look for a __get_XXX method before calling the
__get as a last resort fallback. I'm not attached to this particular
syntax, but I think the KVC concept with an accessor method naming
convention has proven worthwhile in Objective C. KVC also has some
interesting advanced features such as indexed properties, paths, change
notification, and constraint enforcement. KVC is worth emulating.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 12, 2005, at 1:48 PM, Rasmus Lerdorf wrote: 4. Include an opcode cache by default. A lot of work has gone into pecl/apc recently, but I am not hung up on which one goes in. This is a sweet carrot to drive adoption despite a few minor BC issues. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __autoload() enhancement
On Apr 3, 2005, at 6:05 AM, Zeev Suraski wrote:
What I'd like to suggest is a change in the behavior of __autoload(),
so that multiple __autoload()'s could be defined. Essentially,
declaring __autoload() would in fact add the function to the list of
functions that are called in case a missing class is referenced.
However, it will not actually place a function named __autoload() in
the PHP function table. That way, it would be possible to declare
multiple __autoloads(), and have all of them called when a missing
class is spotted.
Coupled with namespaces, declaring multiple __autoload functions seems
natural:
namespace x {
function __autoload() {
}
...
}
namespace y {
function __autoload() {
}
...
}
Absent namespaces, the symbol table manipulation seems a bit magical to
me.
Just brainstorming here, but why not an __autoload for functions?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: par/phar/jar (was zend_stream_fixup)
On Mar 15, 2005, at 7:41 PM, cshmoove wrote:
read my reply to Christian. as i mentioned, i'm working on another
project which already has infrastucture for dealing with similar
issues. i simply noticed that it could be adapted for the PAR/PHAR
idea. IOW, the extension will be written whether or not we do the
implement web archives.
BTW, i gave your blog only a cursory glance, so i can't comment in
depth. however, i will say that the format addresses your issue of not
having to unpack. the file is memory mapped and cached, so all
resources are available without file operations beyond the initial
open resource types are string, int, arrays (numerically indexed),
tables (hashes of any other type), utf16 string and binary (arbitrary
sized). resource fallback is standard (eg. /path/to/resource/en_US/ ->
/path/to/resource/en/ -> root )
What I was trying to suggest was that this was really two things. One
is an extension that would present a tar file as a file system:
require_once 'tar::///path/myresources.tar/path/index.php';
or
require_once 'tgz::///path/myresources.tgz/path/index.php';
The extension could, of course, cache the tar file in memory and build
some internal data structures to optimize multiple accesses into the
file. I think this would be a good general addition to the standard
PHP distribution.
This combined with the HALT patch would be a killer combination for
distributing PHP applications in one file without unpacking.
Then, on top of this tar layer would come the higher level resource
location API. The API wouldn't care if its base files were located in
an archive or on the native file system, or in another kind of stream
wrapper.
if the tar extension's implementation of
file_exists('tar:://path/to/resource/en_US/resourcename') is fast
enough, couldn't the resource location layer even be native PHP?
The reason I suggested the OS X Bundle system was because it implements
its resource location capability with xml metadata (info.plist) on top
of a plain file system and I thought it might lend itself to such a
division of labor.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: par/phar/jar (was zend_stream_fixup)
On Mar 10, 2005, at 9:59 PM, l0t3k wrote: In about a month or so, i'll start work on an extension implementing a file format which allows for bundling all resources related to a app (including PHP source, localized strings, gifs, byte-code from BCompiler etc). the format has an heirarchical internal structure and allows for introspection and fallback. You might consider looking at the concept of bundles from Mac OS X: http://developer.apple.com/documentation/CoreFoundation/Conceptual/ CFBundles/index.html Bundles aren't a file format, but rather a directory structure, a set of naming conventions, and an API that provides these capabilities on the standard file system. On OS X, the finder makes bundles opaque to the user. In PHP, this could be done with a standard format such as tar or zip. I wrote about this some here: http://www.procata.com/blog/archives/2004/11/24/installing-web- applications/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Feb 2, 2005, at 3:53 PM, Rasmus Lerdorf wrote:
We have seen definitively that many application writers do not know
how to properly validate data. And yes, it is another ini thing to
worry about, and yes it will be painful, but I don't think we can
continue to ignore this. I also think that people who actually write
good and secure web apps in PHP won't have too many problems with
this. It will just be an additional tool they can use if it is
available. For people who don't know what they are doing or don't
care about security, it may very well break their applications, but
those applications most likely should be broken.
I absolutely agree that a problem exists. However, I am not sure that
an optional external filtering solution will solve the problem.
Especially if the option breaks too much stuff for most people to turn
it on.
On the other hand, just the existence of the option, even if rarely
used will still result in obscure bug reports and a steeper learning
curve.
I would like to be wrong.
On Feb 4, 2005, at 4:00 AM, Rasmus Lerdorf wrote:
And everyone here understands that &{ needs to be stripped or entitied
as well, right? How many non-internals folks do you think know that?
Which is why whitelists for input are better than blacklists. If a
strict global blacklist oriented filter causes the programmer to bypass
it and go for the raw input, then they are in the same boat regarding
this stuff.
Independently of the external filtering, a set of standard whitelist
oriented filtering functions would be a good idea.
There may also be some other areas where quoting requirements and
filtering requirements might be made more obvious.
For example, if you use external input inside the replacement parameter
of preg_replace, you have to quote it. However, many people don't
realize that, or that the quoting rules for the replacement parameter
are different than the quoting rules for the search pattern parameter.
A preg_replacement_quote function might highlight this issue.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Feb 1, 2005, at 5:41 PM, Rasmus Lerdorf wrote:
But the general idea is to provide an optional filter that people can
enable in their ini file. This will strip out any XSS, quotes,
braces, etc.
I hate to see more ini options. They make it more difficult to write
programs that work under a variety of configurations and more difficult
to integrate programs written for different configurations. I would
like to less ini file variability in the wild, not more.
It seems to me like only the application knows what is valid data.
Trying to bolt on input checking to existing applications from the
outside looks like it would just break applications, perhaps in subtle
and difficult to detect ways.
One example would be that applications which display back form values
upon validation failure would be sending back modified values. This
can be disconcerting to the user. The user may not even notice that
what they typed was silently modified to be something else.
Doing this from the ini file just seems like another kind of
magic_quotes_gpc to me. I am not a fan of magic.
If ini file based filtering causes too many problems to turn on in
general, then what good is having it? If ini file based filtering
becomes too specific to an individual application, then why not just
let the application handle it? It seems like a fine line to walk.
I am wary of an ini file based input filtering.
echo filter(GET,'foo',FILTER_NUMBER);
A set of easy to use and easy to find whitelist oriented filtering and
validation functions is a great idea.
Eventually, someone is going to want to start adding parameters to
control the filtering. This would be easier with individual functions
for individual types. Also, the filters would be more useful if they
were de-coupled from the input mechanism.
What about:
echo filter_number($_GET['foo']);
echo filter_string($str); // Perhaps same thing as strip_tags with no
$allowed_tags, but white list oriented naming.
echo filter_html($str, $allowed_tags_and_attributes); // improved
strip_tags
etc.
Also perhaps something like this for registering input filters:
register_filter(GET, ALL, 'trim');
register_filter(GET, 'foo', 'filter_number');
register_filter(GET, 'bar', 'filter_html',
$allowed_tags_and_attributes);
echo $_GET['foo'];
echo $_GET['bar'];
If there had to be a ini file option, then perhaps something taint-like:
block_unfiltered_input = 1
With this option, superglobals that didn't have filters registered
would simply be NULL. An option like this has to be able to be
modified at runtime. something like:
echo $_GET['foo']; // 'bar'
ini_set('block_unfiltered_input', TRUE);
echo $_GET['foo']; // NULL
I have no idea how super globals are implemented, so I don't know if
this is even possible. These are just some additional ideas.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: pdo [was Re: [PHP-DEV] PHP 5.1 roadmap]
On Oct 25, 2004, at 8:48 AM, Lukas Smith wrote: D Kingma wrote: I just took a view at some PDO examples on the net and it looks promissing. The one thing that I would to see is that the fetch method accepts a class name as optional second parameter (when using PDO_FETCH_OBJ or PDO_FETCH_LAZY) and then returns a new instance of the given class with the given result row as properties (when defined in the class). Yes, that as on the todo at somepoint. Atleast it was on Marcus's todo list at somepoint. Another cool thing to have would be to also be able to pass an existing class instance instead of a class name. I really like that idea. You don't really need the ability to pass a class name if you have that ability: $obj = $stmt->fetch(PDO_FETCH_OBJ, new MyObject()); I imagine this would be a popular form: $obj = $stmt->fetch(PDO_FETCH_OBJ, $this); Whenever I see a method with a constant parameter like this, especially when it involves additional required parameters disguised as optional parameters, I always imagine the constant folded into the function name anyway (see http://www.sitepoint.com/forums/showpost.php?p=913525&postcount=10 ): $stmt->fetch_PDO_FETCH_OBJ($obj); I would prefer to see fetch left alone (and simple) and instead to have this added to the API: $stmt->fetchInto($obj); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
On Jul 30, 2004, at 4:33 PM, Edin Kadribasic wrote: Jeff Moore wrote: Where did the if statements go? do_stuff(), do_more_stuff(), and do_even_more_stuff() should throw exceptions rather than return boolean error indicators. Now imagine do_stuff() and friends were native PHP functions ;) You might also have installed a standard error handler to raise some kinds of php errors as exceptions. In the worst case, you would have to add the if ... throws and you would be no worse off at the lowest level.However, the caller of the enclosing pseudocode() function would not have to check for a boolean error code and so try/catch is still a net gain. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
On Jul 30, 2004, at 10:35 AM, Shaun Thomas wrote:
Paul G wrote:
function pseudocode()
{
$a=allocate_resource_z();
$b=allocate_resource_y();
$res=do_stuff();
if(!$res)
goto err_out;
$c=allocate_resource_x();
$res=do_more_stuff();
if(!$res)
goto err_out;
$d=allocate_resource_foo();
$res=do_even_more_stuff();
if(!$res)
goto err_out;
return true;
err_out:
free_resouce($a);
free_resouce($b);
if(isset($c)) free_resouce($c);
if(isset($d)) free_resouce($c);
return false;
}
While this is valid, it's not really a good example of pseudocode that
requires a goto to be efficient. You could do the same thing with
try/catch/throw:
function pseudocode()
{
$a=allocate_resource_z();
$b=allocate_resource_y();
try {
$res=do_stuff();
if(!$res)
throw SOME_ERROR;
$c=allocate_resource_x();
$res=do_more_stuff();
if(!$res)
throw SOME_ERROR;
$d=allocate_resource_foo();
$res=do_even_more_stuff();
if(!$res)
throw SOME_ERROR;
return true;
}
catch SOME_ERROR {
free_resouce($a);
free_resouce($b);
if(isset($c)) free_resouce($c);
if(isset($d)) free_resouce($c);
return false;
}
}
I would prefer to write the original code as follows:
function pseudocode() {
try {
$a = allocate_resource_z();
$b = allocate_resource_y();
$res = do_stuff();
$c = allocate_resource_x();
$res = do_more_stuff();
$d = allocate_resource_foo();
$res = do_even_more_stuff();
} catch ( Exception $e ) {
free_resouce($a);
free_resouce($b);
if(isset($c)) free_resouce($c);
if(isset($d)) free_resouce($c);
throw ($e);
}
}
Where did the if statements go? do_stuff(), do_more_stuff(), and
do_even_more_stuff() should throw exceptions rather than return boolean
error indicators. (Following the principle of raising the error as
soon as it can be detected.) This implementation of pseudocode() also
re-throws the exception, rather than use a boolean error return value.
One major benefit of exceptions is to eliminate conditional statements
as error codes "bubble up." goto does not help with this.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
On Jul 29, 2004, at 6:30 PM, Ilia Alshanetsky wrote: Here are some more programming languages you may wish to discredit for their goto support. C#, The C# goto is limited: "goto statements can transfer control within blocks and out of blocks, but never into blocks." Does the PHP goto implementation have this limitation? http://www.jaggersoft.com/csharp_standard/15.4.htm http://www.jaggersoft.com/csharp_standard/15.9.3.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance Consideration of 1 class per file
On Apr 23, 2004, at 11:37 PM, Alan Knowles wrote: PEAR is considering stipulating 1 class per file, for the packages. - one of the concerns raised is performance. While this is true for a non-cache compiled situation (where performance is less of an issue) - would anyone care to comment on the implications when using the Zend Optimizer or APC, on how significant the impact of this would be. The Mojavi framework combines 19(?) single class files into a single file to include. I benchmarked this and if I recall correctly, the combined file loaded in roughly half the time of including the individual 19 files. The timing was only for including, no actual work was performed. No cache was used. The benchmarks were done under OS X, which as has been discussed on this list before, has a particularly inefficient implementation of realpath (used in the including process). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible with that of Foo::__construct()
On Feb 26, 2004, at 1:49 AM, Andi Gutmans wrote:
You are breaking the isA relationship. We fixed this so that from now
on, people will not make such mistakes anymore (I think it's the right
way to go, so that we don't leave broken functionality around).
You can enable compatibility mode to make this work or specify a
default value (as you saw) for $bar so that you are keeping the
interface of the base class.
First Interfaces. Interfaces are a purely a type checking construct.
There is nothing you can do with interfaces in PHP 5 that you can't
already do with classes in PHP 4 except type checking. So, it makes
sense that implementing an interface obligates you to some method
signature type checking. Implementing an interface means this class
supports this contract.
interface BaseInterface1 {
function example($value = NULL);
}
class DefaultArguments1 implements BaseInterface1 {
function example($value = NULL);
}
The class implements the interface contract. This should work.
interface BaseInterface2 {
function example($value);
}
class DefaultArguments2 implements BaseInterface {
function example($value = NULL);
}
The class implements the interface contract. This should work.
interface BaseInterface3 {
function example();
}
class VariableArguments1 implements BaseInterface3 {
function example() {
if (func_num_args() <= 1) {
...
}
}
}
The class and interface signatures match, but the class has an
implementation twist in that it accepts a variable number of arguments.
This should work. The interface doesn't specify whether () means no
arguments or variable number of arguments, so one has to assume
variable number.
interface BaseInterface1 {
function example($value = NULL);
}
class VariableArguments2 implements BaseInterface1 {
function example() {
if (func_num_args() <= 1) {
...
}
}
}
This class may implement the contract, too. Its just hard to tell from
the declarations. Traditionally in PHP, declarations have not meant
much. Since interfaces are new, whether or not this works is optional.
if not, then perhaps a varargs keyword will be added in a later
version to help match the declarations.
Now constructors and interfaces...
interface BaseInterface4 {
function __construct();
}
What does it mean to "construct" an interface? Nothing. This should
be a compile time error.
Now old style constructors
interface BaseInterface4 {
function OldConstructor1();
}
class OldConstructor1 implements BaseInterface4 {
}
This is an error, too. The name of a method in the interface cannot
match the name of a class that implements it (or match the name of any
of the parent classes.) This protects the classes constructors from
becoming involved in an interface.
There is nothing wrong with the interface by iteself. There is nothing
wrong with the class by itself. They just cannot be used together.
Moving on the the class side...
Constructors aren't are really an object method, they are a class
method. As such, their signatures should not be a part of any normal
method signature checks. Here is an example:
class Shape {
function __construct() {}
}
class Polygon {
function __construct($sides) { parent::_construct(); }
}
class Rectangle {
function __construct($sides, $length, $width) {
parent::_construct($sides); }
}
class Square {
function __construct($sides, $size) { parent::_construct($sides,
$size, $size) }
}
Here each class maintains the is_a relationship with its predecessor.
However, the constructors are essentially unrelated except where
explicitly linked in the code. The signatures are not linked by the
declaration. This is correct. PHP should NOT compare the signatures of
the construction methods. This is consistent with other languages and
consistent with the idea that constructors are class methods, not
instance methods. This capability is essential.
Actually, unless I am mistaken, constructors ARE just instance methods
in PHP with a fancy naming convention.
Now moving on to the signatures of non-construction methods.
PHP implements a dynamic message passing object paradigm (ala small
talk) instead of a static type based object paradigm (ala java). This
is a good thing. The message (method name) is passed up the
inheritance tree until an object says "I can do that." Only then to
the arguments get bound and the method implementation on the object
invoked. The checking against number of arguments occurs at binding
time. This is not bad. nor is it incorrect.
PHP will never know what types are being passed, so it simulates
overloading with default arguments and variable argument functions.
On Feb 26, 2004, at 1:51 AM, Andi Gutmans wrote:
Regular inheritance has to follow the same isA rules as interfaces.
Inheritance is exactly
Re: [PHP-DEV] try/catch/FINALLY
On Wednesday, August 6, 2003, at 03:14 AM, Marcus Börger wrote:
There's absolute no need for finally:
PHP doesn't necessarily control every resources you might want to
deallocate.
mysql_query('LOCK ...');
try {
... do stuff
} finally {
mysql_query('UNLOCK...');
}
.. do more stuff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Error handling code compatible with both PHP 4 and PHP 5
I've been doing some thinking about how to write error handling code
that can run in both PHP 4 and PHP 5. Under the current situation, it
looks like you have to resort to the lowest common denominator of PHP 4
to make error handling code that works under both versions.
Here is a proposal for changing that:
1. Change built in functions to raise exceptions.
There was a thread on this. This would let you do the standard modern
error handling in PHP 5:
try {
db_connect ( 'foo' );
} catch (exception e) {
}
2. Change php 5 to convert uncaught exceptions into standard PHP 4 style
errors and pass them to the current error_handler.
uncaught exceptions raised by the built in functions would be converted
into exactly the same parameters to the error_handler that they would
have
triggered in PHP 4.
This maintains backward compatibility without requiring any
configuration parameters. Unmodified PHP 4 code running under PHP 5
would perform exactly the same as long as no try .. catch statements
were used.
This PHP 4 style code would still work the same in PHP 5 even when
db_connect raises an exception:
set_error_handler("myErrorHandler");
db_connect('foo');
3. Change the suppress errors operator (@) to also suppresses
exceptions.
This is also required for backward compatibility, so that things like
this still work the same way:
@db_connect('foo');
4. Change trigger_error to raise an exception.
This allows PHP 4 compatible code to communicate with PHP 5 code via
exceptions.
For unmodified PHP 4 code, the uncaught exception would be changed back
into a standard error_handler style error. Thus, the code would run the
same under PHP 4.
PHP 5 code could catch the exception.
A good example of this would be calling a PHP 4/PHP 5 compatible library
from either a PHP 4 or a PHP 5 program. The library can simply call
trigger_error. Any caller can then handle the error in the way that
is appropriate:
function MultiVersionCompatableLibraryFunction() {
if ($Problem) trigger_error("Message");
}
function PHP4Caller() {
set_error_handler("myErrorHandler");
MultiVersionCompatableLibraryFunction();
}
function PHP5caller() {
try {
MultiVersionCompatableLibraryFunction();
} catch (exception e) {
}
}
5. Add a call_error_handler() function
This function takes an exception as a parameter and converts it to a
valid call on a PHP 4 style error_handler.
call_error_handler($exceptionObj, $handlerName)
The second parameter would default to the current error handler.
This would be used for explicitly converting between the different error
models:
try {
...
} catch (exception e) {
call_error_handler($e);
}
This proposal is intended to give an intermediate solution for
errorhandling during the transition from PHP 4 to PHP 5. Without this,
the jump from using an error_handler to using exceptions is too harsh.
As soon as you start using exceptions, you have to abandon PHP 4. This
won't be realistic for libraries (such as smarty) that have to support
the version of PHP that people are actually using. Without the
capability to mix error models, library authors will have to delay using
exceptions until the majority of installations are using PHP 5. With the
described changes, library authors can migrate to an transitional
solution
that works with both PHP 4 and PHP 5.
Comments? Is this possible? Am I missing something?
This proposal is a bit half-baked, but I wanted to get it out as soon
as I
could.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Micro-Benchmark-Suite
On Thursday, June 26, 2003, at 04:09 AM, Sebastian Bergmann wrote: I started working on a PHP Micro-Benchmark-Suite [1] to track changes in performance between PHP releases. Great idea. I was reading this article this morning: http://www.macdevcenter.com/pub/a/mac/2003/06/24/wwdc_2003.html "Safari is the shining example of how to do it right. The engineering team made performance the most important feature, and it was measured constantly. No regression was allowed from build to build. If an engineer wanted to introduce a feature that degraded performance, then there had to find some other way to improve speed in order to keep the feature." For what its worth, I'd like to contribute some of the php benchmarks that I've put together in the past: http://www.procata.com/php/bench.tgz These benchmarks mostly test PHP parsing speed and various methods of importing/modifying large amounts of text/html data into a PHP script. A couple interesting things in here: I was mildly surprised at how long it takes php to parse raw html with no php escape tags in it. I would have thought that parsing inside quotes would be more comparable. (look at cb1 vs. qb1 - they should be equal?). Also, heredoc syntax is 5 times slower than single or double quotes. I am a little disappointed that include_once performance is so much poorer than the if...defined...include logic is was designed to replace. Also, I am using ab instead of in-script timers. Here are my results on a 300 Mhz G3 running Mac OS X & PHP 4.3.2: ce0 (empty html file)3.08 [ms] c1e (empty PHP file) 9.93 [ms] cb0 (big html) 5.14 [ms] cb1 (big html as php)22.45 [ms] cb3 (big html as shtml) 15.17 [ms] ib1 (fread) 15.75 [ms] ib2 (include) 25.40 [ms] ib3 (include_once) 25.54 [ms] ib4 (include_once twice)27.80 [ms] ib5 (get_file_contents) 15.08 [ms] ib6 (./include) 25.32 [ms] is1 (fread) 13.06 [ms] is2 (include) 13.23 [ms] qb1 (single quote syntax)31.94 [ms] qb2 (double quote syntax)32.00 [ms] qb3 (heredoc syntax) 162.22 [ms rb1 (replace_string)38.69 [ms] rb2 (php escape)26.64 [ms] rs1 (replace_string)14.25 [ms] rs2 (php escape)14.19 [ms] rb3 (keys/values rep_str) 33.98 [ms] Benchmarks marked with an "e" operate on a 0 byte file. Benchmarks marked with an "s" operate on a 366 byte file. Benchmarks marked with a "b" operate on a 35,913 byte file. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Benchmarking 4.3.2 vs 4.1.2
On Wednesday, June 4, 2003, at 12:21 PM, Rasmus Lerdorf wrote: Uh, the number of open() calls really shouldn't change. Are you sure you are comparing the same code? Yes. I am sure. And how are you testing? I attach fs_usage to the running httpd process and hit the script a single time. http://developer.apple.com/techpubs/macosx/Essentials/Performance/ PerformanceTools/fs_usage_Fi_alysis_Tool.html Here is the full trace for accessing a zero length file called control.php: (notice how each directory gets opened three times. in 4.1.2 each directory gets opened twice.) readF=3B=0x1c5 stat /Library/WebServer/Documents/rot/bench/control.php open [ 2] /Library/WebServer/Documents/rot/.htaccess open [ 2] /Library/WebServer/Documents/rot/bench/.htaccess stat stat . chdir /Library/WebServer/Documents/rot/bench openF=4 . chdir /Library/WebServer/Documents/rot/bench lstat control.php stat lstat . openF=5 .. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x68 lseek F=5 O=0x close F=5 lstat .. openF=5 ../.. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x208 lseek F=5 O=0x close F=5 lstat ../.. openF=5 ../../.. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x58 lseek F=5 O=0x close F=5 lstat ../../.. openF=5 ../../../.. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x2ac lseek F=5 O=0x close F=5 lstat ../../../.. openF=5 ../../../../.. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x218 lseek F=5 O=0x close F=5 lstat ../../../../.. fchdir F=4 close F=4 stat stat . stat lstat . openF=4 .. fstat F=4 fstatfs F=4 fstat F=4 getdirentries F=4B=0x68 lseek F=4 O=0x close F=4 lstat .. openF=4 ../.. fstat F=4 fstatfs F=4 fstat F=4 getdirentries F=4B=0x208 lseek F=4 O=0x close F=4 lstat ../.. openF=4 ../../.. fstat F=4 fstatfs F=4 fstat F=4 getdirentries F=4B=0x58 lseek F=4 O=0x close F=4 lstat ../../.. openF=4 ../../../.. fstat F=4 fstatfs F=4 fstat F=4 getdirentries F=4B=0x2ac lseek F=4 O=0x close F=4 lstat ../../../.. openF=4 ../../../../.. fstat F=4 fstatfs F=4 fstat F=4 getdirentries F=4B=0x218 lseek F=4 O=0x close F=4 lstat ../../../../.. openF=4 . chdir /Library/WebServer/Documents/rot/bench lstat control.php stat lstat . openF=5 .. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x68 lseek F=5 O=0x close F=5 lstat .. openF=5 ../.. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x208 lseek F=5 O=0x close F=5 lstat ../.. openF=5 ../../.. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x58 lseek F=5 O=0x close F=5 lstat ../../.. openF=5 ../../../.. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x2ac lseek F=5 O=0x close F=5 lstat ../../../.. openF=5 ../../../../.. fstat F=5 fstatfs F=5 fstat F=5 getdirentries F=5B=0x218 lseek F=5 O=0x close F=5 lstat ../../../../.. fchdir F=4 close F=4
[PHP-DEV] Benchmarking 4.3.2 vs 4.1.2
I remember a discussion about system calls here earlier. What is the status of that? I've been doing some tests and have found that this code runs about 2.5 times slower under 4.3.2 than it did on 4.1.2 on the same machine (running OS X): I did some tests with fs_usage to check file system calls and found that for a zero length test.php file, 4.3.2 makes the following additional calls beyond 4.1.2: 1 chdir /Library/WebServer/Documents/rot/bench 1 fchdir 12 fstat 5 fstatfs 5 getdirentries 7 lseek O=0x 1 lstat test.php 6 lstat (., .., ../.., etc. 6 open (., .., ../.., etc) 1 stat The fread example above made the following additional calls in 4.3.2 beyond 4.1.2: 2 chdir /Library/WebServer/Documents/rot/bench 2 fchdir 32 fstat 15 fstatfs 15 getdirentries 16 lseek O=0x 1 lstat file.html 1 lstat test.php 18 lstat (., .., ../.., etc.) 17 open (., .., ../.., etc) 4 stat 1 stat . some of my counts my be slightly off - I counted them by hand. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
