Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
Was it considered to augment type hinting syntax - both in parameter lists and for the hinted property RFC - to permit giving multiple types at once? public DateTime|DateTimeImmutable $refdate; public Foo|NULL $object; // the issue discussed in the previous msgs function bar(array|string $arg) ... best regards Patrick
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
On 06.01.2013, at 6:38, Stas Malyshev smalys...@sugarcrm.com wrote: Following the recent discussion on the list, I've drafted an RFC describing the CurlFile solution for it here: https://wiki.php.net/rfc/curl-file-upload Please review and comment. If there's a general positive feedback, I'll try to implement a patch for it pretty soon. Looks elegant and extensible. Great work! -- Alexey Zakhlestin https://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
On 06.01.13 06:38, Stas Malyshev wrote: https://wiki.php.net/rfc/curl-file-upload Please review and comment. If there's a general positive feedback, I'll try to implement a patch for it pretty soon. Looks solid to me. One thing though: The manual spells the extension cURL and so does http://curl.haxx.se/. Shouldn't the new class then be called CURLFile instead of CurlFile? - Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Providing improved functionality for escaping html (and other) output.
On Sat, Jan 5, 2013 at 6:26 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
It's important to escape output according to context. PHP provides
functions such as htmlspecialchars() to escape output when the context
is HTML. However, one often desires to allow some subset of HTML
through without escaping (e.g., br /, b/b, etc.)
I think what you are looking for is HtmlPurifier and such. Doing it in
the core properly would be pretty hard.
Hi Stas,
HtmlPurifier is a fantastic tool, but it offers far more than I
typically need/want (e.g., CSS validation, attempting to remove
malicious code, fixes to illegal nesting, etc.) I guess I'm wondering
about something that allows more through than htmlspecialchars()
through some form of whitelisting, but not as much through as
strip_tags() (as noted, attributes can be problematic.)
https://github.com/AdamJonR/nephtali-php-ext/blob/master/nephtali.c
Could you describe in detail what that function actually does, with
examples?
Sure!
Function:
// Example userland code commented to explain the flow:
function str_escape_html($string, $allowed_html = array(), $charset = 'UTF-8')
{
// use htmlspecialchars because it only does the 5 most important
chars, and doesn't mess them up
// start out safely by ensureing everything is html escaped
(whitelisting approache)
$escaped_string = htmlspecialchars($string, ENT_QUOTES, $charset);
// check if there are whitelisted sequences which, if present, we
can safely revert
if ($allowed_html) {
// cycle through the whitelisted sequences
foreach($allowed_html as $sequence) {
// Save escaped version of sequence so we know what to revert safely
// This also works for regexes fairly well because , , ,
', , don't have special meaning in regexes, but character sets cause
trouble, something I've just learned to work around
// http://php.net/manual/en/regexp.reference.meta.php
$escaped_sequence = htmlspecialchars($sequence, ENT_QUOTES, $charset);
// if the sequence begins and ends with a '/', treat it as a regex
if (($sequence[0] == '/') ($sequence[strlen($sequence) -
1] == '/')) {
// revert regex matches
$escaped_string = preg_replace_callback($escaped_sequence,
function($matches){return html_entity_decode($matches[0]);},
$escaped_string);
// otherwise, treat it as a standard string sequence
} else {
// revert string sequences
$escaped_string = str_replace($escaped_sequence,
$sequence, $escaped_string);
}
}
}
return $escaped_string;
}
$input = 'div class=expectedb onclick=alert(\'Oh no!\')click
me/bbr id=whyIdMe /b class=emphasizedo not click the other
bolded text/b/div';
$draconian_bold_tag_regex = '/b( class=([a-z]+))?[a-zA-Z_.,! ]+\/b/';
echo strip tags: . strip_tags($input, 'bdivbr') . br /br /;
echo htmlspecialchars: . htmlspecialchars($input, ENT_QUOTES,
'UTF-8') . br /br /;
echo str_escape_html: . str_escape_html($input,
array($draconian_bold_tag_regex, 'br /', 'div class=expected',
'/div'), 'UTF-8');
Problems with above implementation:
Regexing large chunks of HTML is a pain, and easy to get wrong.
Additionally, you have to enter both the opening and closing tag in
the whitelist separately for literals, and character sets can break
things due to the escaping (e.g., [^].)
Solutions:
What I'm looking to build is functionality that adds to
htmlspecialchars by implementing whitelisting through some primitive
parsing (identify the tags without regard for validating HTML, similar
to strip_tags) and some regexing (validate attribute contents) using a
similar approach to the above function. The new function would better
break up the tag components, making the required regexes much easier
to work with.
For example:
$new = str_escape_html(a class='important' href='test'Test/a, array(
'a' = [
'href' = '/^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w
\.-]*)*\/?$/' // strings beginning and ending with '/' are considered
regexes
'class' = 'important' // other strings are just evaluated as literals
],
'br' = [] // has no allowed attributes
), UTF-8);
Conclusion:
Bridging the gap between strip_tags and htmlspecialchars seems like a
reasonable consideration for PHP's core. While I do use HTMLPurifier
or other tools for more involved HTML processing, I often wish the
core had something just a bit more flexible than htmlspecialchars, but
just a bit more protective than strip_tags that I could use for my
typical escaping needs. I'm going to spend some time refining this
approach in an extension, but I was looking for feedback before
proceeding further.
Thanks,
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Providing improved functionality for escaping html (and other) output.
Hi!
if ($allowed_html) {
// cycle through the whitelisted sequences
foreach($allowed_html as $sequence) {
What is supposed to be in $allowed_html? If those are simple fixed
strings and such, why can't you just do preg_split with
PREG_SPLIT_DELIM_CAPTURE and encode each other element of the result, or
PREG_SPLIT_OFFSET_CAPTURE if you need something more interesting?
I would seriously advise though against trying to do HTML parsing with
regexps unless they are very simple, since browsers will accept a lot of
broken HTML and will happily run scripts in it, etc.
Bridging the gap between strip_tags and htmlspecialchars seems like a
reasonable consideration for PHP's core. While I do use HTMLPurifier
I think with level of complexity that is needed to cover anything but
the most primitive cases, you need a full-blown HTML/XML parser there.
Which we do have, so why not use any of them instead of reinventing
them, if that's what you need?
--
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] [RFC] Alternative typehinting syntax for accessors
On Sun, Jan 6, 2013 at 10:05 AM, Patrick Schaaf p...@bof.de wrote: Was it considered to augment type hinting syntax - both in parameter lists and for the hinted property RFC - to permit giving multiple types at once? public DateTime|DateTimeImmutable $refdate; public Foo|NULL $object; // the issue discussed in the previous msgs function bar(array|string $arg) ... best regards Patrick That's an interesting idea (at least something worth discussion), but please in a different thread. Same goes to the initializers that were mentioned previously in this thread. Both things are related to this proposal, but only slightly, and should be discussed separately to keep things clean. Thanks :) Nikita
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On Sun, Jan 6, 2013 at 2:59 AM, Stas Malyshev smalys...@sugarcrm.comwrote: This is pretty bad by itself. But the fact that everybody would be using this feature in this way - since they would think I don't need null default, null is always the default and I'd initialize it in the ctor anyway, not realizing that declaring public DateTime $foo blocks unset - is even worse. At least with setter you need to explicitly define typehinted setter - and there you have a place to think about it. With public DateTime $foo 99% of people would never even remember to think about it - until they'd start getting mysterious fatal errors on unsets. That's why I think it makes it worse. In this mail I'm only going to address the unset() concern. First of all it should be made clear that contrary to the impression that you conveyed unset() is a fallible operation. It absolutely is fallible, even when overloaded properties and offset (__unset/offsetUnset) are not involved. If I write `unset($foo[0])` then this is an operation that can throw a fatal error, for example when $foo is a string. Why does this throw a fatal error? Because a string offset can not be unset. It's an operation that does not make sense and so PHP throws an error. PHP could also just do nothing, leave the string intact and pretend the unset() was successful. But it doesn't do so and it's good that it doesn't do so. What we are talking about here is a similar situation. We are talking about a property where it does not make sense to unset it. The unset operation is not meaningful and as such shouldn't be allowed. It's as easy as that. That's the first point. The second point is that even *if* an issue existed here (which it does not) then you are presenting it in a *totally* disproportional matter. You make it seem like unset()ing properties is this super important operation that we do all the time and the world would collapse if it failed. That's not true. Unset() on object properties is only used *very* rarely. Symfony Standard (including Symfony, Doctrine, Twig, ...) has a total of !! 4 !! property unsets (compare this to their ~3800 accessor methods). The ZF2 has 8 property unsets of which only !! 3 !! are targeted at specific properties (the remaining 5 are on stdClass-like objects). Again, compare this to their ~4k accessor methods. In summary: a) Unset() is a fallible operation, it's okay if it throws an error if the unset is not reasonably possible. b) Even if you *don't* agree with this assessment it's quasi a non-issue as property unsets are incredibly rare. Dismissing a feature based on something like this is absolutely implausible. c) You can always allow unset() and NULL assignment by specifying it as the default value. Not hard to do *should* you once run into issues of this kind. Thanks, Nikita
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
Hi Stas, Am 06.01.2013 um 06:38 schrieb Stas Malyshev smalys...@sugarcrm.com: [...] Following the recent discussion on the list, I've drafted an RFC describing the CurlFile solution for it here: https://wiki.php.net/rfc/curl-file-upload Please review and comment. If there's a general positive feedback, I'll try to implement a patch for it pretty soon. Couldn’t CurlFile extend SplFileInfo? Otherwise it looks good. cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset failable
Bringing up this old issue a bit.
Nothing was ever said of unset? Should unset be benign?
Since unset() is intended to take an action (rather than check on state)
shouldn't an invalid unset (one with a guarded property that doesn't
have a setter) emit a warning?
On 10/30/2012 10:37 PM, Clint Priest wrote:
Would you say the same of unset? Always benign?
On 10/29/2012 2:14 PM, Stas Malyshev wrote:
Hi!
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this-b = $x; }
}
}
$o = new a();
if(!isset($o-b)) {
/* delete files */
}
echo (int)isset($o-b); /* This should return false and not emit any
sort of warning/notice? */
isset should return false, since $b is not set value. It should not
produce any warning. Of course (int) would produce 0 then ;)
I mean specifically, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing execution
No, the result is determinate - it's false. That's the point of isset()
in PHP and that's how it is used in existing code.
to stop I don't see it being a good idea to not warn the developer that
what they've attempted is not correct. Without a getter, isset() is
not a legal call (since the value cannot be retrieved).
isset() should always be legal. This is the way to check if $o-b is
legal.
--
-Clint
Re: [PHP-DEV] Providing improved functionality for escaping html (and other) output.
On Sun, Jan 6, 2013 at 6:13 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
What is supposed to be in $allowed_html? If those are simple fixed
strings and such, why can't you just do preg_split with
PREG_SPLIT_DELIM_CAPTURE and encode each other element of the result, or
PREG_SPLIT_OFFSET_CAPTURE if you need something more interesting?
I like to start out conservatively, with everything in a safe (i.e.,
fully escaped) state, and then revert from there. If something slips
through, it slips through in a conservative state.
I would seriously advise though against trying to do HTML parsing with
regexps unless they are very simple, since browsers will accept a lot of
broken HTML and will happily run scripts in it, etc.
I agree, that's why I proposed an improved approach in which regexes
would only optionally be used to validate attributes.
I think with level of complexity that is needed to cover anything but
the most primitive cases, you need a full-blown HTML/XML parser there.
Which we do have, so why not use any of them instead of reinventing
them, if that's what you need?
I don't think the simple state machine utilized by strip_tags() is a
full-blown HTML/XML parser, yet I find it does provide practical
value. Merging this type of state machine with the ability to check
attributes (via literal string or regex) would be an incremental step
beyond what is present now, and would prove practically beneficial.
I gave this example as one way to implement this approach through an API:
$new = str_escape_html(a class='important' href='test'Test/a, array(
'a' = [
'href' =
'/^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w\.-]*)*\/?$/',
'class' = 'important'
],
'br' = []
), UTF-8);
The idea is that a string would first be escaped using
htmlspecialchars, a state machine similar to that used by strip_tags
would parse the text for the escaped form of tags. When whitelisted
tags are encountered, their attributes are checked against string
literals or regexes. If the tag and its attributes match the
whitelisted form, the tag sequence is unescaped.
One could also augment the strip_tags() function so the whitelist
items could include the ability to only allow specific attributes
through:
$new = strip_tags(a class='important' href='test'Test/a, a
:class :url);
The colon-prepended symbols could allow predefined attributes
according to a regex. Any unlisted attributes would be stripped.
Thank you for the feedback, Stas.
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Reflection annotations reader
Hi internals! In one of the discussions (about the deprecated keyword, to be specific), it was been said that adding ability to read doc-comment annotation could be handy. Personally, I really think it can be great. So, I've created an RFC that propose to improve the Reflection extension by adding the ability to read annotations decorated in the doc-comment. https://wiki.php.net/rfc/reflection_doccomment_annotations What is your opinion about this? Regards, Yahav.
Re: [PHP-DEV] [RFC] Reflection annotations reader
Hi there, It would be great to have such a feature in reflection itself, since it would speed up parsing by a huge lot. Anyway, I noticed that the proposed syntax is quite different from the one adopted by Doctrine\Common (therefore by Drupal, Symfony, Typo3, ZF, etc.), which would probably make it a bit hard to migrate for existing apps. If you check the doc comments of https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations/DocParser.phpyou will find the EBNF of the currently used implementation. I'd really love to see this happening! Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 6 January 2013 22:58, Yahav Gindi Bar g.b.ya...@gmail.com wrote: Hi internals! In one of the discussions (about the deprecated keyword, to be specific), it was been said that adding ability to read doc-comment annotation could be handy. Personally, I really think it can be great. So, I've created an RFC that propose to improve the Reflection extension by adding the ability to read annotations decorated in the doc-comment. https://wiki.php.net/rfc/reflection_doccomment_annotations What is your opinion about this? Regards, Yahav.
Re: [PHP-DEV] [RFC] Reflection annotations reader
Hi Yahav, Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar g.b.ya...@gmail.com: [...] In one of the discussions (about the deprecated keyword, to be specific), it was been said that adding ability to read doc-comment annotation could be handy. Personally, I really think it can be great. So, I've created an RFC that propose to improve the Reflection extension by adding the ability to read annotations decorated in the doc-comment. https://wiki.php.net/rfc/reflection_doccomment_annotations What is your opinion about this? From what I've seen in various components using annotations, this kind of support wouldn’t be enough. I would much prefer direct mapping of a single annotation on a class including a way to define properties and such. This is how e.g. Doctrine, Symfony, Zend Framework etc. all utilize annotations nowadays. cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reflection annotations reader
On Mon, Jan 7, 2013 at 12:24 AM, Lars Strojny l...@strojny.net wrote: Hi Yahav, Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar g.b.ya...@gmail.com: [...] In one of the discussions (about the deprecated keyword, to be specific), it was been said that adding ability to read doc-comment annotation could be handy. Personally, I really think it can be great. So, I've created an RFC that propose to improve the Reflection extension by adding the ability to read annotations decorated in the doc-comment. https://wiki.php.net/rfc/reflection_doccomment_annotations What is your opinion about this? Hi! I do agree with you two about the difference between my proposal and the way that Doctorine and other FW implemented that, and as I've told - its a first draft of the proposal - the main idea is to get the ability to have static metadata. I'll implement the actual patch after we'll agree on the way it should work :). About Doctorine implementation, firstly - the parser code is... hugh, I really think that we should do something about that! However, I don't think that we should make, like their implementation - ability to create constructors and such, otherwise, it'll look just like Attributes... I think that our work is to isolate each annotation so it'll be easy to access, then, it'll be easy enough to write the code that creates complex annotations, such as constructors and so on, in userland. From what I've seen in various components using annotations, this kind of support wouldn’t be enough. I would much prefer direct mapping of a single annotation on a class including a way to define properties and such. This is how e.g. Doctrine, Symfony, Zend Framework etc. all utilize annotations nowadays. Can you provide an example? cu, Lars
Re: [PHP-DEV] [RFC] Reflection annotations reader
I think that our work is to isolate each annotation so it'll be easy to access, then, it'll be easy enough to write the code that creates complex annotations, such as constructors and so on, in userland. In fact, there's probably no need (now) to go on and build a full annotation reader that instantiates classes and does fancy stuff as we currently do in doctrine/common. A fast parser is more than enough I suppose. That's our bottleneck (besides scanning files). Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Reflection annotations reader
On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com wrote: I think that our work is to isolate each annotation so it'll be easy to access, then, it'll be easy enough to write the code that creates complex annotations, such as constructors and so on, in userland. In fact, there's probably no need (now) to go on and build a full annotation reader that instantiates classes and does fancy stuff as we currently do in doctrine/common. A fast parser is more than enough I suppose. That's our bottleneck (besides scanning files). Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ So the problem is the syntax which is difference? When wrote this RFC, I just though about basic cases... Though I agree with you that the main problem is the syntax. We can extract the entire doc-comment and only isolate between annotations, so doc-comment like: /** * @Route(/) * @ORM(Key=foo) * @var string */ Will be : array( 'Route(/)' = , 'ORM(Key=foo)' = , var = string ) But the question is it really worth it, since you'll probably need to create some sort of sub-parser that uses this isolated annotations array and apply on them your syntax. That's being said, if we'll see performance improvements, I really think that it's a good solution to start with, since because its not an Attributes, I don't think that we should dictate the syntax for each application. Each application will get the doc-comment annotation and will be able to apply on it its own syntax and fancy stuff... I think that it's the best solution because of BC too. What do you think?
Re: [PHP-DEV] [RFC] Reflection annotations reader
2013/1/6 Yahav Gindi Bar g.b.ya...@gmail.com On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com wrote: I think that our work is to isolate each annotation so it'll be easy to access, then, it'll be easy enough to write the code that creates complex annotations, such as constructors and so on, in userland. In fact, there's probably no need (now) to go on and build a full annotation reader that instantiates classes and does fancy stuff as we currently do in doctrine/common. A fast parser is more than enough I suppose. That's our bottleneck (besides scanning files). Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ So the problem is the syntax which is difference? When wrote this RFC, I just though about basic cases... Though I agree with you that the main problem is the syntax. We can extract the entire doc-comment and only isolate between annotations, so doc-comment like: /** * @Route(/) * @ORM(Key=foo) * @var string */ Will be : array( 'Route(/)' = , 'ORM(Key=foo)' = , var = string ) But the question is it really worth it, since you'll probably need to create some sort of sub-parser that uses this isolated annotations array and apply on them your syntax. As a suggestion, that should cover most (all?) cases: The identifier could be defined as between @ and the first non-alphanumeric character (it should probably allow some special like /, or \ to allow namespace-like annotations). @Route(/) would be array( 'Route' = '(/)'. Now a secondary parser only needs to take care about (/), but for example it can already directly test, whether or not the annotation exists. That's being said, if we'll see performance improvements, I really think that it's a good solution to start with, since because its not an Attributes, I don't think that we should dictate the syntax for each application. Each application will get the doc-comment annotation and will be able to apply on it its own syntax and fancy stuff... I think that it's the best solution because of BC too. To throw that in: Multiline-annotations must be taken into account too :) Regards, Sebastian What do you think? -- github.com/KingCrunch
Re: [PHP-DEV] [RFC] Reflection annotations reader
-Clint On Jan 6, 2013, at 5:11 PM, Sebastian Krebs krebs@gmail.com wrote: 2013/1/6 Yahav Gindi Bar g.b.ya...@gmail.com On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com wrote: I think that our work is to isolate each annotation so it'll be easy to access, then, it'll be easy enough to write the code that creates complex annotations, such as constructors and so on, in userland. In fact, there's probably no need (now) to go on and build a full annotation reader that instantiates classes and does fancy stuff as we currently do in doctrine/common. A fast parser is more than enough I suppose. That's our bottleneck (besides scanning files). Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ So the problem is the syntax which is difference? When wrote this RFC, I just though about basic cases... Though I agree with you that the main problem is the syntax. We can extract the entire doc-comment and only isolate between annotations, so doc-comment like: /** * @Route(/) * @ORM(Key=foo) * @var string */ Will be : array( 'Route(/)' = , 'ORM(Key=foo)' = , var = string ) But the question is it really worth it, since you'll probably need to create some sort of sub-parser that uses this isolated annotations array and apply on them your syntax. As a suggestion, that should cover most (all?) cases: The identifier could be defined as between @ and the first non-alphanumeric character (it should probably allow some special like /, or \ to allow namespace-like annotations). @Route(/) would be array( 'Route' = '(/)'. Now a secondary parser only needs to take care about (/), but for example it can already directly test, whether or not the annotation exists. That's being said, if we'll see performance improvements, I really think that it's a good solution to start with, since because its not an Attributes, I don't think that we should dictate the syntax for each application. Each application will get the doc-comment annotation and will be able to apply on it its own syntax and fancy stuff... I think that it's the best solution because of BC too. To throw that in: Multiline-annotations must be taken into account too :) Regards, Sebastian What do you think? -- github.com/KingCrunch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reflection annotations reader
Just a thought on this, some other languages support attributes which is
similar but could also allow the engine to use them for things. As a quick
example (roughly based on what I've seen in c#) but applied to PHP use case:
class a {
[$date(Nullable)]
public function foo(DateTime $date) { ... }
}
-Clint
On Jan 6, 2013, at 3:58 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
Hi internals!
In one of the discussions (about the deprecated keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.
So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.
https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reflection annotations reader
On Mon, Jan 7, 2013 at 1:11 AM, Sebastian Krebs krebs@gmail.com wrote:
2013/1/6 Yahav Gindi Bar g.b.ya...@gmail.com
On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com
wrote:
I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that creates
complex
annotations, such as constructors and so on, in userland.
In fact, there's probably no need (now) to go on and build a full
annotation reader that instantiates classes and does fancy stuff as we
currently do in doctrine/common.
A fast parser is more than enough I suppose. That's our bottleneck
(besides scanning files).
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
So the problem is the syntax which is difference?
When wrote this RFC, I just though about basic cases...
Though I agree with you that the main problem is the syntax.
We can extract the entire doc-comment and only isolate between
annotations,
so doc-comment like:
/**
* @Route(/)
* @ORM(Key=foo)
* @var string
*/
Will be : array( 'Route(/)' = , 'ORM(Key=foo)' = , var =
string )
But the question is it really worth it, since you'll probably need to
create some sort of sub-parser that uses this isolated annotations
array
and apply on them your syntax.
As a suggestion, that should cover most (all?) cases: The identifier could
be defined as between @ and the first non-alphanumeric character (it
should probably allow some special like /, or \ to allow namespace-like
annotations). @Route(/) would be array( 'Route' = '(/)'. Now a
secondary parser only needs to take care about (/), but for example it
can already directly test, whether or not the annotation exists.
I've thought about two types of solutions:
- The first one is to add another argument that supplies additional
characters for the annotation key, so for example getAnnotation(name,
\\/!) Wil match any alphanumericlal values and \, / and !. From the
moment it'll catch another tag - it'll be the value.
So
@var String
@param2/param2(bar)
Will be array('var' = 'String', 'param2/param2' = '(bar)' );
- The second option, is to built some pre-defined parsing ways, so for
example we can define
REFLECTION_PARSE_DEFAULT which will parse the annotations just with
alphanumerical characters.
REFLECTION_PARSE_FUNCTION which will make the parsing of the parameters in
the brackets so @ORM(Key=foo) Will be parsed to array( 'ORM' = array(
'key' = foo ))
and @MaxLength(255) will be parsed to array ('MaxLength' = 255).
What do you think?
That's being said, if we'll see performance improvements, I really think
that it's a good solution to start with, since because its not an
Attributes, I don't think that we should dictate the syntax for each
application. Each application will get the doc-comment annotation and
will
be able to apply on it its own syntax and fancy stuff... I think that
it's
the best solution because of BC too.
To throw that in: Multiline-annotations must be taken into account too :)
Sure! :)
To tell the truth, I've implemented this parsing, too, in userland for
documenting application API's, and including it in PHP can make API
(web-services) documentations really easy!
Regards,
Sebastian
What do you think?
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Reflection annotations reader
This is attributes. I saw proposal for attributes that was declined.
I think that the language should contain attributes, but because the lack
of them the Annotations, which's currently used by some FW can be a great
addition.
To tell the troth, even if attributes was implemented in PHP, since the
doc-comment is being used in applications, I think that adding annotations
to the Reflection class can be great anyway. It can be handy in case
there's attributes, for example, to create documentation of functions etc.
On Mon, Jan 7, 2013 at 2:16 AM, Clint Priest cpri...@zerocue.com wrote:
Just a thought on this, some other languages support attributes which is
similar but could also allow the engine to use them for things. As a quick
example (roughly based on what I've seen in c#) but applied to PHP use case:
class a {
[$date(Nullable)]
public function foo(DateTime $date) { ... }
}
-Clint
On Jan 6, 2013, at 3:58 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
Hi internals!
In one of the discussions (about the deprecated keyword, to be
specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.
So, I've created an RFC that propose to improve the Reflection extension
by
adding the ability to read annotations decorated in the doc-comment.
https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
My objection is that we are introducing a class into an otherwise completely procedural API. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
Hi Stas, Everything looks good to me :) Great job. About your optional section : I like the procedural function that you proposed so that you don't have to use an object if you don't want to. cURL allow you to upload file from string buffer with CURLFORM_BUFFER and we should be able to do all the streams stuff with CURLFORM_STREAM and by modifying our CURLOPT_READFUNCTION. Pierrick On 6 January 2013 00:38, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Following the recent discussion on the list, I've drafted an RFC describing the CurlFile solution for it here: https://wiki.php.net/rfc/curl-file-upload Please review and comment. If there's a general positive feedback, I'll try to implement a patch for it pretty soon. -- 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] Reflection annotations reader
There is already a similar RFC here :) Maybe it could be good to start from this one so that we don't have any duplicated RFC ? https://wiki.php.net/rfc/annotations-in-docblock Pierrick On 6 January 2013 16:58, Yahav Gindi Bar g.b.ya...@gmail.com wrote: Hi internals! In one of the discussions (about the deprecated keyword, to be specific), it was been said that adding ability to read doc-comment annotation could be handy. Personally, I really think it can be great. So, I've created an RFC that propose to improve the Reflection extension by adding the ability to read annotations decorated in the doc-comment. https://wiki.php.net/rfc/reflection_doccomment_annotations What is your opinion about this? Regards, Yahav. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
Hi! cURL allow you to upload file from string buffer with CURLFORM_BUFFER and we should be able to do all the streams stuff with CURLFORM_STREAM and by modifying our CURLOPT_READFUNCTION. CURLFORM_STREAM has one issue - you can only have one read function, but you could have many uploaded files in the form. If we're willing to accept the limitation that only one uploaded file can be a stream and that you can not use both read function and stream file at the same time, then it will work. Otherwise cURL API wouldn't let us to distinguish between the functions. I'll start with implementing it without stream/buffer support, and then add it later. -- 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] [RFC] Reflection annotations reader
Yahav Gindi Bar wrote: Though I agree with you that the main problem is the syntax. We can extract the entire doc-comment and only isolate between annotations, so doc-comment like: /** * @Route(/) * @ORM(Key=foo) * @var string */ Will be : array( 'Route(/)' = , 'ORM(Key=foo)' = , var = string ) What about repeated keys? i.e: @param int $a @param string $b -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reflection annotations reader
Dear Yahav, At phpDocumentor we have been working on formalizing the PHPDoc Standard for quite some time now and I would ask you to take a look at that and use it as basis for the parsing of DocBlocks. You can find the document here: https://github.com/phpDocumentor/phpDocumentor2/blob/develop/docs/PSR.md This document contains an ABNF of a PHPDoc including descriptions and tags as currently used by conventional and modern applications. Do note that annotations are explicitly not detailed in this spec; just their global syntax. This is because the PHPDoc Standard is agnostic to these constructs. This document is still an unfinished draft and open for scrutiny by the community and stakeholders. It documents the current state of affairs and also opens up discussion for future improvements such as Inline DocBlocks. Please let me know if you have any questions, Mike van Riel Lead Developer of phpDocumentor On 06.01.2013 22:58, Yahav Gindi Bar wrote: Hi internals! In one of the discussions (about the deprecated keyword, to be specific), it was been said that adding ability to read doc-comment annotation could be handy. Personally, I really think it can be great. So, I've created an RFC that propose to improve the Reflection extension by adding the ability to read annotations decorated in the doc-comment. https://wiki.php.net/rfc/reflection_doccomment_annotations What is your opinion about this? Regards, Yahav. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
Hi! I've added the pull request for the CURLFile here: https://github.com/php/php-src/pull/255 No procedural API yet, I'm not really sure if we need it, it's not that hard writing new CurlFile(). But if needed I can add it there. Everybody please take a look and see if you notice any problems or missing stuff there. Tests are there and they pass for me :) -- 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] [RFC] Fixing insecure cURL file uploading
Hi! Couldn’t CurlFile extend SplFileInfo? Otherwise it looks good. I don't see much reason for that. They are very different classes - CurlFile is not meant to provide information about the file, just keep the name, MIME type, etc. So most of the SplFileInfo API will be useless there. -- 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] [RFC] Reflection annotations reader
So
@var String
@param2/param2(bar)
Will be array('var' = 'String', 'param2/param2' = '(bar)' );
Let's make this clear immediately: an associative array as output is not
useful.
That would make it impossible to nest annotations. For example, something
like following wouldn't work if the output is just arrays:
@MyApp\Acl({
allow=@MyApp\Acl\Allow({john=read, joe=write}),
deny=@OtherApp\Acl\Deny(default=*, log=true)
})
Maybe a silly example, but nested annotations are not that rare :)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
[PHP-DEV] Re: release frequency?
hi Stas, On Wed, Jan 2, 2013 at 7:26 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I see that we do not have a lot of changes in 5.4 since last release. So I wonder if it may make sense to reduce release frequency now that we got less bugfixes coming in, say from monthly to 1.5 or 2 months between release. What do you think? Just to be clear, I have no problem (excepting unforeseen circumstances, of course) still doing monthly, just not sure it's worth it if we'd have less than 10 bugfixes per release... I would go from a case by case basis. I received really good feedback about our more frequent releases. Any bug is important to some of our users, however we could prioritize them and see if the available fixes are important enough to do a release, if not, we do it next month. But then no delay anymore, two months delay between two releases the max :) 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
Re: [PHP-DEV] Re: release frequency?
As an outsider I would say consistency is king. Knowing that I can rely on when new versions come out is much more important than whether they contain 9 or 11 bug fixes. So, pick a schedule that works and stick to it. Just my thoughts. -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
