Re: [PHP-DEV] How deep is copy on write?
So it sounds like the general answer is that if you pass a complex array
to a function by value and mess with it, data is duplicated for every
item you modify and its direct ancestors up to the root variable but not
for the rest of the tree.
For objects, because of their pass by handle-type behavior you are
(usually) modifying the same data directly so there's no duplication.
Does that sound correct?
Related: What is the overhead of a ZVal? I'm assuming it's a fixed
number of bytes.
--Larry Garfield
On 1/19/11 11:27 AM, Gustavo Lopes wrote:
On Wed, 19 Jan 2011 14:23:49 -, Martin Scotta
martinsco...@gmail.com wrote:
What about objects?
With objects less copying occurs because the object value (zval) data is
actually just a pointer and an id that for most purposes works as a
pointer.
However, it should be said that while a copy of an array forces more
memory to be copied, the inner zvals are not actually copied. In this
snippet:
$a = array(1, 2, array(3));
$b = $a;
function separate($dummy) { }
separate($a);
the copy that occurs when you force the separation of the zval that is
shared by $a and $b ($b = $a doesn't copy the array in $a to $b, it
merely copies the zval pointer of $a to $b and increments its reference
count) is just a shallow copy of hash table and a increment of the first
level zvals' refcounts. This means the zvals that have their pointers
stored in the array $a's HashTable are not themselves copied.
Interestingly (or should I say, unfortunately), this happens even if the
inner zvals are references. See
http://php.net/manual/en/language.references.whatdo.php the part on arrays.
class Foo {
public $foo;
}
function test($o) {
$o-foo-foo-foo = 2;
}
$bar = new Foo;
$bar-foo = new Foo;
$bar-foo-foo = new Foo;
test( $bar );
This example shows no copying (in the sense of new zval allocation on
passing or assignment) at all.
---
Also... is it better to pass an object as a parameter rather than many
values?
function withValues($anInteger, $aBool, $aString) {
var_dump($anInteger, $aBool, $aString);
}
function withObject(ParamOject $o) {
var_dump( $o-theInteger(), $o-theBool(), $o-theString() );
}
It should be indifferent. In normal circumstances, there is no zval
copying at all (only the pointers of arguments' symbols are copied).
Only when you start throwing references into the mix will you start
forcing copied.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
On 12/20/10 7:53 AM, Matthew Weier O'Phinney wrote: On 2010-12-19, Stefan Marrp...@stefan-marr.de wrote: On 19 Dec 2010, at 17:22, Matthew Weier O'Phinney wrote: Exactly. I wouldn't default to public on conflicts, though -- just with the highest declared visibility (e.g., if one trait defines as private and the other as protected, protected wins). I am currently actually implementing the most restricted proposal: all differences in the property definition will lead to a fatal error. The reasoning behind this is, that the semantics of state is not predictable and all changes in the class/traits hierarchies which are incompatible should give the developer an immediate feedback, i.e., make potentially incompatible code break. That is not the most 'dynamic' of all possible solutions but seems to fit with the rest of PHP. That makes sense to me as well; having conflicting properties due to multiple traits implementing them is a good way to lead to inconsistency and difficult to test/predict code. I will agree up to a point. Dude, this will probably break is a worthwhile message to give. At the same time, though, there does need to be a way for the developer to say I know that; trust me, I know what I'm doing. Otherwise, having two traits that are supposed to operate on the same base data will become needlessly complicated with return-by-ref accessors that may also collide. E.g., if I have three traits that all operate on an internal array, and a dozen classes that use them, I do want class A to have traits 1 and 2, class B to have traits 1 and 3, etc., without needing three extra accessors lying around that serve no purpose other than to work around an unnecessary PHP restriction. (Stack calls in PHP are not free, aside from the ugly code that results in.) Perhaps if both traits use the same variable name, visibility, *and* default value then there is no error? I suspect this issue dovetails with the Traits-and-interfaces thread from earlier. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
I am fine with this approach, with 2 caveats:
- If you actually do want to make two traits use the same property, it
looks like the answer here is Either have no property and demand the
existence of an accessor that returns by reference, or you can't write
E_NOTICE-safe code. Is that true?
- When the visibility collides, should we be folding to the most
restrictive or least restrictive? I'm not sure myself; I'm more
interested in your reasoning for going for most-restrictive.
--Larry Garfield
On 12/16/10 9:25 AM, Stefan Marr wrote:
Hi:
From my point of view the right thing to do with regard to properties is
defined in the test cases below.
The rational behind providing this semantics is based on the fact that PHP
allows to define properties dynamically anyway, so there is no way around
properties.
However, there should be a way that a developer can notice that the code might
not behave as expected in the composed class.
It is true that behavior needs state to operate on, however, accessors are a
common pattern and fully supported by traits. Furthermore, traits are not
supposed to replace classes, and when a trait does more than just providing
code that is to be easily reused, then the designed should ask the question
whether that is not actually a class, which then provides the necessary
guarantees to enforce the invariances the code expects.
Thus, I would like to keep traits as a lightweight concept for code reuse.
Best regards
Stefan
--TEST--
Conflicting properties should result in a notice.
Property use is discorage for traits that are supposed to enable maintainable
code reuse. Accessor methods are the language supported idiom for this.
--FILE--
?php
error_reporting(E_ALL);
trait THello1 {
public $foo;
}
trait THello2 {
private $foo;
}
class TraitsTest {
use THello1;
use THello2;
}
var_dump(property_exists('TraitsTest', 'foo'));
?
--EXPECTF--
Notice: Trait THello1 and THello2 define the same property in the composition
of TraitsTest. This might be incompatible, to improve maintainability consider
using accessor methods instead. Class was composed in %s on line %d.
bool(true)
--TEST--
Non-conflicting properties should work just fine.
--FILE--
?php
error_reporting(E_ALL);
trait THello1 {
public $hello = hello;
}
trait THello2 {
private $world = World!;
}
class TraitsTest {
use THello1;
use THello2;
function test() {
echo $this-hello . ' ' . $this-world;
}
}
var_dump(property_exists('TraitsTest', 'hello'));
var_dump(property_exists('TraitsTest', 'world'));
$t = new TraitsTest;
$t-test();
?
--EXPECTF--
bool(true)
bool(true)
hello World!
--TEST--
Conflicting properties with different visibility modifiers should be merged
to the most restrictive modifier.
--FILE--
?php
error_reporting(E_ALL);
trait THello1 {
public $hello;
}
trait THello2 {
private $hello;
}
class TraitsTest {
use THello1;
use THello2;
}
$t = new TraitsTest;
$t-hello = foo;
?
--EXPECTF--
Fatal error: Cannot access private property TraitsTest::$foo in %s on line %d
On 11 Dec 2010, at 17:47, Stefan Marr wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a trait is to use
either abstract set/get methods or an abstract get that returns a reference to
the property in the class.
However, at the moment it is possible to define properties in a trait:
trait Foo {
private $a;
public $foo;
}
For the moment, that information is completely ignored, thus:
class Bar {
use Foo;
}
property_exists('Bar', 'a') === false
Well, and that is a rather inconsistent status-quo.
I would like to have that fixed in one or another way.
One possibility would be to forbid property definition in a trait altogether.
That reduces a bit the possibility to have wrong expectations about properties,
however, the dynamic property creation is still possible.
Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to merge
public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT notice?
Options here are a notice whenever a property is defined in a trait, or
whenever properties are silently merged.
Comments very welcome.
Thanks
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On 12/2/10 7:51 AM, Patrick ALLAERT wrote: +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. I am still firmly -1 on removing T_FUNCTION for methods. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. If people migrate to a major version of PHP 5 they should at least stop relying on PHP 4 features still valid thanks to BC consideration. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. This makes much sense! Correct me if I'm wrong, but isn't T_VAR on class members already an E_STRICT warning? I thought it was... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 12/2/10 8:42 AM, presid...@basnetworks.net wrote:
How does one get a reference to a property, if a property is just a
collection
of methods with fancy behavior? That makes properties a first class
entity,
which is an entirely different bit of brain bending.
Its the same concept as having a reference to a function, where you can
invoke the reference and it invokes the function. I say that as a
programming concept, not a PHP concept, because I am a bit fuzzy in the
function reference department of PHP.
I don't believe PHP has function references per se. It has the ability
to call functions dynamically by either:
$function = 'foo';
$function();
// or
call_user_func[_array]('foo');
(The former is faster so preferred if you have a fixed number of variables.)
Functions are not first-class entities in PHP the way they are in, say,
Javascript so you can't pass them around, nor do you have function
pointers as you do in C. (My god those are a nightmare to code...)
PHP 5.3 introduced anonymous functions/closures, which seem at first
blush to be sort of like that. However, I believe the internal
implementation is done using objects and you can mimic that behavior on
an object using an interface, so really functions still don't have a
first-class status but are emulated using objects. (I'm sure one of the
compiler people can correct me if that's not entirely accurate.)
/tangent
Actually that's subtly wrong, which is the point I'm making. :-) If
$foo-bar
is a class member, then $foo-bar['baz'] dereferences from $foo to bar,
does
an array key lookup, finds an object, dereferences to the narf class
member,
and assigns poink to that. No new variables are ever created.
If $foo-bar is accessed via __get(), then $foo-bar *returns* an array by
value; the ['bar'] index of that new array is then accessed, we find an
object
there,that gets dereferenced to narf, and we assign 'poink' to that, in the
new array.
So is the solution then to make the set method return by reference? Or
does that just create more problems?
I'm not sure. I'm just pointing out that behaves like class members
is a substantially more complex scenario than it seems at first blush,
and we need to think through the implications of that and just how
closely we can emulate properties.
My question regarding properties here would be: There are subtle and
irritating differences between class members as __get() that make the
latter
not a true replacement for the former, especially when dealing with
arrays as
I've not found a way to work around those yet. What subtle and irritating
differences between class members and properties would we introduce, and
would
they be the same subtle and irritating inconsistencies or an entirely
new set
of subtle and irritating inconsistencies to have to deal with?
I would say, try our best to resolve all of the inconsistencies, and if we
cannot, then make sure they are the same inconsistencies that __get and
__set have, to be as least confusing as possible.
- Dennis
I agree that is a good guideline to follow.
It also provides a natural answer to the isset/unset question: If you
try to isset/unset a class member that doen't exist but __get() does,
what happens? (That may not always be the right answer, but it's a
comparison we should make.)
From another reply:
The basic Idea of a property, is making a getFoo() / setFoo($value) pair
of methods look and act like a variable from the outside, and have an
easily identifiable and simple to use syntax on the inside. The reason I
originally focused so much around methods, is because properties
literally
are a pair of methods in C# (thats what they are compiled into). But PHP
is another beast, and the challenges are different. As long as the
original purpose of properties is not loss, whatever way we figure out is
best to implement them is fine with me.
The original purpose being, specifically, smarter class members,
correct? (The internal syntax to define them we can bikeshed later;
determining the external syntax and semantics has to come first.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 12/2/10 5:33 AM, Lester Caine wrote: Again you are missing the point here. CVS/SVN works nicely for managing a master code base. DVCS does not naturally support that, and this is a major area that needs to be managed by any project switching so that you CAN manage a master codebase. I used to think that; I had no idea how you had an authoritative repo when everyone had a repo. Then I actually started working with Git, and the answer became obvious: You agree on one. You agree on a particular branch in a particular repo (eg, the one hosted on kernel.org / drupal.org / php.net) is the canonical branch, possibly restrict who can push to that (or not, but I think that would help PHP by having a release manager named early who can merge micro-branches), and document it. Git doesn't technologically force an answer on you; you get to define one socially. That actually works surprisingly well in practice in a functional project. (If PHP can't come to such an agreement in practice, that's a social problem, not a tool problem.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/30/10 6:15 PM, presid...@basnetworks.net wrote: public property Hours read getHours write setHours; I actually like that, though I think we should support the whole existing semantics, i.e. get/set/isset/unset. And probably keep the names, so we don't call the same thing both read and get. This doesn't make sense. To call isset() on a property, would be to ask if the property itself exists. But once defined, a property always exists (think of methods, for example). (Sorry for sending again Stas, I forgot to reply all) - Dennis True, but if part of the intent (as noted in a previous email) is to provide a mechanism that looks to the outside world like a class member, and therefore one can switch between the two without breaking an API, then isset/unset should have some sort of useful meaning. They do for __*() magic methods and for ArrayAccess (albeit named differently), so there should be some sort of meaningful definition here. Otherwise they are only half a drop-in/break-no-API replacement for a class member. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/30/10 5:55 PM, presid...@basnetworks.net wrote:
This is a very well-written and well-thought through RFC, Dennis. Nicely
done.
Thank you!
First of all, I have generally found the Bean-style getter/setter
approach to
be a sign of poor encapsulation to begin with. You shouldn't be mucking
with
internal elements of an object in the first place, period. More details on
that here:
http://www.garfieldtech.com/blog/property-visibility
Interesting post, although I can't say I agree with your views. Your post
leaves me wondering how the user is expected to get or give data to a
class (for example, if I'm not supposed to do $customer-name or
$customer-getName(), how do I get the customers name?). Additionally, you
are forgetting the real power of properties, which is the ability to
generate a get value, and process a set value, because get/set are
methods. Properties are hardly just an indirection layer around an
underlying piece of data.
The idea of a -getName() method for retrieving a person's name is fine.
My point there is that any assumption that it corresponds to a -name
class member (as Bean definitions require) is invalid on its face. (The
context there is a lengthy ongoing debate regarding the use of public
vs. protected class members, with my basic point being that class
members are an implementation detail and if you care about them in the
first place then you have a bug. Yes, it's a deliberately stringent
position.)
What I'm seeing here is that whether properties are intended as an
indirection layer for class members (eg, a more robust __get/__set) or
not is a fuzzy question. On the one hand they are (since the goal of
the syntax is to make it irrelevant to the caller which is happening),
but on the other they're supposed to be something different that can do
all kinds of on the fly behavior.
I'm not going to say pick one! because both are valid use cases with
significant benefit, but it is a point of potential confusion in both
the discussion and eventual documentation.
Right, the property keyword ties together with the function keyword, and
the semi-colon provides no real purpose to the author. I have however
been told that the semi-colon is important from an internal perspective,
and would ease the implementation.
Another reason that the function keyword should remain mandatory, IMO.
:-) I cannot speak to the implementation details, but I do know that
the semi-colon would horribly confuse a lot of people.
In C#, get and set methods of a property are compiled down to methods, and
calls to a property are changed to calls to those methods. Therefore
their performance in C# is exactly that of a method call. This is ideal,
since properties are meant to be a replacement for the standard
getXYZ/setXYZ design pattern.
I cannot speak to the implementation potential in PHP as I have never
looked at the compiler's code.
- Which also brings up an interesting question:
class Foo {
public $a = 1;
protected $b = 2;
public property $a { get { return 3; } }
public property $b { get { return 4; } }
}
$f = new Foo();
print $f-a . PHP_EOL; // Does this print 1 or 3?
print $f-b . PHP_EOL; // Does this print 2 or 4, or error?
Both of those throw an error. Properties and variables share the same
namespace, so you cannot define a property and variable with the same
name.
Is this consistent with methods? Do those share a namespace, too? (I
don't actually recall off the top of my head.)
This is what I would imagine seeing, and would compile:
class Foo {
private $_a = 1;
protected $_b = 2;
public property $a { get { return 3; } }
public property $b { get { return 4; } }
}
As you can see, there is no conflict or confusion this way.
True, although for the record I have always detested the underscore
prefix on variables as a difficult to read hack. :-)
That's all I got for now. Once again, nice RFP but still needs some
thinking.
Of course, that is why I am harnessing your collective brains!
BRAAAINS!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/30/10 6:29 PM, presid...@basnetworks.net wrote:
That is true for PHP variables. isset is basically saying does this
variable exist, and unset is saying to get rid of it.
Because properties (as defined in my RFC) are not a variable, but rather
a
set of methods, I do not think there would be any way to unset them.
Like a method, once they are defined, you cannot get rid of them.
Therefore overloading isset and unset would not make any sense here.
This is different from the PHP Language then. You can isset() and
unset() native properties. And use __isset() and __unset() magic
methods.
A new feature should be consistent with the language definition.
Its not a matter of consistency - Properties, as a cross-language concept
are not meant to work that way. You need to think of a property as a set
of two methods that just have a pretty syntax. Methods cannot be unset,
and nor should properties be allowed to. isset() should simply tell us
whether a property with the specified name is part of the class or not.
isset() in the way you suggest would just be confusing. It would allow is
to say that a property does not exist, when in fact it does exist. This
is not logical.
Consistency with other languages must also be balanced against
consistency within PHP. Both are important.
Class members and both existing class-member-ish mechanisms (__magic and
ArrayAccess) have the concept of isset/unset. A third class-member-ish
(syntactically speaking) mechanism will be expected to have the same set
of primitives. To not have them will be a major language WTF, because
to a normal user of an object they *look* like class members, not
methods, they *taste* like class members, not methods, so they should
*act* like class members, not methods.
Basically, properties can only be considered a drop-in replacement for
class members (as you've stated, correctly, is one of the potential big
wins for them) if they fully emulate their behavior. If they do not,
then it is incorrect to say that they can be swapped in for a class
member without changing an API.
__isset() is a whole different matter, without it we would have to assume
that every possible member name either exists or does not exist. This is
because __isset can handle ANY member name.
Properties are bound to a single member name, therefore, they always
exist, unless you were to physically remove that property from the class,
which, like methods, that is not possible.
No, but it can be easily emulated.
Actually, I can even think of a concrete use case. Suppose I have an
object that acts as a facade for a remote object over SOAP, REST, or
whatever. It is using properties to represent attributes of a remote,
say, insurance account. I want to know if a beneficiary has been set on
the account. The most straightforward way to do so is
if (isset($account-beneficiary)) {
print $account-beneficiary-name;
}
If we are implementing such logic via __get(), we can do exactly that.
If we are implementing it via properties, we should still be able to.
Forcing the user to know that he needs to do it this way instead, but
only if we're using properties rather than __get():
if ($account-hasBeneficiary()) {
print $account-beneficiary-name;
}
is violating the principle of encapsulation as it means the user needs
to know which of the three forms of $account-beneficiary happens to be
in use.
Thinking about properties further, actually, there's two other (related)
considerations that always give me grief when dealing with __get:
Reference returns and complex member variables.
If I want a reference to a class member, I can very easily do this:
$foo = $bar-baz;
If -baz is accessed via __get(), then that only works if __get() is
defined as function __get($var) to start with. That's another
encapsulation break.
Similarly, the following does exactly what you'd expect with a normal
class member:
$foo-bar['baz']-narf = 'poink';
If $foo-bar is returned via __get(), though, then the above statement
executes but does not actually save anything... *unless* __get() was
defined to return by reference as above.
Details of my adventures in __get() insanity here, including performance
considerations:
http://www.garfieldtech.com/blog/magical-php-call
How would properties deal with those scenarios? (The answer may well be
it doesn't, screw off, that's way too esoteric, as it is for __get(),
but we should at least consider if it's possible to handle those
gracefully.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/29/10 11:51 AM, Jonathan Bond-Caron wrote: Right, it looks the same but the subtle difference is 'property Hours' wouldn't be registered as a class. It's just container code for get(), set() methods that would get 'compiled' into opcodes in the class TimePeriod (the property exists vs. searching for it in runtime). So you can think of it as a special 'trait' that only applies to properties. The idea behind this syntax is you can move the 'property' definition out of the class so that you can test and re-use it somewhere else (like traits). That might not be problem if you can define properties in traits (needs to be explained in the RFC): I think I'd prefer to use Traits for externally-defined properties rather than defining a new top-level construct. It's fewer moving parts and we don't need to figure out how autoloading would be affected. (Autoload would work the same way it does now for traits... whatever that is.) That would then imply we do need to be able to declare the existence of a property and whether it has get, set, or both independently of the definition, just like methods, so that we can have a proper interface/trait split for properties just as for methods. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/29/10 8:30 AM, Ángel González wrote:
What about allowing this syntax to attach the property to a variable?
For instance:
?php
class TimePeriod
{
protected $seconds;
protected $minutes;
protected $hours;
public property Seconds read $seconds write setSeconds;
public property Minutes read $seconds write setMinutes;
public property Hours read $seconds write setHours;
public function setSeconds($seconds)
{
if ($seconds= 0 $seconds 60) $this-seconds = $seconds;
}
public function setMinutes($minutes)
{
if ($minutes= 0 $minutes 60) $this-minutes = $minutes;
}
public function setHours($hours)
{
if ($hours= 0 $hours 24) $this-hours = $hours;
}
}
We only want to perform checks on write, so instead of writing the trivial
getters, the property is set to the variable itself. Child classes could
reattach it to a function if needing more control.
Another advantage here would presumably be performance. If there's no
getter defined then the engine could simply map $foo-bar to the class
member directly (which is really fast) and not to a method, so there's
no added overhead there. That still leaves the question of what happens
with name collisions, though.
... and that makes me think that someone is sure to ask about runtime
changes to the property structure sooner or later, as we keep asking
about methods (and *sort of* have figured out with binding closures to
objects, if that did actually get committed), so I'll go ahead and ask
it now. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/29/10 12:41 PM, Johannes Schlüter wrote: On Mon, 2010-11-29 at 12:18 -0600, la...@garfieldtech.com wrote: Another advantage here would presumably be performance. If there's no getter defined then the engine could simply map $foo-bar to the class member directly (which is really fast) and not to a method, so there's no added overhead there. That still leaves the question of what happens with name collisions, though. Don't kow what you mean by the engine in this case? The compiler? - no the compiler can't a) it has no idea what type $foo is b) think about inheritance etc. The executor - well there's no win possible. johannes I was referring to the compiler I guess. I don't do C so I have no idea what it's capable of. If that's not a possible performance optimization point, then blargh. I still want to keep the performance implications in mind, as this sounds like something that we'd want to use a lot but could also cost a lot more than it seems at first glance if we're not careful. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On 11/18/10 7:34 AM, guilhermebla...@gmail.com wrote: Hi Larry, For existent project examples and usage, here are 2 links of the upcoming versions of Doctrine 2 and Symfony 2: http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-mapping/en#introduction-to-docblock-annotations http://docs.symfony-reloaded.org/guides/validator.html Please understand that Roman, Benjamin, Jonathan and I wrote this Annotation parser for Doctrine, which was reused by Bernhard on Symfony. So I have clean understanding of the issue we have on hands and every single point that it is required to address. That's why I wrote the RFC. Yesterday night a couple of people joined on #php.pecl and discussed a possible new implementation. I'll write what was discussed and probably some sample code. No offense, but as I've noted before Symfony and Doctrine are very very different types of frameworks/libraries than a lot of the code out there. Much of what may make sense in a component framework doesn't make sense in a full stack framework (e.g., Drupal, which I work on) and vice versa. So while I respect that you put a lot of work into the Doctrine and Symfony implementations that does not mean you will understand every single point that it is required to address. That said, from looking at the Symfony page above it looks like it's an integrated system for providing variable-level validation. True? If that's the case, what would a before/after look like for code using annotations vs. not? As far as implementation goes, for something like this to be useful for a highly-dynamic system like Drupal we'd need to be able to add annotations/validation rules out-of-band, that is, from somewhere other than syntactically right on the variable/function/method being validated. We frequently have highly-generic objects that get used in a multitude of different ways, so we would need to be able to associate validation rules at runtime for them to work. Naturally the error messages from them would also need to be returned/thrown, not printed, so an application can take proper steps with them in its own error handling routines. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On 8/11/10 1:30 PM, Stas Malyshev wrote: Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? +1. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
The problem is that, as was pointed out, strict typing is not optional. The minute I am using one library that is built with strict typing, all of my interaction with it from my code must be strict. That means either: 1) My application needs to be strictly typed throughout (assuming I even understand the concept; really how many developers not on this list even know what a zval is?). 2) I need to build a wrapper layer around that library that handles all of the type conversion for me in context-insensitive ways (which means bugs), which could be extremely difficult if not impossible if it's a large library with a big surface area. Imagine if Zend Framework went strict typing. It would be essentially unusable for anyone who wasn't also doing strict typing everywhere. How does this benefit anyone? --Larry Garfield On 5/27/10 6:02 AM, Ilia Alshanetsky wrote: Brian, What we are talking about here is an **optional** feature for user-land function that allow the author to implement really cheap input-validation to facilitate ensuring that the correct input is supplied. Additionally it also allows for better language interrogation for auto-generation of things like SOAP WSDL and alike. On Wed, May 26, 2010 at 6:02 PM, Brian Moonbr...@moonspot.net wrote: I like the idea of type hinting a lot. (See: http://marc.info/?l=zend-engine2m=102421231114377w=2) I suggested it in 2001 when ZE2 was being designed. Somehow my idea was bastardized into only classes and arrays. Guess it was the mad OOP craze of the time. Anyhow, I would like to use it. And, as much as I appreciate Derick and Ilia's work in getting a change in, I likely won't use it. Mainly because the web is a bunch of strings. Casting data from MySQL every time I want to use it does not interest me at all. Its a number in string form, treat it like one. If you use filter, you still have to worry with casting. There is no way to always get an int back from filter regardless of the input given. Really, I am confused what the argument is about. We already decided how this should work years ago. It should work just like the code below. Having user land functions work different than built in functions is the most confusing thing you can do. Unless of course someone plans on fixing all the internal functions too. ?php error_reporting(E_ALL); $int = 1.25454; $var = substr($int, 0, 4); var_dump($var); $var = round($var, 1); var_dump($var); $arr = array(); $var = substr($arr, 0, 1); var_dump($var); $text = test; $var = round($text, 1); var_dump($var); ? $ php test.php string(4) 1.25 float(1.3) Warning: substr() expects parameter 1 to be string, array given in /Users/brianm/test.php on line 17 NULL float(0) Brian. brianlm...@php.net http://brian.moonspot.net/ -- 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] PHP 5.4 branch and trunk
On 3/19/10 10:34 AM, Eric Stewart wrote: When significant releases are 2-3 years apart, web hosts can expect to have to put in actual work every couple of years and mass-market developers can expect to have to beat their hosts over the head with a stick every few years. If significant releases are going to be every year, then it has to still be easy and safe for hosts to upgrade. Preferably it has to also make servers faster because then they have an incentive to upgrade themselves. If hosts don't upgrade, it doesn't matter what amazing new features PHP has. Most people can't use 'em. I'm not against a more planned, frequent release cycle but I want to make sure that the upgrade treadmill is kept walkable or else it won't matter that PHP has new features. I think that the hosting companies will adapt as slow as they can, so if we give more frequent releases, then they will (have to) upgrade more often. Additionaly if we release more frequently but with fewer changes, then the developers can adapt more easily, because they have to watch out for one or two change at a time, not a whole lot of changes. Being a guy who both runs a small hosting shop and spends lots of time doing development. I would greatly appreciate more frequent, but smaller releases. I just finally got 5.3 rolled out this week, and have been wanting it for months for the performance improvements in realpath, but have been hindered by the large list of things it would throw warnings about. The other side of hosting is that most of your clients don't keep on top of versions of their installed software. Even app developers don't want to go make changes to a 5 year old app just because PHP has decided that something is no longer a good practice. My guess is that I'm in the minority of hosts that want to upgrade PHP for new features. Part of that is probably driven by being a app developer for most of my job. -- -Nathan Gordon If the database server goes down and there is no code to hear it, does it really go down? esc:wqCR I guess I'm missing the point on this. We all know hosting companies are slow to adopt our changes. But does it really have anything to do with the time interval between our releases. I would think the more pressing issue would be BC which is not a function of the time interval but rather a function of actual changes implemented in a release. I don't remember any one in this thread insinuating that we'll be making diversions from the long lasting goal of maintain BC whenever it's even remotely possible. Best case scenario when only considering the time interval. We see a little better adoption if short release cycles mean a new release gets push prior to a hosting company's evaluation period for rollout changes. Worst case scenario, a perception is generated by the fact we appear to be moving ahead faster and they appear to be falling behind even faster. But I think the reality will be that we are still doing roughly the same amount of changes either way. We'll just be pushing it out in smaller chunks. Eric Lee Stewart The point is that, for instance, PHP 5.3 was not a trivial upgrade for coders or hosters. Sure it's mostly compatible, and you certainly can write code that works from 5.0-5.3 just fine, and if not then you're probably doing something wrong... but that's most of the PHP code out there right now. :-) And naturally you can't test your code against 5.3 until it's out. So things like this didn't used to throw a warning but should have all along, so now it does are BC breaks, from a hoster's point of view. If they upgrade, some of the random code they host will start throwing warnings when it didn't used to. So they don't upgrade, and Linux distros take their time (not everyone is as behind as Red Hat, but the current Ubuntu stable still ships 5.2 for instance), so devs who don't compile their own PHP can't really test on 5.3... Nastiness. That's what kept PHP 5 back for so long. I guess my point is that one rough upgrade every 3-5 years is something hosts and coders can deal with, mostly. Or one easy upgrade every 1-2 years is something hosts and coders can deal with, mostly. But a rough upgrade every 1-2 years is not something that most hosts and coders can keep up with. And the definition of rough in this context is really strict. So if non-bug releases are going to move from 3-5 years to 1-2 years, it also needs to be kept easy, not rough, which means a much tighter reign kept on BC breakage, even low-level you should be doing it this way now breakage. The long-tail of versions that mass-market projects need to support is then much longer, too, so they need to be able to write code that will run smoothly on 5.2, 5.3, 5.4, and 5.5, even if they don't use anything not in 5.2. Does that explain my concern better? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
Re: [PHP-DEV] Re: PHP 5.4 branch and trunk
On 3/19/10 1:31 PM, Nate Abele wrote: The point is that, for instance, PHP 5.3 was not a trivial upgrade for coders or hosters. Sure it's mostly compatible, and you certainly can write code that works from 5.0-5.3 just fine, and if not then you're probably doing something wrong... but that's most of the PHP code out there right now. :-) And naturally you can't test your code against 5.3 until it's out. Larry, to mitigate this issue, please refer to the exhaustive list of instructions here: http://twitter.com/nateabele/status/10733251789 PLEASE NOTE: This also applies to user-land applications with test suites (and here I'm risking showing my ignorance by blindly assuming Drupal does, in fact, have a test suite). Please see http://snaps.php.net/ and http://qa.php.net/ for more information. Thanks, - Nate Drupal 7 has an extensive test suite, using our own testing framework rather than phpt. (Let's not get into a debate about why that's the case; it's neither here nor there nor would I even be on just one side of it. g) But that's for a high-end project. It doesn't really help the code slingers that happen to have code they threw together that is holding back a hosting company who don't even know what make is. I am not saying people shouldn't be testing code. I'm saying the barrier to entry to testing common code found in the wild on a new release of PHP is higher than you seem to be assuming. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this
Richard Quadling wrote: How much of a use case is binding $this to closures (personally, I think this is quite a common usage, but I've been using JavaScript so maybe I've got the wrong head on). But, if there are significant technical/internal issues with regard to binding $this to closures, what about (and I'm expecting the usual shoot down here as I obviously know squat) NOT binding closures at all (option 0). Instead get traits working. *snip* If I recall the trait discussion properly, traits are a compile-time thing. Closure binding is a run-time thing. They are not comparable and one cannot really be used to implement the other. (Well, hypothetically bound closures could kinda-sorta replicate traits, but it would be a pretty lousy way of doing it as you get no compile-time enforcement or interface support.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
