It's important to escape output according to context. PHP provides
functions such as htmlspecialchars() to escape output when the context
is HTML. However, one often desires to allow some subset of HTML
through without escaping (e.g., , , etc.)
Functions such as strip_tags() do allow whitelisting,
On 1/4/2013 4:29 PM, Stas Malyshev wrote:
Hi!
This shouldn't be an issue because it is not possible to set the
property without going through the setter, which would be a type hinted
accessor function.
It is possible, if this property's guard is set. Since guard works for
all code called from
Agreed. Some people may actually be using $parent as a variable name,
not difficult to imagine.
So far parent->foo seems to be the answer.
-Clint
On 1/4/2013 4:23 PM, Stas Malyshev wrote:
Hi!
One other possible alternative would be to treat parent "like a variable..."
$parent->foo
That w
On Sat, Jan 5, 2013 at 12:31 AM, Steve Clay wrote:
> Would the following two be exactly functionally equivalent?
>
> public Foo $foo;
>
> public $foo {
> get;
> set(Foo $value) { $this->foo = $value; }
> }
>
> We should also consider how an author would allow type-hinted properties
> to a
On Fri, Jan 4, 2013 at 4:34 PM, Levi Morrison wrote:
>>We should also consider how an author would allow type-hinted properties to
>>accept NULL as a new value, in both proposals.
>
> public $foo {
> get;
> set(Foo $value = NULL) { $this->foo = $value; }
> }
>
> Would work for traditional
>We should also consider how an author would allow type-hinted properties to
>accept NULL as a new value, in both proposals.
public $foo {
get;
set(Foo $value = NULL) { $this->foo = $value; }
}
Would work for traditional type-hints.
--
PHP Internals - PHP Runtime Development Mailing Li
Would the following two be exactly functionally equivalent?
public Foo $foo;
public $foo {
get;
set(Foo $value) { $this->foo = $value; }
}
We should also consider how an author would allow type-hinted properties to
accept NULL as a new value, in both proposals.
Steve
--
http://www.mrc
Hi!
> This shouldn't be an issue because it is not possible to set the
> property without going through the setter, which would be a type hinted
> accessor function.
It is possible, if this property's guard is set. Since guard works for
all code called from inside the setter, if setter is doing
Hi!
> One other possible alternative would be to treat parent "like a variable..."
>
> $parent->foo
That would be a big BC problem and also require serious changes to
handle it (look how $this is implemented - it's not regular variable at
all). So $parent is probably a non-starter.
--
Stanislav
On Fri, 4 Jan 2013, Paul Taulborg wrote:
> I submitted a bugfix patch for this one:
> https://bugs.php.net/bug.php?id=63615 on 2012-12-06
> and asked for feedback here, to make sure this was intended
> functionality. I also have not heard back, and the bug is still
> unassigned. It's not something
Hi!
> Hi, there is a bug(s) I'd like to be fixed and even a patch is available.
> But there is still no reaction at all after 2 years. What else can I do to
> get the bug(s) fixed?
Pull request may speed things up, writing to internals might too :)
> https://bugs.php.net/bug.php?id=45351 - patch
Adding Derick to the loop
On Jan 4, 2013 8:23 PM, "Paul Taulborg" wrote:
> I submitted a bugfix patch for this one:
> https://bugs.php.net/bug.php?id=63615 on 2012-12-06
> and asked for feedback here, to make sure this was intended
> functionality. I also have not heard back, and the bug is still
I submitted a bugfix patch for this one:
https://bugs.php.net/bug.php?id=63615 on 2012-12-06
and asked for feedback here, to make sure this was intended
functionality. I also have not heard back, and the bug is still
unassigned. It's not something that ever affected me personally, it
was a random b
On Fri, Jan 4, 2013 at 6:33 PM, Enumag wrote:
> Hi, there is a bug(s) I'd like to be fixed and even a patch is available.
> But there is still no reaction at all after 2 years. What else can I do to
> get the bug(s) fixed?
>
> https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-1
Hi, there is a bug(s) I'd like to be fixed and even a patch is available.
But there is still no reaction at all after 2 years. What else can I do to
get the bug(s) fixed?
https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13
https://bugs.php.net/bug.php?id=48724 - patch available
Hi Clint,
got it.
Am 04.01.2013 um 16:28 schrieb Clint Priest :
> Uhm.. brain fart.
>
> I was thinking $this->$foo was normal when I wrote this up, I would change my
> last statement from the earlier email to any syntax which did not include a $.
>
> That being said then, I think I favor par
Uhm.. brain fart.
I was thinking $this->$foo was normal when I wrote this up, I would
change my last statement from the earlier email to any syntax which did
not include a $.
That being said then, I think I favor parent->foo the best.
One other possible alternative would be to treat parent "
This shouldn't be an issue because it is not possible to set the
property without going through the setter, which would be a type hinted
accessor function.
Ergo, an attempt to set the value to an invalid value would cause a
fatal error and thus the setter would not be able to then set it to th
This proposal looks really good to me. It cuts out a lot of syntax and
boilerplate for a commonly used case. However, there is one issue that
I know somebody is going to raise:
Argument: If you change the value of the property without using the
setter then `get` could return something that has a t
Are there any updates on this? I submitted this patch a month ago that
is a significant performance increase for some commonly used date/time
functions:
https://bugs.php.net/bug.php?id=63699
Can anyone provide feedback on this, and any possible reasons why this
seems to be shelved?
Thanks!
--
P
Hi internals!
I already brought this up before, but I think the discussion at that time
was not very constructive and largely off-topic, so I'm bringing it up
again. To make sure everything is clear I wrote an RFC document:
https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syn
No need to create another function for that. I will do it once I am back at
work next week.
On Jan 3, 2013 12:33 PM, "Lars Strojny" wrote:
> 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 :
>
> > I have added ImageC
Hi Clint,
Am 04.01.2013 um 04:13 schrieb Clint Priest :
[...]
> 1) It forces the user to access the parent property accessor in a different
> way than is used everywhere else
Isn’t that the same as parent->$foo? Please let’s not introduce a special
syntax for something that can be done proper
Speaking of which, parent::foo ( with :: but no $) might work as well, almost
*any* character change could work...
parent:::$foo
parent:$foo
parent->$foo
parent->foo
parent.$foo
parent.foo
I favor having the $ in some solution though...
-Clint
On Jan 4, 2013, at 5:04 AM, Clint Priest wrote:
Missed that bit... I think that would add two bits of inconsistency though...
(Without the $)
-Clint
On Jan 4, 2013, at 1:18 AM, Stas Malyshev wrote:
> Hi!
>
>> A recent suggestion from Stas is to use parent->$foo (note the use of ->
>> rather than ::)
>
> I actually proposed parent->foo.
25 matches
Mail list logo
