Re: [PHP-DEV] HTML escaped short echo tag
On Sun, Oct 21, 2012 at 1:01 PM, Stas Malyshev wrote: > Hi! > >> I'd like to propose a new short tag that echos with HTML escaping. > > What is "HTML escaping"? Different contexts need different escaping. For > outside tags it's one escaping, for tag attribute it's another, for JS > code context - yet another. Selecting just one use case and integrating > it into the language is a bad idea - since you are basically saying > everybody should use this specific case in any case, which is wrong. > >> The new tag should be just as short and easy to type as > a fan of > Personally I'm hugely *not* a fan of more obscure syntax in PHP. > Especially one that will quickly lead people into writing insecure code > because of applying wrong escaping function for the context. I completely agree. Adding a new syntax for automatic escaping (even if configurable -- yay more php.ini!) is not going to change anyone's mindset from defensive to offensive stance in my opinion. If you have a template which generates javascript, css, and x/html all from the same PHP file you get a lot of confusing having to deal with some new syntax where users now have to be considerate of what output syntax decides on what escape method. For this most user-space implementations (frameworks like you mentioned) do a fine job of identifying these common use cases and providing a common solution. There's the taint approach which could allow a framework to automatically figure out which variables are tainted and should be escaped and which aren't and can pass through cleanly. PHP doesn't need to get in the way here. I think the existing userland implementations should do fine if they get it right. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > 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] [RFC] Accessors : read-only / write-only keywords
I don't disagree (sure, I campaigned to remove the "read-only" keyword). But "not writable" is still different from "private writing". Should we loose any of these meanings? 2012/10/21 Clint Priest > I think that seems to be the consensus at this point, anyone disagree? > > > -Original Message- > > From: Levi Morrison [mailto:morrison.l...@gmail.com] > > Sent: Sunday, October 21, 2012 10:26 AM > > To: Amaury Bouchard > > Cc: Nikita Popov; Clint Priest; internals@lists.php.net > > Subject: Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords > > > > > If for some reason you need to enforce that nobody inherits it and > > > sets the property, then declaring a setter and issuing an error or > > > exception would suffice. > > > > I meant to say declaring a `private or final setter`. Noticed that > after I sent it. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
2012/10/21 Levi Morrison > I would like to point out that in my mind `const` and `read-only` are > not necessarily the same thing. Read-only means that from outside the > class it cannot be modified; the internal class can change it whenever > it wants. Const means that once the value is set it will NEVER change. > Big difference. > "read-only" means that it is only readable. Like const. If the internal class can change it, you are defining writing visibility (as private or protected). Yes, it is different. Visibility has far more meaning than just saying it's a constant value. In fact, "read-only" is a sub-case of usual visibility management.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi! > I think we are still not on the same page here. The exact point is > to *not* put accessors into the method table. As such the accessors > aren't special, half-hidden methods (like they are with the current > implementation), rather they are *just* accessors and nothing else. Accessors are not "half-hidden" now - they are just methods. That's the beauty and simplicity of it, and that's exactly why it works. I want to keep the simplicity and not invent unnecessary complicated entities. Keep it simple. > It's all about making accessors accessors, rather than making them Sorry, I don't understand the meaning of this. You obviously have a preconception of how "accessors" should be, but please understand it's only obvious and natural to you, because it's yours. To me, and I'm sure to many other PHP users, it's an elaborate and complex, yet unnecessary construct, that works almost like methods but subtly different for some reason, and has no precedence in whole PHP history (and, actually, any other dynamic language history, as far as I can see). In my opinion, this is completely unnecessary, and even more - harmful. I'd like to keep PHP simple and have just methods as methods, just as they were in PHP for many years. > Accessors need to be considered separately anyway, otherwise you end > up with the problems that we currently have, where you can't > override a property with an accessor in an extending class or the > other way around. Having those pseudo-methods makes this even more > complicated, This has nothing to do with precedence of variable access resolution, and nobody proposes pseudo-methods. The whole point is I am proposing *not* to do pseudo-methods, but use regular methods instead. > Again, this has to be done anyway and is already done. Accessors > need It does not matter. Unnecessarily complicated code in the engine is bad even if somebody already implemented it - because unneeded complexity is always harmful and it hurts even more over time, as everybody needs to support it and deal with it and make it work with all the rest of the engine. Keeping it simple is a very high priority. > I think it's the other way around. As I already said above, the > accessors won't be methods. So you don't have to consider anything. That's what I think is completely wrong. They work exactly like methods and that's what they should be. > maybe during debugging or whatever). Now you either have to > explicitly consider them in your code, for they are not actual > methods, or the They *are* actual methods, or they should be. You just don't want them to be, but that's where it is wrong, because it creates unnecessary complexity, both conceptual and technical. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTML escaped short echo tag
> Personally I'm hugely *not* a fan of more obscure syntax in PHP. I agree with this sentiment. I think the traditional simplicity of PHP's syntax has been one of its greatest traits. I'm not a fan of all of this type of alternate syntax that has been steadily added. Bryan
Re: [PHP-DEV] HTML escaped short echo tag
Hi! > I'd like to propose a new short tag that echos with HTML escaping. What is "HTML escaping"? Different contexts need different escaping. For outside tags it's one escaping, for tag attribute it's another, for JS code context - yet another. Selecting just one use case and integrating it into the language is a bad idea - since you are basically saying everybody should use this specific case in any case, which is wrong. > The new tag should be just as short and easy to type as a fan of http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generics proposal
Hi! > Hello, list. I want to propose generics. Please no. If you need Java, you know where to find it. Java has a set of great tools, great books, great community. And it's completely free. Anybody who needs Java can just do it. I see no need to turn PHP into Java. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generics proposal
Hi Rasmus,
Am 20.10.2012 um 23:02 schrieb Rasmus Lerdorf :
[...]
> Personally I would hate to see this anywhere near PHP.
Do you mind explaining the why? Isn’t it better than new
Collection("TypeAsAString") and custom assertions in each and every method of
that collection class?
cu,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
I think that seems to be the consensus at this point, anyone disagree? > -Original Message- > From: Levi Morrison [mailto:morrison.l...@gmail.com] > Sent: Sunday, October 21, 2012 10:26 AM > To: Amaury Bouchard > Cc: Nikita Popov; Clint Priest; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords > > > If for some reason you need to enforce that nobody inherits it and > > sets the property, then declaring a setter and issuing an error or > > exception would suffice. > > I meant to say declaring a `private or final setter`. Noticed that after I > sent it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
> If for some reason you need to enforce that nobody inherits it > and sets the property, then declaring a setter and issuing an > error or exception would suffice. I meant to say declaring a `private or final setter`. Noticed that after I sent it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
I would like to point out that in my mind `const` and `read-only` are not necessarily the same thing. Read-only means that from outside the class it cannot be modified; the internal class can change it whenever it wants. Const means that once the value is set it will NEVER change. Big difference. Also, I feel like there is no need for the read-only keyword. Defining a getter and not a setter should suffice in my opinion. The absence of the setter declares intent well, in my opinion. If for some reason you need to enforce that nobody inherits it and sets the property, then declaring a setter and issuing an error or exception would suffice. Let's not clutter up the language for such a simple idea. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 > 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 > alternative. > > > > The new tag should be just as short and easy to type as > a fan of > > > 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] HTML escaped short echo tag
On Sun, Oct 21, 2012 at 2:35 PM, Charlie Somerville < 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 alternative. > > The new tag should be just as short and easy to type as a fan of > 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. >
[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
Re: [PHP-DEV] Generics proposal
I actually don't have much experience with generics, so won't argue about their readability, but this article is all about Java's implementation of generics, so I don't know how much sense this article gives in that context. But it's ok, I see just one person that supported proposal. I think case closed. I see what you are trying to achieve, but I hope this will never make into PHP mainly for impact on readability. I'd like to quote Eric Armstrong, a passionate Java/Ruby dev: I decry their very existence. They are the ultimate condemnation of static type checking--because their very addition has virtually destroyed both the readability and elegance of the language. To make my case, let's start with a quasi-mathematical definition of "elegance". In my view, elegance is a function of power and simplicity. Power is measured by how much you can do. Simplicity is the inverse of the number of characters it takes to achieve the result. So more power with fewer characters equals "elegance" http://www.artima.com/weblogs/viewpost.jsp?thread=299081 __ I question the "need to validate" types part. I'd say you're better off using a completely different language if you want to use strong typing. For PHP: Embrace duck typing, write less boiler-plate code (thus reducing the need for "smart" IDE) and be happy :-) We have typehints, that was my point here. That's the same as saying you can ignore most of the C++ feature and that will make it a simple language. That's neither true for developers nor users of the language. PHP now is multi-paradigm language (isn't it), so... yep, that's the same :) 1) Makes language harder to maintain as there is more (and more complex) code implementing it. 2) Makes documentation bigger so users have first to figure out what part to read and what part to ignore. 3) Makes it harder to write portable user-land libraries as the application and the different libraries might use different (clashing) paradigms. See error codes vs. exceptions as an example of this. 4) Makes it harder to have extensions like APC as they have to implement more features. 5) Makes it harder to write alternative implementations. All this points are also applicable to namespaces, [abstract,final] classes, interfaces, traits, access modifiers (instead of using `var`), etc. If you would have said, this points in the context of... say... necessity of that feature, then yeah, maybe you would be right. Anyway, as long as almost no one didn't supported, I think we can close this discussion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generics proposal
I see what you are trying to achieve, but I hope this will never make into PHP mainly for impact on readability. I'd like to quote Eric Armstrong, a passionate Java/Ruby dev: > I decry their very existence. They are the ultimate condemnation of static > type checking--because their very addition has virtually destroyed both the > readability and elegance of the language. > To make my case, let's start with a quasi-mathematical definition of "elegance". > In my view, elegance is a function of power and simplicity. Power is measured > by how much you can do. Simplicity is the inverse of the number of characters > it takes to achieve the result. So more power with fewer characters equals > "elegance" http://www.artima.com/weblogs/viewpost.jsp?thread=299081 Devis On 21 October 2012 12:55, Alexey Zakhlestin wrote: > > On 21.10.2012, at 0:59, Nikita wrote: > > > Hello, list. I want to propose generics. > > > So, what you think? > > I'm against having this in PHP. > > For IDEs, the better solution is to use generics-like syntax in docblocks. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Generics proposal
Am 21.10.2012 um 13:33 schrieb Nikita Nefedov : > No, this is useful in any OOP-language where there is such thing as type, and > people need to validate types. I question the "need to validate" types part. I'd say you're better off using a completely different language if you want to use strong typing. For PHP: Embrace duck typing, write less boiler-plate code (thus reducing the need for "smart" IDE) and be happy :-) > I unerstand what you are saying about PHP being an easy language, but in > opinion if you don't want to use that feature you can not use it, as you can > not use typehinting in functions for example. That's the same as saying you can ignore most of the C++ feature and that will make it a simple language. That's neither true for developers nor users of the language. Example on why this is are 1) Makes language harder to maintain as there is more (and more complex) code implementing it. 2) Makes documentation bigger so users have first to figure out what part to read and what part to ignore. 3) Makes it harder to write portable user-land libraries as the application and the different libraries might use different (clashing) paradigms. See error codes vs. exceptions as an example of this. 4) Makes it harder to have extensions like APC as they have to implement more features. 5) Makes it harder to write alternative implementations. ... So yes, I agree with Rasmus that this is not a good fit for PHP. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generics proposal
On 21.10.2012, at 0:59, Nikita wrote: > Hello, list. I want to propose generics. > So, what you think? I'm against having this in PHP. For IDEs, the better solution is to use generics-like syntax in docblocks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generics proposal
No, this is useful in any OOP-language where there is such thing as type,
and people need to validate types.
I unerstand what you are saying about PHP being an easy language, but in
opinion if you don't want to use that feature you can not use it, as you
can not use typehinting in functions for example.
Hi Nikita,
What you're asking for is useful in other languages, but it doesn't match
the style of PHP which is to be a quick and easy type-less scripting
language.
What you're proposing is clearly more suited to something like Java or
C#,
but doesn't really belong here.
I'd also hate to see this anywhere near PHP.
Many thanks,
Paul.
On Sat, Oct 20, 2012 at 11:10 PM, Marco Pivetta
wrote:
On 20 October 2012 23:09, Michael Stowe wrote:
> I see what you're trying to do but not a big fan of how it's being
> implemented in the example given.
>
> - Mike
>
> Sent from my iPhone
>
> On Oct 20, 2012, at 4:02 PM, Rasmus Lerdorf
wrote:
>
> > On 10/20/2012 01:59 PM, Nikita wrote:
> >> Hello, list. I want to propose generics. For those, who don't know
what
> it is, here's example: say we have a Comment class, that has a method
> getBody. Also we have Collection class, that implements Traversable.
Now,
> if I want to validate all insertions into collection of comments, I
would
> need to create CommentCollection class, extend it from Collection, and
> override all the methods that are dealing with adding new elements to
> collection. Moreover, I can't have any hints from my IDE about type of
> collection's elements, so if I'll have code like this:
> >> foreach ($commentCollection as $comment) {
> >>$comment->getBody();
> >> }
> >> There will be no way for IDE to know, of what type that object will
be.
> >>
> >> But there's how I could solve my problem with generics:
> >> class Collection implements Traversable
> >> {
> >>...
> >>public function add(T $element){}
> >> }
> >> $collection = new Collection();
> >>
> >> $collection->add(new Comment());
> >>
> >> $collection->add("that will be error");
> >>
> >> Actually, that's, again, all about type hinting. If we went so far
with
> scalar type hinting, then generics would also be a good addition.
> >>
> >> So, what you think?
> >
> > Personally I would hate to see this anywhere near PHP.
> >
> > -Rasmus
> >
> >
> > --
> > 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
>
>
Well, the example just shows what I've already got used to when working
with Java.
I like it and it would be of great help to me (especially in reducing
the
amount of code to be tested), but there's a lot more around that, like
multiple generic types (new Map()) and how reflection
would
deal with it...
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generics proposal
Hi Nikita,
What you're asking for is useful in other languages, but it doesn't match
the style of PHP which is to be a quick and easy type-less scripting
language.
What you're proposing is clearly more suited to something like Java or C#,
but doesn't really belong here.
I'd also hate to see this anywhere near PHP.
Many thanks,
Paul.
On Sat, Oct 20, 2012 at 11:10 PM, Marco Pivetta wrote:
> On 20 October 2012 23:09, Michael Stowe wrote:
>
> > I see what you're trying to do but not a big fan of how it's being
> > implemented in the example given.
> >
> > - Mike
> >
> > Sent from my iPhone
> >
> > On Oct 20, 2012, at 4:02 PM, Rasmus Lerdorf wrote:
> >
> > > On 10/20/2012 01:59 PM, Nikita wrote:
> > >> Hello, list. I want to propose generics. For those, who don't know
> what
> > it is, here's example: say we have a Comment class, that has a method
> > getBody. Also we have Collection class, that implements Traversable. Now,
> > if I want to validate all insertions into collection of comments, I would
> > need to create CommentCollection class, extend it from Collection, and
> > override all the methods that are dealing with adding new elements to
> > collection. Moreover, I can't have any hints from my IDE about type of
> > collection's elements, so if I'll have code like this:
> > >> foreach ($commentCollection as $comment) {
> > >>$comment->getBody();
> > >> }
> > >> There will be no way for IDE to know, of what type that object will
> be.
> > >>
> > >> But there's how I could solve my problem with generics:
> > >> class Collection implements Traversable
> > >> {
> > >>...
> > >>public function add(T $element){}
> > >> }
> > >> $collection = new Collection();
> > >>
> > >> $collection->add(new Comment());
> > >>
> > >> $collection->add("that will be error");
> > >>
> > >> Actually, that's, again, all about type hinting. If we went so far
> with
> > scalar type hinting, then generics would also be a good addition.
> > >>
> > >> So, what you think?
> > >
> > > Personally I would hate to see this anywhere near PHP.
> > >
> > > -Rasmus
> > >
> > >
> > > --
> > > 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
> >
> >
> Well, the example just shows what I've already got used to when working
> with Java.
> I like it and it would be of great help to me (especially in reducing the
> amount of code to be tested), but there's a lot more around that, like
> multiple generic types (new Map()) and how reflection would
> deal with it...
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
[PHP-DEV] Should "apc.slam_defence" and "apc.write_lock" be turned on at the same time?
Hi Internals I wondering if "apc.slam_defence" and "apc.write_lock" should be turned on at the same time? The default for APC v3.1.13 have both settings turned on. But the documentation says "apc.slam_defence is Deprecated by apc.write_lock." http://www.php.net/manual/en/apc.configuration.php#ini.apc.slam-defense So I'd like to know how should the settings be configured? Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
