Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion
Fair enough. I'm bias towards the C# annotation syntax, so that's my attraction to it. On Wed, Nov 17, 2010 at 1:49 AM, Dave Ingram wrote: > On 17/11/10 06:38, Will Fitch wrote: > > I like the idea, Alec. > > > > My only question is, syntactically, what difference would using a > keyword, > > in this case "attribute", as opposed to brackets "[]"? > I would say that it provides better searchability -- it's easier for > people new to the feature to recognise what it means, and to search for > how to use it. I for one didn't understand what []-style annotations > were when I first saw them, and had no idea how to find out what it meant. > > > D > > > > On Tue, Nov 16, 2010 at 9:38 PM, Alec Gorge wrote: > > > >> Ah, thanks. > >> > >> This is my proposed syntax and examples of it being used: > >> https://gist.github.com/702925 > >> > >> Here is my answer to those questions: > >> > >> - PHP code > >> - See the gist for syntax > >> - Return object instances of the annotation because then you can call > >> methods on the annotation if you need to (it think it would be useful) > >> - Can you APC cache ones that exist at compile time and then not cache > ones > >> that are created at runtime (since they are likely to change anyways, > >> request to request)? > >> - Method argument order to maintain consistency with PHP syntax. Named > >> arguments if PHP ever gets 'em. The grammar addition should use the > grammar > >> already there in the grammar file for calling methods so that it always > >> works with the new way of calling methods and functions. > >> - Yes for inherited metadata as long as you can filter it out (exactly > like > >> in the RFC). > >> > >> A another comment: > >> > >> getAnnotation($name) and getAnnotation($name, $type) both have to become > >> getAnnotations and then always return an array. This makes things more > >> consistent and allows for multiple metadata structures for each method. > >> > >> The gist I posted would be a fully working API (albeit very basic with > no > >> proper error/exception handling) if the url parsing code was put in, but > I > >> left it out for brevity. > >> > >> Opinions? > >> > >> -Alec > >> > >> > >> > >> > >> On 11/16/2010 9:39 PM, guilhermebla...@gmail.com wrote: > >> > >>> Hi Alec, > >>> > >>> Here is the quick list: > >>> - Where to put the metadata information? docblock or though php code? > >>> - Syntax (based on first decision) > >>> - Return would be an array or object instances > >>> - Compile time or run time (decision is more about APC being able to > >>> cache, but instances being created at runtime automatically or no APC > >>> cache but instances only being created when requested (during > >>> Reflection call) > >>> - Named variables for instantiation or method arguments order? How > >>> would we deal with the need of Reflector during constructor if second > >>> sounds better? > >>> - Would we support inherited metadata? > >>> > >>> Cheers, > >>> > >>> On Wed, Nov 17, 2010 at 12:33 AM, Alec Gorge > wrote: > >>> > In my opinion (as a person with 0 karma), I think that sounds > reasonable > because most people are most concerned about the actual implementation > (syntax, performance, apc etc) because I don't think many argue that > Metadata doesn't have value. > > What are the 5 different discussion topics you are thinking of, just > out > of > curiosity? > > Also, I can just post my syntax idea as a gist or pastie or something > instead of making an rfc... > > -Alec > > On 11/16/2010 9:29 PM, guilhermebla...@gmail.com wrote: > > > Hi Stas, > > > > Ok, so you think I should just consider everyone want some sort of > > meta attribute support and start discussing the topics? > > Should I separate it in different threads or put it all here? > > > > The subject is big and I identify at least 5 different discussions > > that can diverge. > > > > Cheers, > > > > On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshev< > smalys...@sugarcrm.com> > > wrote: > > > >> Hi! > >> > >> I'm able to write 10 RFC's, but none will care until we reach this > >>> list with a patch. > >>> > >> Not entirely true. Patch helps, but with feature this big and > complex > >> having > >> consensus on design before actually implementing it may be better > and > >> save > >> you some time. > >> As for polls, I think generic "having annotations" poll is not very > >> useful. > >> It's like having a poll "should we have cool features in PHP?" Of > >> course > >> we > >> should! The devil is in the details. And so far the details of this > >> thing > >> contain a significant number of devils we have to handle. > >> -- > >> Stanislav Malyshev, Software Architect > >> SugarCRM: http://www.sugarcrm.com/ > >> (408)454-6900 ext. 227 > >> > >> > >>> > >> -- > >>
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion
On Nov 17, 2010, at 4:29, "guilhermebla...@gmail.com" wrote: > Hi Stas, > > Ok, so you think I should just consider everyone want some sort of > meta attribute support and start discussing the topics? Of course not. Assuming meta support requires substantial additions of syntax then it's very far from consensus. A more productive approach would be coming up with ways to do it with existing functionality (maybe with some minor additions), which makes phpdoc a natural option to look at (even if it's not the incarnation of the perfect annotations solution). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion
On Wed, Nov 17, 2010 at 9:36 AM, Zeev Suraski wrote: > > On Nov 17, 2010, at 4:29, "guilhermebla...@gmail.com" < > guilhermebla...@gmail.com> wrote: > > > Hi Stas, > > > > Ok, so you think I should just consider everyone want some sort of > > meta attribute support and start discussing the topics? > > Of course not. Assuming meta support requires substantial additions of > syntax then it's very far from consensus. > > A more productive approach would be coming up with ways to do it with > existing functionality (maybe with some minor additions), which makes phpdoc > a natural option to look at (even if it's not the incarnation of the perfect > annotations solution). > > Zeev > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > http://www.mail-archive.com/internals@lists.php.net/msg47732.html you said that before. and this is where the discussion started about the alternative syntax and implementation. you said, that you see the usefulness, you just don't think that it worths the complexity and the new syntax. if that so, then I can't see, why can't we move on from the why is this useful to the how and what should we implement. in the end, it would only gets in to the trunk if the prominent coredevs(as you, Rasmus, etc.) accept it, so I don't know why are you afraid continuing the discussion about this feature. Tyrael
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion
I think everyone is jumping the gun on this. Let's let Alec, et al. finish the newly proposed RFC and then argue about it. If the consensus is still that the complexity and drag in the introduced syntax outweighs the benefits, we put it to bed or try again. Fair enough? On Wed, Nov 17, 2010 at 2:50 AM, Ferenc Kovacs wrote: > On Wed, Nov 17, 2010 at 9:36 AM, Zeev Suraski wrote: > > > > > On Nov 17, 2010, at 4:29, "guilhermebla...@gmail.com" < > > guilhermebla...@gmail.com> wrote: > > > > > Hi Stas, > > > > > > Ok, so you think I should just consider everyone want some sort of > > > meta attribute support and start discussing the topics? > > > > Of course not. Assuming meta support requires substantial additions of > > syntax then it's very far from consensus. > > > > A more productive approach would be coming up with ways to do it with > > existing functionality (maybe with some minor additions), which makes > phpdoc > > a natural option to look at (even if it's not the incarnation of the > perfect > > annotations solution). > > > > Zeev > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > http://www.mail-archive.com/internals@lists.php.net/msg47732.html > you said that before. > and this is where the discussion started about the alternative syntax and > implementation. > you said, that you see the usefulness, you just don't think that it worths > the complexity and the new syntax. > if that so, then I can't see, why can't we move on from the why is this > useful to the how and what should we implement. > in the end, it would only gets in to the trunk if the prominent coredevs(as > you, Rasmus, etc.) accept it, so I don't know why are you afraid continuing > the discussion about this feature. > > Tyrael > -- Thanks, Will Fitch Director of Operations | Quepasa.com 931.205.8242 | will.fi...@quepasacorp.com Twitter: twitter.com/willfitch
RE: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion
I’m not the only one in this thread repeating himself to make a point :) What I opposed is the notion that ‘everyone wants some sort of meta attribute support’. Maybe I read too much into it but I read it as implying we need something substantial that’s new. Either way, I’m fine with going in this way as long as the high-level-direction of not adding a large amount of syntax is clear. Zeev http://www.mail-archive.com/internals@lists.php.net/msg47732.html you said that before. and this is where the discussion started about the alternative syntax and implementation. you said, that you see the usefulness, you just don't think that it worths the complexity and the new syntax. if that so, then I can't see, why can't we move on from the why is this useful to the how and what should we implement. in the end, it would only gets in to the trunk if the prominent coredevs(as you, Rasmus, etc.) accept it, so I don't know why are you afraid continuing the discussion about this feature.
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On 17 November 2010 01:54, Stas Malyshev wrote: > Hi! > >> I would have no trouble accepting a rejection of annotations on the actual >> merits, but the interminable sequence of comparisons to phpdoc make it >> clear to me that people just don't realize the potential of annotations. > > People do realize the potential, what you and many "+1" voters seem to not > realize is the cost. You propose to add new syntax into PHP which is > completely different from all other syntax constructs in PHP - different > instantiation syntax, different method parameters syntax. > It's a full micro-language inside PHP. We discussed it already, but somehow > it failed to register. > >> Yes, it is new syntax and by itself that is undesirable. However, I see > > The problem is not new syntax per se. The problem is new syntax for things > that already have old syntax. I'm a +1 in terms of PHP having support for meta data. The issues that seem to be raised so far are: 1 - New syntax / micro-language / etc to learn 2 - Parser performance and new parser to code/develop/test 3 - APC cacheing of meta data. What if the meta data is just more PHP code? We all know PHP. The parser already works. APC already gets it op-codes. Nothing significantly new to learn/develop/test. With DocBlocks, the comments are relative to the element they are describing and are placed immediately before the item in question, with the exception of a file level docblock. Keeping with that, what if there was 1 new keyword; something like annotate or annotation. This keyword would operate in the same was as class. I don't know what the content of the annotation would be, but if I was asked to try and describe what an annotation looks like, based upon what I've seen, it looks like a set of consts. The items don't change, just like a const. Please bear in mind that I've not used annotations beyond docblocks and wsdl generation. So, maybe something like this ... >From this, I think there would need to be a few changes. 1 - "annotate" may not be enough, so maybe annotateFile, annotateClass, annotateFunction, annotateX, where is the element type being annotated - possibly/probably too much. 2 - Because some of suggestions on what annotations need to support includes nested data, a const would need to be allow for an array to be assigned. Personally, I think supporting a const array is a pretty useful idea. The advantages that I see here are hopefully fairly obvious. 1 - No new significant core changes. Essentially a new type of class. If annotateFile is the preferred route, then this obeys the rules like namespaces. Only 1 per file. As would annotateNamespace. 2 - The syntax is extremely familiar. 3 - There is nothing significantly new in the parser (naive assumption). 4 - APC would get the data in the same way as if it was a class or a namespace. 5 - Adding new elements to the annotation would involve absolutely no changes to core. You want to add meta data describing the COBOL picture format of a parameter or the regex validation rule that will be used, then fine. Nothing in the engine will change. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
Hello Internals! For me, as a user-land developer, this issue seems as if some people are trying to push the annotations at any cost. What they fail to see, is that annotations are never described what they are and how they can be useful in our developer work. Right now I, and I think many other user-land developers, just fail to see what the annotations are without any meaningful example. Right now I stand for ditching the annotations and schedule to return to them later, after 5.4 or whatever it will be. Right now there are more pressing things to deal with in PHP: * PDO is stuck in its development and mysqli & co are quite better developed. * tainted variables are a huge bonus but somehow they are stuck in the draft mode too (http://wiki.php.net/rfc/taint - hell, I wait for this getting into the PHP for a lng time and there are patches) * Traits are mostly discussed and probably need finishing touches. And these have a clear and understood benefit of being worked upon. Annotations now are just a big WTF. The fact that only a handful of developers reply to this thread (remember the type hinting thread - there where tons of reply's from many people) just shows that we as a com unity are not ready for annotations. Most of us just don't know that this is and how it's supposed to be used, Really, there is a ton of work to finish what is already has been started and needs attention. Type hints had the same story as annotations now. No easy agreement - ditched the discussion till next major version. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks wrote: > Hello Internals! > > For me, as a user-land developer, this issue seems as if some people > are trying to push the annotations at any cost. What they fail to see, > is that annotations are never described what they are and how they can > be useful in our developer work. Right now I, and I think many other > user-land developers, just fail to see what the annotations are > without any meaningful example. > > Right now I stand for ditching the annotations and schedule to return > to them later, after 5.4 or whatever it will be. > Right now there are more pressing things to deal with in PHP: > * PDO is stuck in its development and mysqli & co are quite better > developed. > * tainted variables are a huge bonus but somehow they are stuck in the > draft mode too (http://wiki.php.net/rfc/taint - hell, I wait for this > getting into the PHP for a lng time and there are patches) > * Traits are mostly discussed and probably need finishing touches. > And these have a clear and understood benefit of being worked upon. > Annotations now are just a big WTF. The fact that only a handful of > developers reply to this thread (remember the type hinting thread - > there where tons of reply's from many people) just shows that we as a > com unity are not ready for annotations. Most of us just don't know > that this is and how it's supposed to be used, > > Really, there is a ton of work to finish what is already has been > started and needs attention. Type hints had the same story as > annotations now. No easy agreement - ditched the discussion till next > major version. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I agree with you; there are more important issues than some "syntactic sugar", for example Large File Support, unicode support, pdo, pecl4win, optimizating the error handling (generating full backtrace and such for every error, which are just gets discarded/ignored, etc.), upload progress (I think APC provides this.), to name just a few from the top of my head. the only problem is, that they either hard, or boring to implement, or there isn't any agreement on them. my point is with this is that maybe there are more important features for you, or for me, but if nobody can/want working on those issues, why should we reject an improvement, which has actiove supporters? (they did write an RFC and patch, and they brought the issue to the list, so everybody can tell their opinion/concerns, and help to chose the best possible solution). So as long as the above mentioned problems are unsolved, we could reject every other improvement/addition, because there are more important, or older problems to solve. But I wont go to that direction, would you? Tyrael
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On Wed, Nov 17, 2010 at 12:54 PM, Ferenc Kovacs wrote: > > > On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks > wrote: > >> Hello Internals! >> >> For me, as a user-land developer, this issue seems as if some people >> are trying to push the annotations at any cost. What they fail to see, >> is that annotations are never described what they are and how they can >> be useful in our developer work. Right now I, and I think many other >> user-land developers, just fail to see what the annotations are >> without any meaningful example. >> >> Right now I stand for ditching the annotations and schedule to return >> to them later, after 5.4 or whatever it will be. >> Right now there are more pressing things to deal with in PHP: >> * PDO is stuck in its development and mysqli & co are quite better >> developed. >> * tainted variables are a huge bonus but somehow they are stuck in the >> draft mode too (http://wiki.php.net/rfc/taint - hell, I wait for this >> getting into the PHP for a lng time and there are patches) >> * Traits are mostly discussed and probably need finishing touches. >> And these have a clear and understood benefit of being worked upon. >> Annotations now are just a big WTF. The fact that only a handful of >> developers reply to this thread (remember the type hinting thread - >> there where tons of reply's from many people) just shows that we as a >> com unity are not ready for annotations. Most of us just don't know >> that this is and how it's supposed to be used, >> >> Really, there is a ton of work to finish what is already has been >> started and needs attention. Type hints had the same story as >> annotations now. No easy agreement - ditched the discussion till next >> major version. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > I agree with you; there are more important issues than some "syntactic > sugar", for example Large File Support, unicode support, pdo, pecl4win, > optimizating the error handling (generating full backtrace and such for > every error, which are just gets discarded/ignored, etc.), upload progress > (I think APC provides this.), to name just a few from the top of my head. > the only problem is, that they either hard, or boring to implement, or > there isn't any agreement on them. > > my point is with this is that maybe there are more important features for > you, or for me, but if nobody can/want working on those issues, why should > we reject an improvement, which has actiove supporters? (they did write an > RFC and patch, and they brought the issue to the list, so everybody can tell > their opinion/concerns, and help to chose the best possible solution). > > So as long as the above mentioned problems are unsolved, we could reject > every other improvement/addition, because there are more important, or older > problems to solve. > But I wont go to that direction, would you? > > On the other hand: it seems that more examples about the usage wouldn't hurt in the RFC... Tyrael
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On 15 November 2010 17:07, guilhermebla...@gmail.com
wrote:
> Hi folks,
>
> I'll start a series of topics (in this thread) about meta attribute
> (aka. Annotations) discussion.
> So as soon as we agree on each topic I'll open another point to be discussed.
> Only when we reach some consensus I'll open another topic discussion.
> I suggest to have a poll for each topic, so we can do some democratic
> internals decision. I'd reduce the scope of voters to only people with
> PHP karma.
>
> The first topic to be defined is: Does PHP need meta attribute support?
>
> Any language is built at the top of syntax, words, semantics and context.
> We cannot define it as a language if we don't have these 4 parts well
> fit together.
> For a simple sentence like: I am all ears, we can easily identify these parts.
> But the real meaning of this sentence (context) is only achieved with
> another part of the language: signifier-significate.
> A signifier is an atomic form, material element, visible, sensitive.
> A significate is an idea, semantic content, conceptual element, not
> sensitive perceptive.
>
> This important part is only reminded when we get back to semantics,
> specifically when talking about idiomatic expressions, a metaphor in
> our sample. The meaning will only work if we have the context, a known
> information. Our sentence would mean that spoker person only have
> ears, while the true meaning is that he/she is paying attention.
> A computer language doesn't differ from a language by any means. We
> have tokens (words), a syntax, semantic. But the lack of
> contextualization brings a hole on language and how your application
> should behave. This behavior can be achieved by many different ways;
> the simplest way is known as meta information.
>
> Considering you have a lack of idiomatic expressions knowledge of
> someone that is reading. He'd think person only have ears, but if you
> meta notify him that it is a metaphor, he'd try to find a different
> meaning. Example: (Metaphor) I am all ears.
>
> Now that we find how meta-information can benefit languages, it is
> time to understand how meta-information can benefit a computer
> language.
>
> A good example is define a Service that validates Domain Objects.
> Imagining a scenario where you have a User class that holds email and
> password. Email and password fields must be validated, for example,
> email as an email and password with at least 6 chars. A generic
> validation service could not have the User validation hardcoded inside
> the service, so the solution would be an external factor that explains
> to service how to validate the DO. One of the possible implementations
> would be a UserValidator class that contains validation rules for each
> field. This external factor is a good sample of meta-information. But
> how would a meta attribute would solve this situation?
> A Service could simple retrieve the validation instructions by
> Reflecting the class which instance is going to be validated.
> Basically, to validate a Domain Object, it is simply required to add
> validation rules on desired attributes. Example:
>
> class User {
>
> protected $email;
>
>
> protected $password;
> }
>
> *NOTE*: Please understand that this do not enter in any implementation
> details. It is not time (yet) to talk baout docblock, new syntax, etc.
> Scope now is simpler than that.
>
> Now that is possible to see how meta attribute support could benefit a
> language, I compiled a simple list of known projects and how can they
> benefit of meta support:
> - phpUnit Providing meta functionality for test cases, examples:
> @dataProvider for test data iteration, @expectedException for catching
> exceptions, etc.
> - Doctrine For Object-Relational mapping, examples: @Entity,
> @OneToOne, @Id, etc.
> - Zend Framework Server classes Used to automate mappings for XML-RPC,
> SOAP, etc.
> - FLOW3 for dependency injection and validation
> - Symfony2 for validation and routing rules
> - Others: Validation, Functional Behavior injection (which could take
> advantage of Traits), etc.
>
>
> Poll will be opened for voting for 7 days (1 week) starting from now.
> Poll will be closed next Monday at 5pm GMT.
> Question: Does PHP need meta attribute support?
>
+1 on this poll.
> Happy voting!
>
> --
> Guilherme Blanco
> Mobile: +55 (16) 9215-8480
> MSN: guilhermebla...@hotmail.com
> São Paulo - SP/Brazil
>
> --
> 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] Adding path_len to all stream functions in trunk
Is this related to http://www.ush.it/2009/02/08/php-filesystem-attack-vectors/ ? That's a quiet old bug, I'm happy to listen it's now worked on and has a patch. J.Pauli On Tue, Nov 16, 2010 at 12:34 PM, Pierre Joye wrote: > hi, > > On Tue, Nov 16, 2010 at 7:15 AM, Rasmus Lerdorf wrote: >> On 11/15/10 10:12 PM, Stas Malyshev wrote: >>> Hi! >>> Well, it changes the signature of that function, so while we don't break backward binary compatibility, we break forward compatibility within the 5.3 branch. As in, if I change my extension to use this new NoNull string flag, it will no longer work on<5.3.3 whereas if I do the if(strlen(filename) != filename_len) check, this will still work in all 5.3 releases. >>> >>> So if you have such extension, and you need to have it compatible with >>> previous versions (e.g. PECL one), use the check. That doesn't prevent >>> us from having the flag in the core code and thus keeping it cleaner. >> >> It still worries me a bit. Distros love to separate core extensions >> into separate packages and if you update one of those without updating >> the core package, it will break. Hopefully they have hard dependencies >> so you can't install php-curl-5.3.4 on php-5.3.3, for example. > > Same here, it is somehow a API incompatibility. We did similar changes > in the past and forced us to have two versions of extensions (afair it > was <5.2.5 and >=5.2.6). That was really painful and took years to get > rid of 5.2.5 support. > > I like the idea of having a (maybe not so perfect) solution for 5.3.x > using Rasmus patch and do it right in trunk. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.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
[PHP-DEV] Magic quotes in trunk
Greetings
I wanted to raise this topic before we go Alpha with trunk, regarding
our beloved magic_quotes feature. There seems to be mixed opinions
regarding it so I thought I would take it up for discussion.
We have advised people not to use magic_quotes, register_globals and
the like for years, and they were marked as deprecated in 5.3.0+ if
activated through their php.ini directives. Yet magic_quotes still is
set to "On" in 5.3.0. I think its worth we either remove the feature
or disable it in trunk as its a security related feature. Lets have a
look at what each of those options means:
Removing magic_quotes):
Means we will remove the feature entirely in the source, we will throw
an E_CORE_ERROR if activated so people who have it enabled are forced
to disable it and make their applications work without magic_quotes.
This creates a minor issue for the hosts that simply disable it and
have their customers applications run without them which can create a
security risk for them, although it should be fairly limited. The
functions to check for magic_quotes_runtime should however stay for BC
to avoid applications that run on multiple versions of PHP from doing:
if(function_exists('...') && ...)
Disabling them):
This will help to disable the spread of magic_quotes even more, and it
can safely be removed in the next major version of PHP.
My personal vote here goes towards removing them entirely.
What are your inputs on this matter?
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On Wed, Nov 17, 2010 at 5:08 PM, Kalle Sommer Nielsen wrote:
> Greetings
>
> I wanted to raise this topic before we go Alpha with trunk, regarding
> our beloved magic_quotes feature. There seems to be mixed opinions
> regarding it so I thought I would take it up for discussion.
>
> We have advised people not to use magic_quotes, register_globals and
> the like for years, and they were marked as deprecated in 5.3.0+ if
> activated through their php.ini directives. Yet magic_quotes still is
> set to "On" in 5.3.0. I think its worth we either remove the feature
> or disable it in trunk as its a security related feature. Lets have a
> look at what each of those options means:
>
> Removing magic_quotes):
> Means we will remove the feature entirely in the source, we will throw
> an E_CORE_ERROR if activated so people who have it enabled are forced
> to disable it and make their applications work without magic_quotes.
> This creates a minor issue for the hosts that simply disable it and
> have their customers applications run without them which can create a
> security risk for them, although it should be fairly limited. The
> functions to check for magic_quotes_runtime should however stay for BC
> to avoid applications that run on multiple versions of PHP from doing:
> if(function_exists('...') && ...)
>
> Disabling them):
> This will help to disable the spread of magic_quotes even more, and it
> can safely be removed in the next major version of PHP.
>
>
> My personal vote here goes towards removing them entirely.
>
>
> What are your inputs on this matter?
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
+1 for removing it.
Tyrael
Re: [PHP-DEV] Magic quotes in trunk
+1 for removing it in trunk
Pierrick
On 17 November 2010 11:08, Kalle Sommer Nielsen wrote:
> Greetings
>
> I wanted to raise this topic before we go Alpha with trunk, regarding
> our beloved magic_quotes feature. There seems to be mixed opinions
> regarding it so I thought I would take it up for discussion.
>
> We have advised people not to use magic_quotes, register_globals and
> the like for years, and they were marked as deprecated in 5.3.0+ if
> activated through their php.ini directives. Yet magic_quotes still is
> set to "On" in 5.3.0. I think its worth we either remove the feature
> or disable it in trunk as its a security related feature. Lets have a
> look at what each of those options means:
>
> Removing magic_quotes):
> Means we will remove the feature entirely in the source, we will throw
> an E_CORE_ERROR if activated so people who have it enabled are forced
> to disable it and make their applications work without magic_quotes.
> This creates a minor issue for the hosts that simply disable it and
> have their customers applications run without them which can create a
> security risk for them, although it should be fairly limited. The
> functions to check for magic_quotes_runtime should however stay for BC
> to avoid applications that run on multiple versions of PHP from doing:
> if(function_exists('...') && ...)
>
> Disabling them):
> This will help to disable the spread of magic_quotes even more, and it
> can safely be removed in the next major version of PHP.
>
>
> My personal vote here goes towards removing them entirely.
>
>
> What are your inputs on this matter?
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
RE: [PHP-DEV] Magic quotes in trunk
Yeah,
+1 for remove!
-
Uwe Schindler
theta...@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
> -Original Message-
> From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of Kalle
> Sommer Nielsen
> Sent: Wednesday, November 17, 2010 5:09 PM
> To: Internals
> Subject: [PHP-DEV] Magic quotes in trunk
>
> Greetings
>
> I wanted to raise this topic before we go Alpha with trunk, regarding our
> beloved magic_quotes feature. There seems to be mixed opinions regarding
it
> so I thought I would take it up for discussion.
>
> We have advised people not to use magic_quotes, register_globals and the
like
> for years, and they were marked as deprecated in 5.3.0+ if activated
through
> their php.ini directives. Yet magic_quotes still is set to "On" in 5.3.0.
I think its
> worth we either remove the feature or disable it in trunk as its a
security
> related feature. Lets have a look at what each of those options means:
>
> Removing magic_quotes):
> Means we will remove the feature entirely in the source, we will throw an
> E_CORE_ERROR if activated so people who have it enabled are forced to
> disable it and make their applications work without magic_quotes.
> This creates a minor issue for the hosts that simply disable it and have
their
> customers applications run without them which can create a security risk
for
> them, although it should be fairly limited. The functions to check for
> magic_quotes_runtime should however stay for BC to avoid applications that
> run on multiple versions of PHP from doing:
> if(function_exists('...') && ...)
>
> Disabling them):
> This will help to disable the spread of magic_quotes even more, and it can
> safely be removed in the next major version of PHP.
>
>
> My personal vote here goes towards removing them entirely.
>
>
> What are your inputs on this matter?
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> 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] Magic quotes in trunk
My opinion is to remove them completely. Big +1 from me. It is time for the feature to go. Olivier (iPhone) Le 2010-11-17 à 11:08, Kalle Sommer Nielsen a écrit : Greetings My personal vote here goes towards removing them entirely. What are your inputs on this matter? -- regards, Kalle Sommer Nielsen ka...@php.net -- 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] Magic quotes in trunk
+1 for removal, magic quotes stopped being a 'good' thing to do back when I first learnt what echo did. Web hosts etc have plenty of version numbers to catch up on/upgrade too before they get to this being a problem. (well most anyway) -Original Message- From: ka...@php.net [mailto:kalle@gmail.com] On Behalf Of Kalle Sommer Nielsen Sent: 17 November 2010 16:09 To: Internals Subject: [PHP-DEV] Magic quotes in trunk My personal vote here goes towards removing them entirely. What are your inputs on this matter? -- regards, Kalle Sommer Nielsen ka...@php.net -- 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
[PHP-DEV] Another question on traits
Hi, Simas' question yesterday lead me to take a look at the RFC on the wiki and I have a quick question. Specifically on the 'Rejected Features' -> 'Interfaces Propagation' section. So it sounds like implementing an interface directly with a trait has been shot down, what I wonder about is will it still work if a class implements an interface and uses a trait which provides the functions in said interface? An explicit way to leverage traits in the inheritance tree... Is that accurate, or will that not work either? thx, -nathan
Re: [PHP-DEV] Another question on traits
Hi Nathan:
On 17 Nov 2010, at 19:06, Nathan Nobbe wrote:
> So it sounds like implementing an interface directly with a trait has been
> shot down,
Yes, Traits are meant to be compile-time only, they are not used to introduce
typing relationships.
> what I wonder about is will it still work if a class implements
> an interface and uses a trait which provides the functions in said
> interface?
Yes, sure.
>
> interface IHello {
> public function sayHello();
> }
>
> trait SayHello {
> public function sayHello() {
>echo 'hello world';
> }
> }
This is a typical pattern I would expect to see in code that uses traits.
You have an interface and then you provide a trait thats provide a standard
implementation for that interface. I would probably call the trait similar to
the interface HelloImpl or THello or so.
>
> class MyHelloWorld implements IHello {
> use SayHello;
> }
>
> $o = new MyHelloWorld();
> var_dump($o instanceof IHello); // bool (true)
> ?>
If that does not work, it is a bug I think.
Best regards
Stefan
>
> thx,
>
> -nathan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)supportdiscussion
Now that's something we can agree on :D
We can reduce the syntax added to simply being the attribute tag before
the standard syntax for a function call/class creation.
This means functions can be attributes too (as if that is useful...)!
This is a function being used as an attribute
attribute functionAttr("test")
public function Test() {
...
or a class
attribute new ClassAttr("Test")
public function Test() {
...
Does that lower the syntax bar enough?
-Alec
On 11/17/2010 4:12 AM, Zeev Suraski wrote:
I’m not the only one in this thread repeating himself to make a point :)
What I opposed is the notion that ‘everyone wants some sort of meta attribute
support’. Maybe I read too much into it but I read it as implying we need
something substantial that’s new.
Either way, I’m fine with going in this way as long as the high-level-direction
of not adding a large amount of syntax is clear.
Zeev
http://www.mail-archive.com/internals@lists.php.net/msg47732.html
you said that before.
and this is where the discussion started about the alternative syntax and
implementation.
you said, that you see the usefulness, you just don't think that it worths the
complexity and the new syntax.
if that so, then I can't see, why can't we move on from the why is this useful
to the how and what should we implement.
in the end, it would only gets in to the trunk if the prominent coredevs(as
you, Rasmus, etc.) accept it, so I don't know why are you afraid continuing the
discussion about this feature.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and static methods
Hi Simas: Thanks for sending me the test cases. I checked them in, and surprise surprise: it actually was already completely implemented. I didn't had to touch any code... So the missing bit was being more explicit in the RFC. I added a section and an example based on your Singleton code. Now I also remember what the reference to the static modifier was about. You cannot use it to change it for a standard method. That means, if you have a normal method, you cannot make it static however, you can for instance make a public method private, or add an alias for it. That was what that statement was referring to. http://wiki.php.net/rfc/horizontalreuse Hope that helps Best regards Stefan On 17 Nov 2010, at 08:55, Stefan Marr wrote: > Hi Simas: > > On 17 Nov 2010, at 07:32, Simas Toleikis wrote: >> Alright then, I am sure someone will find more uses for static methods in >> Traits like factories/utilities (especially if traits can be made to work >> with late static binding). >> >> I assume this will be implemented in one way or another before or after >> first 5.4 alphas! :) > Send me the tests/phpt-files for it, and I will have a lock at it over the > weekend. > > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] building DTrace support (currently broken)
Hello php internals list, My name is Mike Harsch. I'm new here, so please set me straight on matters of etiquette and protocol. I've recently been spending a lot of time using the DTrace feature in the 5.3.99-dev code base (--enable-dtrace). I was disappointed to find out that Revision 305329 broke this feature severely. I have a patch (http://pastebin.com/SZnvz3L0) that fixes the problem by re-inserting some of the necessary functionality that was removed in 305329. This patch should be applied to Rev 305455 (very recent). I believe the primary confusion here is the platform-specific way in which DTrace USDT probes are compiled on the various platforms that have DTrace. Specifically, Solaris requires an intermediate compilation step, while Mac OS X does not. For details on how this is done on Solaris, see: http://dtrace.org/blogs/ahl/2006/05/08/user-land-tracing-gets-better-and-better/ and http://blogs.sun.com/dap/entry/writing_a_dtrace_usdt_provider For the Mac OS X way of doing this (much simpler), see the section "Building code containing USDT Probes" in the dtrace(1M) man page for Darwin: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/dtrace.1.html I've heard that FreeBSD has DTrace also, but I don't have any experience on that platform, so I can't comment on the procedure for building USDT probes there. I'm happy to help however I can to get this feature working again. I don't have much experience with autoconf, so it's likely that my patch is sub-optimal, but I've tested it on Solaris and Mac OS X and I know it works (conversely, I can assure you that --enable-dtrace is completely broken on both platforms as of 305329). Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding path_len to all stream functions in trunk
hi, If there is no objection I like to apply this patch to 5.3 tomorrow morning (Europe) so we have it in for 5.3.4RC1. Please raise your concerns until then. At the very least we can always revert it after RC1. Cheers, On Mon, Nov 15, 2010 at 11:42 AM, Rasmus Lerdorf wrote: > Ok, I went through all the 5.3 code. This should fix the null poisoning > problems in 5.3 without breaking binary compatibility: > > http://progphp.com/nullpatch.txt > > There are quite a few places where we can't solve it centrally, so > perhaps we need to take the same approach in trunk. > > This should take care of every issue mentioned here: > > http://www.madirish.net/?article=436 > > along with a number of bug reports. > > I think the only outstanding issue with the patch is whether to show an > error message when we hit a null in a filesystem path string. With the > Zend part of the patch, right now the error is slightly misleading for > code like this: > > $file = "foo.php\0"; > include $file . ".png"; > > This will output: > > PHP Warning: include(): Failed opening 'foo.php' for inclusion > (include_path='.:') in foo on line 3 > > Without this patch, this code will of course simply include the foo.php > file and ignore the .png extension. > > -Rasmus > > On 11/14/10 9:35 PM, Andi Gutmans wrote: >> Hi Rasmus, >> >> Hope I understood the problem correctly. If not, this answer won't make >> sense :) >> I do not see a major problem in passing path_len but wonder how much it'd >> actually solve as we end up calling OS APIs that do not accept path_len, no? >> I assume we don't want to start searching all these strings for invalid >> chars before we pass them to the OS. >> >> Andi >> >>> -Original Message- >>> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >>> Sent: Sunday, November 14, 2010 11:54 AM >>> To: internals >>> Subject: [PHP-DEV] Adding path_len to all stream functions in trunk >>> >>> I think we need to pass along the string length to all the stream functions >>> to >>> maintain binary string safety through this code. This would fix annoying >>> problems like http://bugs.php.net/39863 and a bunch of similar issues. >>> Obviously not something we can do in 5.3 without breaking binary >>> compatibility >>> though. Although we might be able to do something if we assume only chars >>> valid in the current charset is valid in file paths. >>> >>> Anybody have any other thoughts on this one? >>> >>> -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 > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On 18 November 2010 00:08, Kalle Sommer Nielsen wrote: > What are your inputs on this matter? +1 for removing magic quotes completely from trunk. Kill it with fire. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
+1 for removal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
+1 for removal On Wed, Nov 17, 2010 at 10:50 PM, Stanley Sufficool wrote: > +1 for removal > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] building DTrace support (currently broken)
On 11/17/2010 03:40 PM, Mike Harsch wrote: I'm happy to help however I can to get this feature working again. I don't have much experience with autoconf, so it's likely that my patch is sub-optimal, but I've tested it on Solaris and Mac OS X and I know it works (conversely, I can assure you that --enable-dtrace is completely broken on both platforms as of 305329). Cheers, Mike Mike, Can you log a bug for this at http://bugs.php.net/report.php ? Thanks, Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On 11/17/2010 8:46 PM, Adam Harvey wrote: On 18 November 2010 00:08, Kalle Sommer Nielsen wrote: What are your inputs on this matter? +1 for removing magic quotes completely from trunk. Kill it with fire. Adam +infinity. Burn baby burn. (Hudson Ford reference intended...unless that makes me too old.) -- Thomas Hruska CubicleSoft President Barebones CMS is a high-performance, open source content management system for web developers operating in a team environment. An open source CubicleSoft initiative. Your choice of a MIT or LGPL license. http://barebonescms.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On Wednesday, November 17, 2010 5:56:05 am Ferenc Kovacs wrote: > On Wed, Nov 17, 2010 at 12:54 PM, Ferenc Kovacs wrote: > > On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks > > > > > > wrote: > >> Hello Internals! > >> > >> For me, as a user-land developer, this issue seems as if some people > >> are trying to push the annotations at any cost. What they fail to see, > >> is that annotations are never described what they are and how they can > >> be useful in our developer work. Right now I, and I think many other > >> user-land developers, just fail to see what the annotations are > >> without any meaningful example. *snip* > On the other hand: it seems that more examples about the usage wouldn't > hurt in the RFC... > > Tyrael I have to agree with this sentiment in particular. As I've not worked in a language with formal annotations, I still don't grok the use case. To those supporting some form of syntactic annotations (whatever the syntax), can you please explain, simply and preferably with examples, what I could do with such syntax that I cannot do now in user-space, and/or what I could do better/faster/cheaper with such tools than what I can do now in user-space? I think that's the missing piece here: The practical ever-day example of how *my* code would get better because of annotations. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
> What are your inputs on this matter? I'm struggling with this topic. We must do something, but it's important to understand that plenty of people unknowingly rely upon this security feature that's still enabled by default. Granted 5.3 does generate E_DEPRECATED errors when magical quotes are enabled, but is one minor PHP version of errors enough to go from on to gone? So while those in the know (e.g., people who follow this list) find them annoying and wish they never existed, what are the implications? I'm still unsure how best to handle this situation but wanted to express these feelings now. Whatever the case, the education effort towards data filtering and sanitization requires a lot of improvement. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On Wednesday, November 17, 2010 11:19:05 pm Philip Olson wrote: > > What are your inputs on this matter? > > I'm struggling with this topic. We must do something, but it's important to > understand that plenty of people unknowingly rely upon this security > feature that's still enabled by default. Granted 5.3 does generate > E_DEPRECATED errors when magical quotes are enabled, but is one minor PHP > version of errors enough to go from on to gone? > > So while those in the know (e.g., people who follow this list) find them > annoying and wish they never existed, what are the implications? I'm still > unsure how best to handle this situation but wanted to express these > feelings now. Whatever the case, the education effort towards data > filtering and sanitization requires a lot of improvement. > > Regards, > Philip I won't miss magic quotes if they're removed, but I can see the argument for saying "not quite yet". Off-by-default is absolutely necessary if they're kept. (Dear god, you mean they aren't off by default already?) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] building DTrace support (currently broken)
Mike, Can you log a bug for this at http://bugs.php.net/report.php ? Certainly. Here it is: http://bugs.php.net/bug.php?id=53338 Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On Nov 17, 2010, at 9:40 PM, Larry Garfield wrote: > On Wednesday, November 17, 2010 11:19:05 pm Philip Olson wrote: >>> What are your inputs on this matter? >> >> I'm struggling with this topic. We must do something, but it's important to >> understand that plenty of people unknowingly rely upon this security >> feature that's still enabled by default. Granted 5.3 does generate >> E_DEPRECATED errors when magical quotes are enabled, but is one minor PHP >> version of errors enough to go from on to gone? >> >> So while those in the know (e.g., people who follow this list) find them >> annoying and wish they never existed, what are the implications? I'm still >> unsure how best to handle this situation but wanted to express these >> feelings now. Whatever the case, the education effort towards data >> filtering and sanitization requires a lot of improvement. >> >> Regards, >> Philip > > I won't miss magic quotes if they're removed, but I can see the argument for > saying "not quite yet". Off-by-default is absolutely necessary if they're > kept. (Dear god, you mean they aren't off by default already?) > > --Larry Garfield This is true. And in addition to the E_DEPRECATED error, it's worth mentioning that 5.3 includes two optional php.ini-* files (php.ini-production and php.ini-development) that disable magic quotes. But of course not everyone uses these, and "default" is how PHP behaves without a php.ini file. Older versions of PHP include php.ini-dist (On) and php.ini-recommended (Off). Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Magic quotes in trunk
> -Original Message- > From: Larry Garfield [mailto:la...@garfieldtech.com] > Sent: Thursday, November 18, 2010 7:41 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Magic quotes in trunk > > On Wednesday, November 17, 2010 11:19:05 pm Philip Olson wrote: > > > What are your inputs on this matter? > > > > I'm struggling with this topic. We must do something, but it's > > important to understand that plenty of people unknowingly rely upon > > this security feature that's still enabled by default. Granted 5.3 > > does generate E_DEPRECATED errors when magical quotes are enabled, > but > > is one minor PHP version of errors enough to go from on to gone? > > > > So while those in the know (e.g., people who follow this list) find > > them annoying and wish they never existed, what are the implications? > > I'm still unsure how best to handle this situation but wanted to > > express these feelings now. Whatever the case, the education effort > > towards data filtering and sanitization requires a lot of improvement. > > > > Regards, > > Philip > > I won't miss magic quotes if they're removed, but I can see the argument for > saying "not quite yet". Off-by-default is absolutely necessary if they're > kept. > (Dear god, you mean they aren't off by default already?) The voice of reason... As much as I'd like to see magic quotes burning in hell (had the option to kill them when they were small, but unfortunately didn't), I'm wondering whether the people +1'ing are thinking about the potential consequences to doing this, and if they're also volunteering to respond (nicely!!) to the endless complaints, flames, and just general "what happened???!!!" mailing list emails that may flood us when this happens. With 6.0, we talked about having prepend-scripts that emulate magic quotes available, since like it or not - there are probably billions of lines of code out there that rely on the existence of magic quotes. I don't have a strong opinion on whether we should remove magic quotes altogether in 5.4 and provide emulation instructions, or just disable it by default as a first step. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On 18 November 2010 15:22, Zeev Suraski wrote: > As much as I'd like to see magic quotes burning in hell (had the option to > kill them when they were small, but unfortunately didn't), I'm wondering > whether the people +1'ing are thinking about the potential consequences to > doing this, and if they're also volunteering to respond (nicely!!) to the > endless complaints, flames, and just general "what happened???!!!" mailing > list emails that may flood us when this happens. With 6.0, we talked about > having prepend-scripts that emulate magic quotes available, since like it or > not - there are probably billions of lines of code out there that rely on the > existence of magic quotes. I already help support users on IRC — good support channels have been recommending against the use of magic quotes for ages anyway. Yes, killing magic quotes will likely increase the support workload for a time, but I do think it's worth it because in the longer run it'll force people to write better code. Having it deprecated in the 5.3 series seems like sufficient warning to me. At any rate, pulling the trigger and removing it from trunk will help get the word out long before 5.4 has a stable release. I mean, I take the point about it seeming sudden from a userland perspective, but I just think the pros (vastly) outweigh the cons here. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
