On Fri, May 3, 2013 at 2:08 AM, Sherif Ramadan wrote:
> It's already possible to do so now without any modifications to the core:
It was already possible to declare arrays, but the new, shorter array
syntax still brings a smile to my face :) Few new language features
actually add things that were
On Thu, May 2, 2013 at 11:44 PM, Sherif Ramadan wrote:
>
> Just to clarify, PHP doesn't offer two separate approaches of handling
> errors. We need to first distinguish between what is meant by a the terms
> "Errors" and "Exceptions" so that we don't throw around ambigous claims
> here. PHP has an
On Thu, May 2, 2013 at 6:46 PM, Stuart Langley wrote:
> So is the feature you're describing is tuples and a use case of that feature
> is an easier way to do error handling?
No.
Tuples are an implementation detail specific to how Python allows one
to conveniently return multiple values. I merely
PHP currently has two separate approaches to handling errors:
- Errors
- Exceptions
Both have their issues.
Using and responding to errors requires that the returned value (if
there is one) perform double duty as both a potential valid response
AND, in the case of error, a flag that something wen
On Thu, Feb 28, 2013 at 3:00 PM, Anthony Ferrara wrote:
> 1. It has integration issues with ZO+ in that it has to be included in a
> specific order (specifically around ini declarations). If it was included
> into core, this could be accounted for allowing for more robust behavior.
I don't use Su
On Wed, Feb 27, 2013 at 4:45 PM, Nikita Popov wrote:
>>
> Not sure I understand the question. O+ is compatible with 5.5, so you can
> use that if you like. Just install it as an ext. Just like you would have
> done with APC.
>
> Nikita
More than ANY other language feature, having an integrated op
On Wed, Feb 27, 2013 at 4:40 PM, Adam Jon Richardson wrote:
> On Wed, Feb 27, 2013 at 4:30 PM, Nikita Popov wrote:
>> On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf wrote:
>>
>> All these are really great arguments for including O+ ... in PHP 5.6. O+ is
>> already
On Wed, Feb 27, 2013 at 4:30 PM, Nikita Popov wrote:
> On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf wrote:
>
> All these are really great arguments for including O+ ... in PHP 5.6. O+ is
> already compatible with PHP 5.5 and as we're just days away from feature
> freeze this will stay so til
On Fri, Jan 11, 2013 at 7:17 PM, Ben Ramsey wrote:
> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
No voting member, here, but I'd just like to say that I like the
function, but I hope the actual implementation will only p
On Wed, Jan 9, 2013 at 12:45 PM, Anthony Ferrara wrote:
> Stas,
>
> On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev wrote:
>
>> I seriously hope it never comes to this in PHP
>
>
> Would you shut up with this rhetoric already? All it does is show that
> you're completely and utterly out of touch wi
On Sun, Jan 6, 2013 at 6:13 AM, Stas Malyshev 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 som
On Sat, Jan 5, 2013 at 6:26 PM, Stas Malyshev 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 escapi
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., , , etc.)
Functions such as strip_tags() do allow whitelisting,
On Sat, Dec 8, 2012 at 5:36 PM, Steve Clay wrote:
> On 12/8/12 4:48 PM, Adam Jon Richardson wrote:
>
>> call closures that are stored as object properties directly without having
>> to make use of a temporary variable.
>>
> ...
>
> $o = new stdClass();
>>
On Sat, Dec 8, 2012 at 5:05 PM, Stas Malyshev wrote:
> Hi!
>
> > Has anyone else wanted this functionality? Has anyone else thought of
> ideas
> > of addressing this (or come to the conclusion it really isn't safely
> > addressable without causing disproportionate amounts of grief?)
>
> Yes, there
A while back, there was a thread discussing adding a specific function
for removing elements from an array by value. Rasmus L. noted that
when the values are unique, they would be better represented as keys:
> The problem is that it is a rather unusual thing to do. I don't mean
> removing an eleme
On Tue, Sep 18, 2012 at 7:30 AM, Pádraic Brady wrote:
> Hi all,
>
> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
> The RFC is a proposal to implement a standardised means of escaping
> data which is being output into XML/HTML.
>
> https://wiki.php.net/rfc/escaper
Some Qu
On Wed, Sep 12, 2012 at 12:57 PM, Scott MacVicar wrote:
> "There is no requirement for them to be cryptographically secure. "
> What stops the salt from being cryptographically secure? I think it should be
> a goal or we should state what parts aren't cryptographically secure, is it
> the random
On Tue, Sep 4, 2012 at 9:17 PM, Adam Jon Richardson wrote:
> On Tue, Sep 4, 2012 at 8:09 PM, Levi Morrison wrote:
>> This is probably why the section in the RFC is so small . . . :)
>
> The section covering the potential for potential optimizations isn't so small
&
On Tue, Sep 4, 2012 at 8:09 PM, Levi Morrison wrote:
> This is probably why the section in the RFC is so small . . . :)
The section covering the potential for potential optimizations isn't so small :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
On Tue, Sep 4, 2012 at 6:02 PM, Andrew Faulds wrote:
> APC will make things faster, though, you're missing that. And optimisations,
> which an AST would help, would make it even faster.
Respectfully, I didn't miss that, and I alluded to that potential in
my response (did you read all of my respon
On Tue, Sep 4, 2012 at 3:57 PM, Nikita Popov wrote:
> Hey folks!
>
> Some people asked me what the advantages of using an AST-based
> parsing/compilation process are, so I put together a few quick notes
> in an RFC:
>
> https://wiki.php.net/rfc/ast_based_parsing_compilation_process
>
> It would be
On Thu, Aug 23, 2012 at 12:06 PM, Rasmus Lerdorf wrote:
> So do we create a new default_input_encoding ini directive mid-stream in
> 5.4 for this? Of course with the longer-term in mind that this will be
> part of a unified set of encoding settings in 5.5 and beyond.
Yes! This is a fantastic idea
On Thu, Jul 19, 2012 at 2:14 PM, Rasmus Lerdorf wrote:
> The goal of this message is to encourage and motivate a few people to
> give me a hand with tracking down APC bugs. There are still a few
> outstanding bugs that is slowing PHP 5.4 adoption and it would be really
> nice to plow through these
On Thu, Jul 19, 2012 at 2:49 PM, Sara Golemon wrote:
> Same as you would in PHP code. Make an IS_STRING pointing at a global
> function, or IS_ARRAY pointing at a class method, or an IS_OBJECT supporting
> __invoke(). If you're asking how you can call a C function directly via
> this callback: Y
On Mon, Jul 16, 2012 at 10:25 PM, Anthony Ferrara wrote:
> This is standard and expected behavior. Since " has no special meaning
> within a document (outside of an attribute declaration), there is no
> requirement to escape it. And the standard practice when parsing XML/HTML
> using a dom based p
On Mon, Jul 16, 2012 at 7:27 PM, Andrew Faulds wrote:
> Through its history, PHP has slowly become more object-oriented.
While PHP has become more capable for OOP, it has also become more
capable for FP, too. And, procedural programming is still a very
strong influence.
> I think PHP could benef
Hi,
I'm calling the function php_pcre_replace() in my extension:
http://lxr.php.net/xref/PHP_5_4/ext/pcre/php_pcre.c#952
I would like to use a callback for the replace_val, but this will be
supplied by my extension. I'm wondering what the recommended way of
creating the replace_val zval callback
On Tue, Jun 19, 2012 at 6:23 AM, Tjerk Meesters
wrote:
> On 19 Jun, 2012, at 2:24 PM, Adam Jon Richardson wrote:
>>
>> One thing I'm wondering about is whether the last parameter could be
>> changed from:
>> raw_output = false
>>
>> To something l
On Mon, Jun 18, 2012 at 7:14 PM, Anthony Ferrara wrote:
> https://wiki.php.net/rfc/hash_pbkdf2
>
> What are your thoughts?
That's very nice, indeed.
One thing I'm wondering about is whether the last parameter could be
changed from:
raw_output = false
To something like:
output = "hex" (also all
On Wed, Apr 18, 2012 at 1:56 AM, Alexey Shein wrote:
> Hi!
>
> My opinion is that solution tries to overcome bad consequences of
> legacy code, when it's not feasible to change something without
> breakage a lot of code, although the real solution is to refactor
> functions with long variable lis
On Tue, Apr 17, 2012 at 6:54 PM, Stas Malyshev wrote:
> Hi!
>
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named
On Mon, Apr 16, 2012 at 11:42 PM, wrote:
> Stas:
>
> Just b/c there are rarely any women at all that participate on this list,
> could we at list maintain a facade of gender neutrality? I seriously can't
> believe that you used the word "him". What about "her"? Yeah, "her" as in
> myself and e
On Sun, Apr 1, 2012 at 5:10 PM, Pierre Joye wrote:
> hi,
>
> On Sun, Apr 1, 2012 at 2:19 PM, Florian Anderiasch
> wrote:
>
> > due to the widespread acceptance of binary number format (0b1010101) and
> > the growing demand for backwards compatibility I've started to work on
> > support for Roman
On Tue, Mar 6, 2012 at 2:34 AM, Adam Jon Richardson wrote:
> Plugins are a big deal (see
> http://oneofmanyworlds.blogspot.in/2012/03/difficult-decision.html for a
> recent example.) In this era of mashups and breakneck innovation,
> developers must rely on vast amounts of code they&#
2012/3/20 François Gannaz
> Hi
>
> I wrote a report of my first dive into php-src in an attempt to fix a bug.
> https://github.com/mytskine/php-src/wiki/bug40531-mbsubstr
> I tried to detail everything as a personal memo, then for a friend of mine,
> and now I've put it into a github wiki page.
On Mon, Mar 19, 2012 at 12:33 AM, David Soria Parra wrote:
> Migration is underway.
> Will take a while. Import takes a few hours.
> Expect git access to be available by Monday afternoon.
Great work organizing and carrying out this update, David. Git's gonna be
great!
Adam
On Sun, Mar 18, 2012 at 7:11 PM, Simon Schick
wrote:
> Hi, Adam
>
> I totally agree that type-hinting should not cover what the programmer
> should do for validating the given input ...
> But I just wanted to point out that this is something the author (and
> I) would never expect to happen ...
>
On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
wrote:
>
> Hi, All
>
> Just to add an example why I want a more strictly type-check here as
> we have in the current type-juggling:
>
> http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rss&utm_medium=rss&utm_campaign=an-xss-vu
On Sat, Mar 17, 2012 at 10:37 AM, Marco Pivetta wrote:
> Unenforced type hinting:
> - If you have mixed types, then you just don't need type hinting. Lazy
> devs can still avoid using it. Lazyness shouldn't really be
> encouraged, so
> providing some kind of "backwards compatibility
2012/3/7 Ángel González
> On 07/03/12 00:04, Adam Jon Richardson wrote:
> > It would be the responsibility of the framework or CMS or application
> > to protect against this type of attack (which they do quite well.)
> > When you can force a plugin to work through y
On Mon, Mar 12, 2012 at 5:08 PM, Richard Lynch wrote:
> On Tue, March 6, 2012 3:30 am, Florian Anderiasch wrote:
>
> Security by blacklist almost always isn't security...
>
> You're bound to miss one of the functions you should have blacklisted,
> but didn't.
>
Agreed. The approach I'm developi
On Mon, Mar 12, 2012 at 3:52 AM, Stas Malyshev wrote:
> Hi!
>
>
> Ignoring 5.4 for a second, if you in 5.3 do this:
>>
>> echo htmlspecialchars($string);
>> echo htmlspecialchars($string, NULL, "ISO-8859-1");
>> echo htmlspecialchars($string, NULL, "UTF-8");
>>
>> You will see that the first two
On Mon, Mar 12, 2012 at 2:49 AM, Rasmus Lerdorf wrote:
> What we really need is what we added in PHP 6. A runtime encoding ini
> setting that is distinct from the output charset which we can use here.
> That would allow people to fix all their legacy code to a specific
> runtime encoding with a s
On Thu, Mar 8, 2012 at 6:08 PM, John Crenshaw wrote:
>
> > Well, if your type hints gets more forgiving, than it's the same that was
> > proposed by this function a((int) $arg) {} And in this case hints have no
> > meaning at all - it's just other syntax to do the conversion that now
> looks
> > l
2012/3/6 Ángel González
> On 06/03/12 14:04, Adam Jon Richardson wrote:
> > The sandbox I'm considering would only impact the ability to directly
> call...
> It's not that easy. The internal functions could be splitted to
> safe/unsafe (according
> tosome defi
On Tue, Mar 6, 2012 at 4:38 AM, Stas Malyshev wrote:
> Hi!
>
> Thoughts?
>>
>
> This is a fine idea, however actually doing it is not that easy. Note that
> knowing which function is "safe" is pretty hard, but that's only a start.
> Plugin code, for example, can call functions outside plugin cont
On Tue, Mar 6, 2012 at 3:30 AM, Florian Anderiasch wrote:
> Isn't that basically what all template engines tried to solve before
> with giving you a defined subset of tokens that are more or less
> directly converted to php code? The benefit I see is that plugin
> developers wouldn't need to learn
Plugins are a big deal (see
http://oneofmanyworlds.blogspot.in/2012/03/difficult-decision.html for a
recent example.) In this era of mashups and breakneck innovation,
developers must rely on vast amounts of code they've never seen, let alone
audited. Wordpress, Drupal, and many other tools develope
On Mon, Mar 5, 2012 at 7:03 PM, Kris Craig wrote:
> Certainly. I don't believe this is about "inclusion" any more than
> creating a function called "ech" as an alias for "echo" would be. The tag, as you all know, creates problems when working with XML. Furthermore,
> I've never understood the
On Mon, Mar 5, 2012 at 6:04 PM, Kris Craig wrote:
> Personally, I HATE short_open_tab. It has no value-- *except* that,
> unfortunately, it's still widely used in many apps and even some frameworks
> TTBOMK.
I personally like it and find value in its inclusion :)
Adam
On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara wrote:
> Well, there are a few questions about the implementation:
>
> 1. *Which* type casting rules should it follow?
>
> a. Regular cast rules (like $foo = (int) $foo), where it converts
> always without error?
> b. Internal function cast rules, w
On Thu, Mar 1, 2012 at 10:36 AM, Lazare Inepologlou wrote:
> Of note, the scalar type hinting I've outlined does not automatically
>> perform casts...
>
>
> Thank you for your answer. Maybe, this exact fact is what I don't like
> about your suggestion. Please read the following RFC, where Lukas S
On Thu, Mar 1, 2012 at 8:55 AM, Anthony Ferrara wrote:
> Please do not implement int, float, etc as an alias to scalar. That's
> going to cause nothing but trouble later on. It will instantly close
> the door to any type of casting magic (due to BC concerns), be
> completely non-obvious ("I hin
On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou wrote:
> Yes, I agree, the casting (or the failing to cast) has to happen on entry,
> for the reasons that you have very well explained.
>
> However, I cannot understand what it means to cast an object to a scalar.
> Does it always mean casting to
On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou wrote:
> And, *what if PHP added the following aliases for the hint scalar*:
>
> - bool
>
> - int
>
> - float
>
> - string
>>
>
> If an object has a __toString method, does it qualify as a valid value to
> be passed to a scalar argument? In my opi
First, phpunit is a fantastic tool! I'm thankful for your contributions to
all of the PHP community (especially with the code coverage capabilities.)
I speak to your 2 points inline below:
On Wed, Feb 29, 2012 at 9:36 PM, Sebastian Bergmann wrote:
> On 02/29/2012 09:01 PM, Adam Jon Ri
PHP currently allows users to provide type hints for functions and methods,
although the type hints are currently limited to objects and arrays:
http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking
Restricting the type hinting to arrays and objects makes sense, as PHP's
type j
On Wed, Feb 29, 2012 at 8:46 PM, Kris Craig wrote:
> I was thinking something more along the lines of simply throwing an error
> if, say, (int) $a != $a *if *$a is defined as an integer.
>
> --Kris
>
>
> On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw >wrote:
>
> > > -Original Message
59 matches
Mail list logo
