Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63132
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <0960EAA5-17FF-4E0F-9DDE-BB93D13EA02B@gmail.com>
References: <CAO1hux8mmUsy4badiNjxTGMubaduD1gkgbw4ZK1Me_MwGwLybA@mail.gmail.com>
	<CALtuQzC4e2Sn_BHinFAPdVrz8Oc_d6wCqTr=AscMChH29NSENw@mail.gmail.com>
	<CAO1hux9+4QK2sVX9+4110ksa9qDpUpfDhFJvyzkXcBHrFoFWvg@mail.gmail.com>
	<0960EAA5-17FF-4E0F-9DDE-BB93D13EA02B@gmail.com>
Date: Wed, 19 Sep 2012 13:55:52 +0200
Message-ID: <CAO1hux9t9refYHYnKhY0725MvRm88ab85Ng23LCvnjDJxqQA7g@mail.gmail.com>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <padraic.brady@gmail.com>
Cc: Sebastian Krebs <krebs.seb@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class
From: tomas.creemers@gmail.com (Tomas Creemers)

On Wed, Sep 19, 2012 at 9:58 AM, P=E1draic Brady <padraic.brady@gmail.com> =
wrote:
> You did notice the character encoding parameter to the constructor? The p=
oint of the class is to share that little piece of state and omit it as a r=
equired method parameter thus removing one OOP layer for those practicing O=
OP like all the major frameworks.
>
> The RFC notes already that character encoding parameters are NOT optional=
. They MUST be set on each call outside of the class to enforce explicitnes=
s and prevent the currently popular option of imposing a non-configurable d=
efault in libs and frameworks. Character encoding is important in escaping =
and assuming that they are interchangeable doesn't always fit the reality o=
f browser behaviour and bugs.
>
> This would apply to static calls as much as plain functions.
>
> Paddy

I missed the encoding parameter. While it's still possible to add that
to a static-only class, that would be more cumbersome and less correct
than instantiation (since the encoding is state, technically). My
apologies. Carry on ;-)

Tomas


> On 19 Sep 2012, at 08:39, Tomas Creemers <tomas.creemers@gmail.com> wrote=
:
>
[snip]
>>
>> I really don't see what class instantiation would add to this design
>> (if it's going to be a class at all). It doesn't have
>> instance-specific state.
>>
>>
>> Regards,
>> Tomas
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>