[PHP-DEV] HTML escaped short echo tag
Hi internals, I'd like to propose a new short tag that echos with HTML escaping. XSS is still a significant problem for PHP apps, but it is less common in apps written with frameworks that provide automatic HTML escaping. However, many developers are still writing straight PHP without any framework and a feature like this in PHP itself could prove to be incredibly handy. One approach I sometimes use is defining a global function called h() which passes its argument through htmlspecialchars(). This works well, but it still adds a little bit of unwanted mental and typing overhead. Since escaping is desired the vast majority of the time , I'd like to see a short tag for outputting with escaping. This tag could become the de facto standard for echoing data, with ?= being seen as the more dangerous alternative. The new tag should be just as short and easy to type as ?=. Personally I'm a fan of ?- or perhaps ?~. Looking forward to hearing some feedback on this idea. Cheers, Charlie.
Re: [PHP-DEV] HTML escaped short echo tag
How do you propose we customise the escaping of such things, using htmlentities() or htmlspecialchars? What about the ENT_QUOTES options, or the charset to be used (UTF-8)? htmlspecialchars() with ENT_QUOTES and UTF-8 should be sufficient. I'm personally not a fan of your new syntax because it ass more variations to the way PHP is invoked and outputting information, but perhaps a generic escape() function is in order. Maybe you're onto something, but I feel the new php-invoking syntax isn't the way to go about it. To clarify - I'm not proposing any new functionality. I'm specifically proposing new syntax for existing functionality. I don't really see what benefits a generic escape() function would bring. The idea of this proposal is that it makes escaping just as easy as not escaping. At the moment many developers have a mindset of deciding whether or not they should escape something. I'd like to see that change to a mindset of specifically deciding not to escape a certain bit of output - and having an automatic escaping syntax will help that. On Monday, 22 October 2012 at 12:44 AM, Paul Dragoonis wrote: On Sun, Oct 21, 2012 at 2:35 PM, Charlie Somerville char...@charliesomerville.com (mailto:char...@charliesomerville.com) wrote: Hi internals, I'd like to propose a new short tag that echos with HTML escaping. XSS is still a significant problem for PHP apps, but it is less common in apps written with frameworks that provide automatic HTML escaping. However, many developers are still writing straight PHP without any framework and a feature like this in PHP itself could prove to be incredibly handy. One approach I sometimes use is defining a global function called h() which passes its argument through htmlspecialchars(). This works well, but it still adds a little bit of unwanted mental and typing overhead. Since escaping is desired the vast majority of the time , I'd like to see a short tag for outputting with escaping. This tag could become the de facto standard for echoing data, with ?= being seen as the more dangerous alternative. The new tag should be just as short and easy to type as ?=. Personally I'm a fan of ?- or perhaps ?~. Looking forward to hearing some feedback on this idea. How do you propose we customise the escaping of such things, using htmlentities() or htmlspecialchars? What about the ENT_QUOTES options, or the charset to be used (UTF-8)? If you standardise such functionality then you'll need to have a callback executed. I'm personally not a fan of your new syntax because it ass more variations to the way PHP is invoked and outputting information, but perhaps a generic escape() function is in order. Maybe you're onto something, but I feel the new php-invoking syntax isn't the way to go about it. - Paul. Cheers, Charlie.
Re: [PHP-DEV] Funny array function
I'm struggling to imagine how such a function would be useful considering you can already use [] to index arrays. If you have a variable 'depth' you need to drill down to, then writing a function to do that is also fairly trivial. On Sunday, 30 September 2012 at 9:50 PM, kuldeep dhaka wrote: hello guys, this is my first time, if thing mail is at wrong place please forward it the right place. while coding , i just found a requirement, its little bit funny. if it already exists, please be calm and mail me the function name and its usage. for accessing arrays we use ?php echo $array[school][class][roll_number][name]; // this will print the name of the student /* i was thinking if is their any function that can do the above work like */ echo array_drill($array, array(school,class,roll_number,name)); // like wise while assigning values array_drill(array to perform on, keys, new value); ? i hope you guys would have understood what i mean. kuldeep singh dhaka kuldeepdha...@gmail.com (mailto:kuldeepdha...@gmail.com)
Re: [PHP-DEV] Make try/catch brackets optinal
rescue is the exact same concept as catch On Jul 24, 2012 3:41 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 23/07/12 06:03, Alex Aulbach wrote: In other words: You want to introduce something, which we are glad not to need anymore. :) Ok. And as I said, it is a proposal so… ;-). Next topic: rescue or finally keywoard? Best regards :-). -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make try/catch brackets optinal
On Thursday, 19 July 2012 at 7:49 PM, Paul Dragoonis wrote:
Why is your try block only going to contain 1 line, and that's
throwing an exception??
try
throw new Exception('foobar');
catch(Exception $e)
Because it's a contrived example. He's not trying to write real code, he's
trying to demonstrate his point - and you totally missed that point.
Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.
1) Braces are good.
This is subjective. There are some cases where it might improve code
readability to drop the braces for a single-statement try/catch.
There's certainly no technical barrier to doing this. I'm not familiar with
PHP's parser, but I'd imagine there would be some kind of 'statement'
non-terminal that would handle single statements as well as a braced group of
statements.
2) Try with only one line in it to throw an exception doesn't seem
like a realistic situation.
There could be some utility to this. For example, as well as having post-fix
if, unless, etc., Ruby also has a post-fix 'rescue'. Here's a silly example of
its use:
some_var = foo.bar rescue oops
If 'foo.bar' threw an exception, some_var would contain oops instead.
I think PHP could benefit from having a single statement try form. I often turn
to PHP for quick and dirty scripts when I need to do something with little
fuss. I think having try/catch support brace-less single statements would help
increase consistency in PHP's syntax, as well as be useful in certain
situations.
On Thursday, 19 July 2012 at 7:49 PM, Paul Dragoonis wrote:
-1 from me, sorry Hoa.
On Thu, Jul 19, 2012 at 10:44 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net (mailto:ivan.ender...@hoa-project.net) wrote:
Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:
if($condition) {
echo 'foobar';
}
is strictly equivalent to:
if($condition)
echo 'foobar';
But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
First, I would like to know why it is not possible to write:
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e-getMessage());
as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e-getMessage());
}
Second, if it is possible, could we plan to have this “feature” (uniformity
actually) in PHP6 (or maybe before)?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make try/catch brackets optinal
This has code readability problem written all over it. When maintaining it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.
I've often heard people make this argument, but I've never found it to be a
real concern in practise.
Is this really such a common problem?
On Thursday, 19 July 2012 at 8:01 PM, Rafael Dohms wrote:
On Thu, Jul 19, 2012 at 11:44 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net (mailto:ivan.ender...@hoa-project.net) wrote:
Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:
if($condition) {
echo 'foobar';
}
is strictly equivalent to:
if($condition)
echo 'foobar';
But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
Writing if blocks without brakets is considered a bad practice. IMHO anyway.
First, I would like to know why it is not possible to write:
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e-getMessage());
This has code readability problem written all over it. When maintaining it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.
as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e-getMessage());
}
Second, if it is possible, could we plan to have this “feature”
(uniformity actually) in PHP6 (or maybe before)?
Sorry, -1 from me.
Re: [PHP-DEV] PHP class files without ?php at the top
I'm +1 on this. ?php isn't a *huge* issue, but it is a bit of an annoyance. 'phpc' would help fix that up IMO. On Saturday, 7 April 2012 at 11:26 PM, Tom Boutell wrote: Now that the flamewar has died down a little I'd like to try to have a civil discussion about this idea - *without* my admittedly inflammatory suggestion to kill ?php altogether. So here is what I am seriously suggesting: * The default behavior doesn't change. The parser starts out in HTML mode. * If the CLI sees a .phpc file extension, the parser starts out in PHP mode (no opening ?php is required). It is still possible to shift into HTML mode after that with ?. * If a require/include statement sees a .phpc file extension, the parser starts out in PHP mode. * If mod_php and FPM are able to see the path (I'm honestly not sure if they can or not), they look for .phpc as their indication to start out in PHP mode. If that's not possible then new options are defined to allow Apache to be configured to tell mod_php and/or FPM to do the right thing based on mime types etc. This way .php continues to behave exactly as it does today, and can interoperate smoothly with code that uses .phpc. .phpc can require .php and vice versa. They are friends. Thoughts? -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com (http://punkave.com) window.punkave.com (http://window.punkave.com) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Perl logo in the php website
April fools On Monday, 2 April 2012 at 4:41 PM, Eloy Bote Falcon wrote: Hi internals, Maybe this is not the correct list to ask this, but why is the perl logo placed in the php website, instead of the php logo?
Re: [PHP-DEV] resume after exception
Magnus Holm has an excellent proof of concept for this in Ruby, which
supports continuations:
http://timelessrepo.com/never-gonna-let-you-go
On Apr 2, 2012 10:44 PM, Rasmus Schultz ras...@mindplay.dk wrote:
I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...
What if you could resume execution after an exception was thrown?
Fictive example:
function test()
{
echo Begin Test!\n;
throw new Interrupt();
echo Execution resumed!;
}
try
{
test();
}
catch (Interrupt $e)
{
echo Execution interrupted.\n;
resume;
}
The output of this would be:
Begin Test!
Execution interrupted.
Execution resumed!
In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.
Taking this one step further, imagine it were also possible to serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.
I'm sure there are lots of problems with this idea, and perhaps it's not a
good fit for PHP at all, but I figured it couldn't harm to put the idea out
there anyway :-)
Any thoughts?
[PHP-DEV] json_encode() and non-UTF8 strings
Hi internals, I've created a pull request (https://github.com/php/php-src/pull/33) that changes json_encode to fall back to ASCII for strings that are not valid UTF-8. I ran into an issue in a production application involving PayPal IPN callbacks (which are sent encoded as windows-1252) and json_encode(). If there was an accented character present in the data, json_encode() would fail to encode the string and serialize it as 'null'. I've modified the behaviour of the underlying json_escape_string() implementation to attempt to encode strings anyway while still producing a warning. Thanks -- Charlie Somerville
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
My point is that *although* it's certainly possible to do almost everything I
want already, I should not have to write all that boilerplate for each enum.
I would much prefer to write something like 'enum { A, B, C }' rather than
write a full class for the enum, duplicate each enum value multiple times (your
example repeats 'foo' and 'bar' three times each), overload the __toString()
magic method, do manual error handling in the constructor, etc.
Since PHP provides no way to overload the equality operator, any solution that
tries to emulate enums as Samuel or I have written about will be flawed.
On Wednesday, 22 February 2012 at 7:37 PM, Sebastian Krebs wrote:
2012/2/22 Charlie Somerville char...@charliesomerville.com
(mailto:char...@charliesomerville.com)
Right, but enums could possibly be a lot richer than class constants are
now.
They could be a type where the only values are what's defined in the enum.
This could be used with type hinting:
enum Foo {
A,
B,
C
}
function bar(Foo $x) {
// ...
}
class MyEnum {
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
$this-value = $value;
}
public function __toString () { return $this-value; }
}
function doSomething (MyEnum $foo) { /* code */ }
What I wanted to say: I don't see, what is not possible already?
There'd be no need to do any manual checking that $x is a valid value.
Perhaps enum values could also be casted back to strings:
(string)Foo::B; // B
Sure, this is the kind of stuff that's possible in other ways already, but
first class support always helps.
On Feb 22, 2012 4:14 PM, Laruence larue...@php.net
(mailto:larue...@php.net) wrote:
On Wed, Feb 22, 2012 at 12:45 PM, Samuel Deal samuel.d...@gmail.com
(mailto:samuel.d...@gmail.com)
wrote:
Hi all,
I really missed enums in PHP,
Why? we have class constant.
thanks
So after reading I tryed to synthetise the various views.
You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)
There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.
Thanks
--
Samuel Déal
samuel.d...@gmail.com (mailto:samuel.d...@gmail.com)
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
Right, but enums could possibly be a lot richer than class constants are
now.
They could be a type where the only values are what's defined in the enum.
This could be used with type hinting:
enum Foo {
A,
B,
C
}
function bar(Foo $x) {
// ...
}
There'd be no need to do any manual checking that $x is a valid value.
Perhaps enum values could also be casted back to strings:
(string)Foo::B; // B
Sure, this is the kind of stuff that's possible in other ways already, but
first class support always helps.
On Feb 22, 2012 4:14 PM, Laruence larue...@php.net wrote:
On Wed, Feb 22, 2012 at 12:45 PM, Samuel Deal samuel.d...@gmail.com
wrote:
Hi all,
I really missed enums in PHP,
Why? we have class constant.
thanks
So after reading I tryed to synthetise the various views.
You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)
There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.
Thanks
--
Samuel Déal
samuel.d...@gmail.com
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change bug tracker bogus to not-bug?
It'd also be nice to see a more receptive approach to bug reports. It's concerning that so many legitimate bug reports get labelled as bogus for whatever reason. On Wednesday, 25 January 2012 at 10:20 AM, Matthew Fonda wrote: On Tue, Jan 24, 2012 at 3:16 PM, Paul Dragoonis dragoo...@gmail.com (mailto:dragoo...@gmail.com) wrote: On Tue, Jan 24, 2012 at 11:12 PM, Christopher Jones christopher.jo...@oracle.com (mailto:christopher.jo...@oracle.com) wrote: On 01/24/2012 03:11 PM, Justin Martin wrote: Hello, With some frequency, I find bugs which are not bogus, so much as they are reported based on a misunderstanding. Usually this happens for documentation problems, where someone has misunderstood what the documentation says, or hasn't read the documentation thoroughly enough. I'd like to propose simply changing the term bogus to not-bug. This would more politely and clearly indicate the nature of the way the bug is being closed, in addition to the comment that one ordinarily leaves. Those I've spoken to in php.doc agree. Any objections? Thank you, Justin Martin I'm +1 on this. It's time for a new, more collaborative approach. Sure, I'll +1 on this. The bogus implies RTFM, bitch, which isn't professional at all :-) I've felt this way for a long time. Big +1 on changing this. Cheers, --Matthew -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
