> > - i.e. name them __prop_get_xxx, __prop_set_xxx, and so on.
>
> I think it'd more natural to make it __set__PROPNAME. Though __set_state
> is a static method, so maybe we can live with it - except that you won't
> be able to declare property named $_state.
Needing an "except" is inelegant, if
Hi,
On Thu, Oct 25, 2012 at 9:59 PM, Antony Dovgal wrote:
> Just use logrotate for that.
On Windows there is no logrotate by defautl, so that would be a nice feature ;)
Cheers
Mario
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, Oct 27, 2012 at 2:17 AM, Mario Brandt wrote:
> Hi,
>
> On Thu, Oct 25, 2012 at 9:59 PM, Antony Dovgal
> wrote:
> > Just use logrotate for that.
>
> On Windows there is no logrotate by defautl, so that would be a nice
> feature ;)
>
> Cheers
> Mario
>
> --
> PHP Internals - PHP Runtime De
Hi!
>> On Windows there is no logrotate by defautl, so that would be a nice
>> feature ;)
> I agree. This would definitely be a nice feature to have, at least for the
> Windows build.
There are a number of solutions for that:
https://www.google.com/search?q=logrotate+windows
PHP doesn't have to
Hi!
> Excuse my persistence. There must be a fix for this at the PHP level
> that's palatable to you folks...
I'd suggest talking directly to PGSQL maintainers... In general, the
pull seems to be fine to me, but I'd rather have the people that
understand something in PGSQL APIs look at it :)
--
Recursion is guarded by the same mechanism __get uses to avoid recursion.
On 10/26/2012 9:33 AM, Stas Malyshev wrote:
Hi!
v1.2 Proposes that this be inverted such that if there is an accessor
defined for a given property name, the accessor will always be used. The
accessor would be able to get
That's basically what #2 is getting at, my only question is, emit a
warning or notice or not?
Technically returning false on an invalid isset() call could be
misleading without emitting some kind of notice or warning about it.
On 10/26/2012 9:56 AM, Stas Malyshev wrote:
Hi!
1. If al
On 10/26/2012 9:39 AM, Stas Malyshev wrote:
Hi!
/* Would be equivalent to this */
class TimePeriod {
public $date {
get() { return $this->date; }
set(DateTime $value) { $this->date = $value;}
}
}
I don't think this has a use case and this encourages mixing var
That's why I think they shouldn't even be visible to users, they aren't
relevant to them and in fact it could mis-lead them into thinking that
they could simply define __getHours() and expect $foo->Hours to call
it, which it wouldn't.
To me, the bottom line is, the fact that there are methods
On 10/26/2012 6:37 PM, Stas Malyshev wrote:
Hi!
Stas, if you define an accessor, how do you define it? Do you say
Either way, doesn't matter.
According to the current proposal at least you can write the first
code *and the first code only*. If you write the second code then you
That's wher
On Saturday 27 October 2012 13:05:27 Clint Priest wrote:
> That's why I think they shouldn't even be visible to users, they aren't
> relevant to them and in fact it could mis-lead them into thinking that
> they could simply define __getHours() and expect $foo->Hours to call
> it, which it wouldn't.
Hi,
thanks for bringing this up again. I digged even deeper into the whole issue of
converting floats to strings and my current findings are that we can’t solve
that consistently as things are already fubar’ed. The reason for that is, that
in order to solve this issue we would need to make ever
Hi!
> Recursion is guarded by the same mechanism __get uses to avoid recursion.
__get on recursion returns undefined, __set on recursion does nothing.
However you're saying "No direct access to the property would be allowed
except from within the accessor" - but what this not allowing means?
Just
Hi!
> That's why I think they shouldn't even be visible to users, they aren't
> relevant to them and in fact it could mis-lead them into thinking that
> they could simply define __getHours() and expect $foo->Hours to call
> it, which it wouldn't.
I think it should. That's how __get works.
--
Hi!
> What is "reflection hiding patches" referring to? Reflection is changed
> to reflect what the user has defined, that's what reflection is supposed
> to be.. no?
No. Reflection is supposed to show which methods exist on a class, which
can be called from certain context, etc. This has noth
Sorry I guess I should have been more clear. The recursion would
prevent the accessor from being called which would allow the ordinary
property code to execute, thus accessing the property directly. I
suppose if it were in a setter and the property were not defined by the
accessor then it wou
Sounds like you're implying that the mere existence of a properly named
function such as __prop_get_hours() would cause it to be called instead
of returning the property.
There are several problems with this approach:
1) Currently __get() is only checked/invoked if there is not a property
alr
Stas, you should probably do some research before posting such non-sense:
http://en.wikipedia.org/wiki/Property_%28programming%29
Every language you mentioned has them. Perhaps the confusion is that I
am calling them accessors since other languages refer to accessors as
"properties" while PHP
On 10/26/2012 05:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the
remaining "being debated" categories referenced in this 1.1 -> 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
-
On 10/26/2012 05:43 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the
remaining "being debated" categories referenced in this 1.1 -> 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
-
On 10/27/2012 09:38 PM, Larry Garfield wrote:
On 10/26/2012 05:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the
remaining "being debated" categories referenced in this 1.1 -> 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemente
Hi folks,
I believe there's an issue with the SessionHandler implementation and
the way the destroy handler is invoked when using
session_regenerate_id(TRUE)
Using latest stable Gentoo PHP 5.4.6 but as far as I could tell the C
code source for this part hasn't since been touched up to master.
Th
Hey Larry,
Glad you chimed in here on this. I my opinion (author of thingy), they
are separate and distinct from data members. More specifically they
are getter and setter code that is called when the property is accessed.
Using your example:
echo $obj->baz; // executes the code "return $t
Hi!
> 1) Currently __get() is only checked/invoked if there is not a property
> already defined; ie properties shadow __get() (no performance penalty)
Yes, that's kind of the point of it - extending __get.
> 2) It would dramatically reduce performance because every property
> access would have
24 matches
Mail list logo
