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
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
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?
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 -
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
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
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
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
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
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.
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;
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
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
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
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
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
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
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,
18 matches
Mail list logo
