On Wed, Sep 19, 2012 at 8:34 AM, Sebastian Krebs wrote:
>
>
> 2012/9/19 Tomas Creemers
>>
>> Hi all,
>>
>>
>>
>> If this is going to be implemented as a class, what is the advantage
>> of instantiation for this? Unless I'm missing it, I would propose that
>> the functions are made static.
>>
[sni
You did notice the character encoding parameter to the constructor? The point
of the class is to share that little piece of state and omit it as a required
method parameter thus removing one OOP layer for those practicing OOP like all
the major frameworks.
The RFC notes already that character
2012/9/19 Tomas Creemers
> On Wed, Sep 19, 2012 at 8:34 AM, Sebastian Krebs
> wrote:
> >
> >
> > 2012/9/19 Tomas Creemers
> >>
> >> Hi all,
> >>
> >>
> >>
> >> If this is going to be implemented as a class, what is the advantage
> >> of instantiation for this? Unless I'm missing it, I would pro
2012/9/19 Tomas Creemers
> On Wed, Sep 19, 2012 at 8:34 AM, Sebastian Krebs
> wrote:
> >
> >
> > 2012/9/19 Tomas Creemers
> >>
> >> Hi all,
> >>
> >>
> >>
> >> If this is going to be implemented as a class, what is the advantage
> >> of instantiation for this? Unless I'm missing it, I would pro
On Wed, Sep 19, 2012 at 9:58 AM, Pádraic Brady wrote:
> You did notice the character encoding parameter to the constructor? The point
> of the class is to share that little piece of state and omit it as a required
> method parameter thus removing one OOP layer for those practicing OOP like
> al
On 9/19/12 2:37 AM, Sebastian Krebs wrote:
2012/9/19 Steve Clay mailto:st...@mrclay.org>>
https://wiki.php.net/rfc/__alternative_callback_syntax
reason I like 'Classname::class' for classes) I don't like, that functions will
look like
classes with a static property "function" then ...
On 19/09/12 15:15, Steve Clay wrote:
On 9/19/12 2:37 AM, Sebastian Krebs wrote:
2012/9/19 Steve Clay mailto:st...@mrclay.org>>
https://wiki.php.net/rfc/__alternative_callback_syntax
reason I like 'Classname::class' for classes) I don't like, that
functions will look like
classes with a sta
No need to apologise ;). Just wanted to clarify that the character
encoding drives the choice of class since it can be easy to miss its
importance - amended the RFC a little to highlight it.
Paddy
On Wed, Sep 19, 2012 at 12:55 PM, Tomas Creemers
wrote:
> On Wed, Sep 19, 2012 at 9:58 AM, Pádraic
Hi Steve,
Missed this one in the rush of emails...
> I echo this. I think some clearer names might help, I think something like
> these:
>
> escapeHTMLAttribute for attributes, escapeHTMLText for text inside
> tags, escapeXMLAttribute and escapeXMLContent, escapeJSStringLiteral,
> escapeCSSIdent
>> 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 ;-)
It's probably already been covered, but I don't like t
Hi,
For now php-fpm provides and init.d sample script.
I propose to also provide an unit sample file.
During updating systemd management in fedora, I notice it is quite ugly
to rely on configuration file for daemonize option, as user can change
this value (testing purpose) and will break the la
Hi Leigh,
On Wed, Sep 19, 2012 at 3:10 PM, Leigh wrote:
>>> 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 19/09/12 15:07, Pádraic Brady wrote:
Hi Steve,
Who's he? :)
The ESAPI API uses encodeForHTML, encodeForCss, etc. We can name these
in a few different styles which would all be semantically correct but
my own sentiment is often to keep the naming simple.
The naming is unclear just now though
>> Hi Steve,
>
> Who's he? :)
Everybody knows Steve! :P I know at least 10!
>> The ESAPI API uses encodeForHTML, encodeForCss, etc. We can name these
>> in a few different styles which would all be semantically correct but
>> my own sentiment is often to keep the naming simple.
>
> The naming is
On 19/09/12 16:36, Pádraic Brady wrote:
Hi Steve,
Who's he? :)
Everybody knows Steve! :P I know at least 10!
The ESAPI API uses encodeForHTML, encodeForCss, etc. We can name these
in a few different styles which would all be semantically correct but
my own sentiment is often to keep the namin
> It feels like this is just using classes for the sake of using
> classes, adding an unnecessary layer of complexity (and discussion)
> for no real reason except that is the RFC authors preference.
+1
First the discussion was filtering vs escaping. Now it is about how to
implement it as a clas
On 19/09/12 17:06, Michael Shadle wrote:
It feels like this is just using classes for the sake of using
classes, adding an unnecessary layer of complexity (and discussion)
for no real reason except that is the RFC authors preference.
+1
First the discussion was filtering vs escaping. Now it is
Personally, I would like to see it operate similar to MySQLi, where you
have the convenience of OOP, but can still call a function directly in a
procedural manner.
And I definitely feel like we need encoding. We can default it to UTF-8 or
to the zend.script_encoding if set, but I think it needs t
> Call it str_escape(string, flags optional, encoding optional) and be done
> with it.
Keeping it simple definitely preferred
> 1) do we even need encoding or is UTF8 just fine
Definitely need encoding.
mbstring supports quite a lot
http://php.net/manual/en/mbstring.supported-encodings.php
I
Hi,
Am 19.09.2012 um 18:11 schrieb Michael Stowe :
> Personally, I would like to see it operate similar to MySQLi, where you
> have the convenience of OOP, but can still call a function directly in a
> procedural manner.
There seems to be a need for a procedural API. As their is one, let’s do it
On 19/09/12 17:16, Lars Strojny wrote:
Hi,
There seems to be a need for a procedural API. As their is one, let’s do it
similar to how MySQLi etc. does it and use a context resource:
$ctx = escape_context_create('UTF-8');
$str = escape_html_attr($ctx, $str);
And so on.
cu,
Lars
Oh goodness no
*"Oh goodness no, let's please only do OOP with the language features.
Creating ridiculous "procedural" OOP abstractions helps absolutely nobody"*
Andrew, I'm the biggest advocate of OOP out there, but the purpose of this
is to provide a nice convenient layer for all developers to use to properly
On 19/09/12 17:21, Michael Stowe wrote:
/"Oh goodness no, let's please only do OOP with the language features.
Creating ridiculous "procedural" OOP abstractions helps absolutely
nobody"/
Andrew, I'm the biggest advocate of OOP out there, but the purpose of
this is to provide a nice convenient
On Wed, Sep 19, 2012 at 9:08 AM, Andrew Faulds wrote:
> Yes, but typing the encoding every time is cumbersome. Or, if you don't want
> to set it every time, you'd have to set it globally. Then, you forgot to
> change it back somewhere when you're dealing with multiple encodings, and it
> all goes
On Wed, Sep 19, 2012 at 9:16 AM, Lars Strojny wrote:
> There seems to be a need for a procedural API. As their is one, let’s do it
> similar to how MySQLi etc. does it and use a context resource:
>
> $ctx = escape_context_create('UTF-8');
> $str = escape_html_attr($ctx, $str);
why bother with t
On Wed, Sep 19, 2012 at 9:21 AM, Michael Stowe wrote:
> Andrew, I'm the biggest advocate of OOP out there, but the purpose of this
> is to provide a nice convenient layer for all developers to use to properly
> escape code and increase security within their applications. As such, we
> need to ca
On 19/09/12 17:57, Michael Shadle wrote:
If you want to play with OO all day, then use Java. PHP was built on
procedural, and now all you OO fanboys are going nuts with it. :) On a
short-lived web request I see no reason to complicate and obfuscate
the code with OO.
Please explain in detail how o
On Tue, Sep 18, 2012 at 8:48 PM, Steve Clay wrote:
>
> Hello,
>
> https://wiki.php.net/rfc/alternative_callback_syntax is a proposal for a
> simple alternative syntax for creating function callbacks.
>
> The basics: Given a function/method call, replace the argument list with
> "::function". PHP
On Wed, Sep 19, 2012 at 10:11 AM, Andrew Faulds wrote:
> Please explain in detail how object-oriented code obfuscates, complicates,
> murders baby kittens, etc.
Because a simple str_replace one line will become 6-10 lines of OO
code very easily?
Maybe you write "amazing" OO code, but the stuff
On 19/09/12 18:16, Levi Morrison wrote:
On Tue, Sep 18, 2012 at 8:48 PM, Steve Clay wrote:
Hello,
https://wiki.php.net/rfc/alternative_callback_syntax is a proposal for a simple
alternative syntax for creating function callbacks.
The basics: Given a function/method call, replace the argument
On 19/09/12 18:19, Michael Shadle wrote:
Because a simple str_replace one line will become 6-10 lines of OO
code very easily?
Does it?
Let's use an example from Python, which actually has strin methods. And
then stop this argument that isn't related to the topic.
PHP:
str_replace('yak',
On Sep 19, 2012 4:31 AM, "Kris Craig" wrote:
>
> On Tue, Sep 18, 2012 at 8:14 AM, Amaury Bouchard
wrote:
>
> > Sounds to me like aspect-oriented programming, applied to object
> > construction.
> > Take a look at: https://github.com/AOP-PHP/AOP
> >
> >
> Yeah I wasn't aware of this, either, but I
On 9/19/12 9:26 AM, Ivan Enderlin @ Hoa wrote:
callable is already a reserved word (T_CALLABLE).
Oh, good. It's not listed here http://php.net/manual/en/tokens.php
Steve
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
Hi Andrew,
On Wed, Sep 19, 2012 at 4:39 PM, Andrew Faulds wrote:
>> Than I suggest including "For" in all of them. escapeForHtml,
>> escapeForUrl, etc. That should clear it up somewhat that we're not
>> targeting whole blocks of HTML/JS/CSS.
>
> That still isn't clear enough, I think. escapeHTMLA
On Sep 19, 2012, at 10:22 AM, Andrew Faulds wrote:
> Again, "all the OOP code is a waste of time" doesn't really add anything to
> this discussion. Arguing against this being OOP, which I think is useful and
> requires, at most, one extra line ($x = new Escaper), is silly.
Arguing semantics ov
On 19/09/12 18:48, Pádraic Brady wrote:
I think we're running into being overly prescriptive. Escaping can
never, by definition, apply to anything that isn't a value string or
integer, i.e. anything that is capable of altering the meaning of the
HTML/Javascript or CSS into which its inserted. Th
Hi Michael,
>> It feels like this is just using classes for the sake of using
>> classes, adding an unnecessary layer of complexity (and discussion)
>> for no real reason except that is the RFC authors preference.
>
> +1
>
> First the discussion was filtering vs escaping. Now it is about how to
>
On 9/19/12 1:19 PM, Andrew Faulds wrote:
I completely agree. How about &function_name? Resembles C (function pointers!),
and unless
I'm getting confused, it isn't currently legal syntax for something else.
$cb = & Foo::doSomething;
$cb = & foo_doSomething;
$cb = & $obj->doSomething;
The last
On 19/09/12 18:56, Steve Clay wrote:
On 9/19/12 1:19 PM, Andrew Faulds wrote:
I completely agree. How about &function_name? Resembles C (function
pointers!), and unless
I'm getting confused, it isn't currently legal syntax for something
else.
$cb = & Foo::doSomething;
$cb = & foo_doSomething;
On Sep 19, 2012, at 10:55 AM, Pádraic Brady wrote:
> I have never once expressed a problem with this being a set of
> procedural function. Not once. The RFC offers some suggested function
> signatures. So nobody has expressed any issues and nobody has insisted
> that you be required to use a cla
On 9/19/12 2:01 PM, Andrew Faulds wrote:
Some other ideas:
$cb = (callable) $obj->bar;
Ah, but (callable) that won't work for global functions, since (callable) is a
cast, and
(callable) is not usable as a cast (at least in 5.4.7):
$a = (callable)'str'; // Parse error: syntax error, unexpec
On 19/09/12 19:21, Steve Clay wrote:
On 9/19/12 2:01 PM, Andrew Faulds wrote:
Some other ideas:
$cb = (callable) $obj->bar;
Ah, but (callable) that won't work for global functions, since
(callable) is a cast, and
(callable) is not usable as a cast (at least in 5.4.7):
$a = (callable)'str';
Hi everybody,
I'm currently working on https://github.com/php/php-src/pull/186, which fixes a
problem with PostgreSQL when passing a float to pg_query_params() with a locale
setting that uses "," as a decimal point. pg_query_params() uses
convert_to_string(), which uses %G as a format string fo
On Wed, Sep 19, 2012 at 10:34 AM, jpauli wrote:
>
> On Sep 19, 2012 4:31 AM, "Kris Craig" wrote:
> >
> > On Tue, Sep 18, 2012 at 8:14 AM, Amaury Bouchard
> wrote:
> >
> > > Sounds to me like aspect-oriented programming, applied to object
> > > construction.
> > > Take a look at: https://github.
Hi,
Am 19.09.2012 um 20:35 schrieb Lars Strojny :
[...]
> This kind of fix is very likely needed in other places, where floats are
> converted using convert_to_string(). I haven’t found time to try e.g.
> mysqlnd, but I suspect we’ll find similar issues there. I don’t think the
> proposed worka
On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady wrote:
> Hi Michael,
>
> See the link near the bottom of the RFC - even htmlspecialchars() has
> unusual behaviour that's potentially insecure. I have no objections to
> there being functions, of course, and the RFC makes that clear.
> However, many
On Wed, Sep 19, 2012 at 10:48 PM, Michael Shadle wrote:
> On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady
> wrote:
>> Hi Michael,
>>
>> See the link near the bottom of the RFC - even htmlspecialchars() has
>> unusual behaviour that's potentially insecure. I have no objections to
>> there being f
Anthony,
I'll run through some of the semantics related to your response in case it
provides any insight that would encourage a direction change for this
functionality. But overall, I agree 100% with your closing line, "I think it
strongly depends upon the exact behavior of the library. If we d
On 20/09/12 07:48, Michael Shadle wrote:
On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady wrote:
Hi Michael,
See the link near the bottom of the RFC - even htmlspecialchars() has
unusual behaviour that's potentially insecure. I have no objections to
there being functions, of course, and the RFC
On Wed, Sep 19, 2012 at 9:25 PM, David Muir wrote:
> On 20/09/12 07:48, Michael Shadle wrote:
>>
>> On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady
>> wrote:
>>>
>>> Hi Michael,
>>>
>>> See the link near the bottom of the RFC - even htmlspecialchars() has
>>> unusual behaviour that's potentially
Bryan,
“You hit the nail on the head here. You cannot black-list convert
> ISO-8859-1 to UTF-8. However, when we talk about escaping, we're talking
> about a context where the encoding is already correct, we're just
> preventing special characters from imparting special meaning. In that case,
> es
51 matches
Mail list logo
