That has not been covered and it is a problem, just tested it.
Anyone have any preferences on a resolution?
Only thing that really needs to occur is that the function names need to
be unique, we could prefix any capitals in a variable name with an
additional _ such that:
class A {
Em 2013-01-02 16:53, Nicolai Scheer escreveu:
I might have chosen the wrong tool for what I'm trying to achieve in
the
first place, but can anyone comment on the algorithmic complexity of
strtr?
This is definitely not the expected behaviour for such small inputs.
Since
the inputs varied and
On 1/3/2013 12:48 AM, Stas Malyshev wrote:
Hi!
Within get: $this-Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this-Hours = 1 can write to the underlying property but a
read of the property would go
Just getting back to you on #1 and #2...
#1: It seems the majority want to have these internally created accessor
functions visible, which they presently are through get_class_methods,
etc. They are currently hidden by Reflection. I favor the latter, as is
implemented in Reflection since an
The is_null feature is really helpful. Thanks!
Am 02.01.2013 um 16:26 schrieb Johannes Schlüter johan...@schlueters.de:
Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
I've written an RFC. It's available on:
https://wiki.php.net/rfc/zpp_improv
The patch is mssing an update to
No objection from my POV. Going to merge it in around a week, if no one objects.
Am 02.01.2013 um 10:35 schrieb matt clegg cleggm...@gmail.com:
I have added ImageCopyMergeAlpha as an extra function to resolve bug 23815.
I have created a pull request on github
On Wed, Jan 2, 2013 at 3:29 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
Em 2012-07-18 23:05, Gustavo Lopes escreveu:
Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t;
Hi!
On 3 January 2013 11:40, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
Em 2013-01-02 16:53, Nicolai Scheer escreveu:
I might have chosen the wrong tool for what I'm trying to achieve in the
first place, but can anyone comment on the algorithmic complexity of
strtr?
This is definitely
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value;
Before I look into this further, can someone confirm that fopen on a zip
stream should return something other than a null?
I've a zip called test.zip which contains 5 files,
a.txt,b.txt,c.txt,d.txt and yes, e.txt
The zip is valid and can be unzipped using unzip on linux.
Running the
On 1/3/2013 8:21 AM, Steve Clay wrote:
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t;
On 1/3/2013 9:33 AM, Steve Clay wrote:
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return
On 3 January 2013 17:41, Clint Priest cpri...@zerocue.com wrote:
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
We have constructors, shouldn't those be sufficient for that task?
--
Regards,
Mike
--
PHP
On 1/3/13 11:41 AM, Clint Priest wrote:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value; }
}
}
What would be the point of this?
I think it would be more readable for someone using the class. As a user it
On 1/3/13 12:42 PM, Michael Wallner wrote:
On 3 January 2013 17:41, Clint Priest cpri...@zerocue.com wrote:
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
We have constructors, shouldn't those be sufficient
Clint,
...snip...
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
Well, just speaking in general, we should not try to rush through these
kinds of design decisions. They should only be done incrementally if
Hi!
I think infinite recursion is a potential issue for lots of logging setups
(let's log
when someone calls the logger!) and situations where you have multiple
values to keep in
sync. The accessor implementation shouldn't try to solve these design
problems.
The whole problem here is
Not really sure what to say about this, we can either guard against
recursion or not, I see
no reason *not* to guard against recursion except that it could allow
unauthorized direct
access when the guard is active.
I guess a third option could be that if the property is attempted to be
Note, there has been a show stopper of an issue with the current RFC
that many minds have been talking about how to solve.
The problem is with parent::$foo accessing the parent accessor.
In summary, the difficulty is that this is parsed as a static property
access and during compilation there
Please note that I have updated and clarified v1.2 with some recent
feedback:
1) Steve Clay suggested the term Guarded Property and dropping
Shadowing. The Shadowing section has been renamed to Guarding, some
of the wording was updated and the For Additional Clarity was updated
with nearly
Hi!
A recent suggestion from Stas is to use parent-$foo (note the use of -
rather than ::)
I actually proposed parent-foo. parent-$foo implies the name of the
variable is $foo, not foo - just as in $this-$foo. Yes, I know it
does not match parent::$foo - but I can't do much about it. In any
22 matches
Mail list logo
