[PHP-DEV] [RFC] Fixing insecure cURL file uploading

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

Re: [PHP-DEV] How to get a PHP bug fixed?

Hi! > I agree with you that the parameters would be good. There should also > be the limit parameter (same as for debug_backtrace). However I'm > afraid I'm not that much familiar with C to actually write it. There's a bigger problem with this bug. The problem is that if we keep the object in the

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Stas, You can not both say "it works just like method parameters" and in the > same breath say it needs the concept of dynamic initializers which never > existed in PHP and which BTW was not introduced in the RFC either (and > which won't solve the problem you're trying to solve anyway). I neve

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Hi! > As far as "introduce completely new concept, not existing in PHP at > all", that's the entire purpose of an RFC. That's what we're doing right > here. We're talking about introducing new functionality and features > that may make people's lives easier. So to discuss the feature, yet > limit

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Stas, 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 > unse

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Stas, You really put it in the same answer as telling me it's the same as > parameter defaults? Here you introduce completely new concept, not > existing in PHP at all - non-constant initializers. And this is a whole > new can of worms - when it should be run, what should happen when it's > run, w

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Hi! > Wait, what are you talking about here? About this particular proposal or > the accessors RFC in general? The fact that unset() can throw a > (catchable) fatal error is just the same without this particular syntax. This is pretty bad by itself. But the fact that everybody would be using this

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

On 1/5/13 7:25 PM, Anthony Ferrara wrote: No, the other initializer that would be useful is `new Foo`. Assigning a default value is not an initializer. An initializer is something that's run on object construction (and has been discussed in other threads): class Foo { public DateTime $bar {

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

On Sun, Jan 6, 2013 at 2:05 AM, Stas Malyshev wrote: > You convinced me that this feature is actually harmful to PHP - dealing > with unset() throwing fatal errors is much worse than occasional empty() > check. This is a huge landmine - now any code that unsets object > property can return fatal er

[PHP-DEV] Casting in list()

I just run over this a few times lately (it is a bit indirect because of not having much logic in the overall syntax, but probably not that bad), for PHPs list() construct I think it would be nice being able to cast the assignments on the fly:     list((string) $name) = array(new SplFileInfo(__

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote

Hi! > The first call to a getter would initiate the (calling) guard, any other > access outside of the getter from that point forward would return NULL, > but the access by the getter would return the property. How we implement that? Would we have each variable access check whether we are in th

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Hi! > Again, same for function typehints. NULL is the only possible > initializer there, too. But still we don't take that as a reason to > always allow NULL for them. For function, non-optional parameters are always mandatory provided. For properties, it is not true - there are no "mandatory pro

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Hi! > No, the other initializer that would be useful is `new Foo`. Assigning a You really put it in the same answer as telling me it's the same as parameter defaults? Here you introduce completely new concept, not existing in PHP at all - non-constant initializers. And this is a whole new can of

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

On Sun, Jan 6, 2013 at 1:18 AM, Stas Malyshev wrote: > Hi! > > > "Too much magic"? It's completely consistent with how method parameters > > work now. In fact, I'd argue that introducing a new syntax for this > > would be inconsistent with the current paradigm. > > But this in for methods, and you

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Stas, But this in for methods, and you are putting it into entirely different > place - property initializer. That's what I call magic - somehow > property initializer magically becomes method parameter's default value. The same could be used to justify the param order difference between string

Re: [PHP-DEV] Ruby's symbols

On 01/05/2013 03:43 PM, Kris Craig wrote: > Granted, but other use-cases have already been presented as well. > Obviously the one I suggested would no longer be useful if PHP adopts > enums. Actually, I didn't see any other cases. The fact that we have interned immutable strings in PHP invalidate

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Hi! > "Too much magic"? It's completely consistent with how method parameters > work now. In fact, I'd argue that introducing a new syntax for this > would be inconsistent with the current paradigm. But this in for methods, and you are putting it into entirely different place - property initializ

Re: [PHP-DEV] How to get a PHP bug fixed?

I agree with you that the parameters would be good. There should also be the limit parameter (same as for debug_backtrace). However I'm afraid I'm not that much familiar with C to actually write it. It's true that in 'args' there theoretically may not be any object. But as you are surely aware

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Stas, > I think this is way too much magic. This means default is no longer a > default, but instead some obscure flag that somehow is carried over to > the setter. I do not think redefining initialization as permitting nulls > is a good idea, initialization and value set are two different things

Re: [PHP-DEV] How to get a PHP bug fixed?

Hi! > I don't understand. There already IS the 'args' field where huge > objects also can be (and very often are). The new 'object' field > does not make any difference in this regard. It adds another place where huge objects can be - and unlike args, it is guaranteed to be an object, and those

Re: [PHP-DEV] How to get a PHP bug fixed?

I don't understand. There already IS the 'args' field where huge objects also can be (and very often are). The new 'object' field does not make any difference in this regard. Dne Sun, 06 Jan 2013 00:42:58 +0100 Stas Malyshev napsal(a): Hi! Are you sure there should be the $options parame

Re: [PHP-DEV] Ruby's symbols

Hi! > I'm still a total newb when it comes to Ruby, but as I understand it, a > symbol can be particularly helpful by maximizing code readability > without sacrificing efficiency. As a PHP guy, I tend to think of a Ruby > symbol as a constant that doesn't need to be defined or set. Its value St

Re: [PHP-DEV] Ruby's symbols

On Sat, Jan 5, 2013 at 3:39 PM, Rasmus Lerdorf wrote: > On 01/05/2013 03:36 PM, Kris Craig wrote: > > > > > > On Sat, Jan 5, 2013 at 3:32 PM, Rasmus Lerdorf > > wrote: > > > > On 01/05/2013 03:29 PM, Kris Craig wrote: > > > > > In both cases, we really don't ca

Re: [PHP-DEV] How to get a PHP bug fixed?

Hi! > Are you sure there should be the $options parameter? It would not > save any memory because the trace needs to be pregenerated > regardless. Back compatibilty clearly doesn't need to be that strict > in this case because for example in case of debug_backtrace function > the 'object' fields w

Re: [PHP-DEV] How to get a PHP bug fixed?

And by tests I mean fixing all the old tests which use Exception::getTrace(). There is no need to write a new test(s). Dne Sun, 06 Jan 2013 00:28:17 +0100 Jáchym Toušek napsal(a): Are you sure there should be the $options parameter? It would not save any memory because the trace needs to be

Re: [PHP-DEV] Ruby's symbols

On 01/05/2013 03:36 PM, Kris Craig wrote: > > > On Sat, Jan 5, 2013 at 3:32 PM, Rasmus Lerdorf > wrote: > > On 01/05/2013 03:29 PM, Kris Craig wrote: > > > In both cases, we really don't care what the actual values of > brown, black, > > and purple ar

Re: [PHP-DEV] Ruby's symbols

On Sun, Jan 6, 2013 at 12:29 AM, Kris Craig wrote: > I'm still a total newb when it comes to Ruby, but as I understand it, a > symbol can be particularly helpful by maximizing code readability without > sacrificing efficiency. As a PHP guy, I tend to think of a Ruby symbol as > a constant that d

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote

The problem I see with your proposal is that get/isset/unset could all bypass the setter which I think is a bad idea. If the problem is simply this "hidden state" that keeps being referred to, I thought the solution I mentioned before would be better. To re-iterate that prior idea is to make

Re: [PHP-DEV] Ruby's symbols

On Sat, Jan 5, 2013 at 3:32 PM, Rasmus Lerdorf wrote: > On 01/05/2013 03:29 PM, Kris Craig wrote: > > > In both cases, we really don't care what the actual values of brown, > black, > > and purple are. We just want it to be unique so we can reference each of > > them in a visually friendly way w

Re: [PHP-DEV] Ruby's symbols

On 01/05/2013 03:29 PM, Kris Craig wrote: > In both cases, we really don't care what the actual values of brown, black, > and purple are. We just want it to be unique so we can reference each of > them in a visually friendly way with minimal performance impact. That's > where I could see a valid

Re: [PHP-DEV] Ruby's symbols

On Sat, Jan 5, 2013 at 2:49 PM, Stas Malyshev wrote: > Hi! > > > I know I shouldn't write "Ruby" in the subject of a letter for > > php-internals ML, but... Just wanted to ask, is anybody interested in > this > > feature in PHP? > > As I understand, :foo is basically an interned string "foo". But

Re: [PHP-DEV] How to get a PHP bug fixed?

Are you sure there should be the $options parameter? It would not save any memory because the trace needs to be pregenerated regardless. Back compatibilty clearly doesn't need to be that strict in this case because for example in case of debug_backtrace function the 'object' fields where added

Re: [PHP-DEV] Providing improved functionality for escaping html (and other) output.

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., , , etc.) I think what you are looking for is Html

Re: [PHP-DEV] Ruby's symbols

Hi! > I know I shouldn't write "Ruby" in the subject of a letter for > php-internals ML, but... Just wanted to ask, is anybody interested in this > feature in PHP? As I understand, :foo is basically an interned string "foo". But in PHP all constant strings are interned now, so the only thing

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

Hi! >> typehints, i.e. allow NULL when NULL is specified as the default value. So >> `public DateTime $date;` would not allow an explicit NULL assignment, >> whereas `public DateTime $date = NULL;` would. I think this is way too much magic. This means default is no longer a default, but instead s

Re: [PHP-DEV] How to get a PHP bug fixed?

Hi! > I've looked into it and I'm not sure whether an option for getTrace > method is the best way to solve this. I mean the trace is created > along with the exception so it would have to be generated with the > object fields regardless and then filtered if the option is not set. > I think it wou

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

On 1/4/13 9:41 AM, Nikita Popov wrote: https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax I like the proposal so far. I'm still a little hesitant about syntax for allowing the setting of NULL values. Since properties are NULL by default (I wish this were explicit in

Re: [PHP-DEV] How to get a PHP bug fixed?

I've looked into it and I'm not sure whether an option for getTrace method is the best way to solve this. I mean the trace is created along with the exception so it would have to be generated with the object fields regardless and then filtered if the option is not set. I think it would be bette

[PHP-DEV] MAC address validation for ext/filter

In https://github.com/php/php-src/pull/247 I have implemented MAC address validation for ext/filter. The current implementation detects MAC addresses in three notations (IEEE 802 with colons or hyphens and EUI-64 with dots) and optionally one can specify the expected separator character (colons/h

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote

On 1/5/13 2:05 PM, Clint Priest wrote: I like the alternate idea here, but I'm not sure what advantage it has over the current situation? See the "Pros" I listed. The primary being a clear differentiation between calling accessors and handling of the storage value associated with the property

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

+1 from me as well. On 1/4/2013 8:41 AM, Nikita Popov wrote: Hi internals! I already brought this up before, but I think the discussion at that time was not very constructive and largely off-topic, so I'm bringing it up again. To make sure everything is clear I wrote an RFC document: https://w

[PHP-DEV] Issue #63882 patch validation

Hi, there is an issue about the recursion inthe default class properties comparsion. I've added a patch there and would like to ask for the validation. Regards Anatoliy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote

I like the alternate idea here, but I'm not sure what advantage it has over the current situation? This line of reasoning revealed a difference between what your verbiage suggestion from a few days ago suggests and what i

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

This looks really nice. I would love to see this in PHP +1 - Jon On Fri, Jan 4, 2013 at 8:41 AM, Nikita Popov wrote: > Hi internals! > > I already brought this up before, but I think the discussion at that time > was not very constructive and largely off-topic, so I'm bringing it up > again. T

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote

On 1/3/13 5:43 PM, Stas Malyshev wrote: The whole problem here is that the only reason why it is a problem is because of the accessors that have hidden state in guards. If it were regular variables (and for all the API consumer knows, they are) there Please ignore this if it's been debated befo

Re: [PHP-DEV] Ruby's symbols

On Sat, Jan 5, 2013 at 6:58 PM, Nikita Nefedov wrote: ** Though there would be a little speed-up because with Symbols array's Buckets will keep numeric key, so instead of memcmp you will need to just compare two longs when retrieving element. Before memcmping the array keys PHP will fir

Re: [PHP-DEV] Ruby's symbols

On Sat, Jan 5, 2013 at 6:58 PM, Nikita Nefedov wrote: > ** > Though there would be a little speed-up because with Symbols array's > Buckets will keep numeric key, so instead of memcmp you will need to just > compare two longs when retrieving element. > Before memcmping the array keys PHP will fi

Re: [PHP-DEV] Ruby's symbols

On Sat, 05 Jan 2013 12:21:26 -, Nikita Popov wrote:On Sat, Jan 5, 2013 at 3:07 PM, Nikita Nefedov wrote: What symbols can give: 1. More convenient way to use it almost everywhere as a replacement for strings and sometimes for constants. There's a lot of code that uses ar

[PHP-DEV] VCS Account Request: demoking8

1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Ruby's symbols

If symbols could use the sign bit or otherwise distinguish from typical integer keys one would have some hope of meaningful debugging output. I don't think it makes sense to mix integer keys and symbol keys but being able to differentiate them for debugging purposes would be great. However since

Re: [PHP-DEV] Ruby's symbols

On 05/01/13 13:21, Nikita Popov wrote: [snip] If this is about memory savings, then I don't think it will help at all. PHP uses interned strings, so all those "label" etc strings in your above example actually use the same string value. The hash for those strings is also precomputed, so symbol do

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote

On 02.01.2013 12:36, Clint Priest wrote: > Here is the updated RFC incorporating the feedback from previous rounds > of discussion. > > https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 One thing that I have not found in the RFC is how do you specify a default value AND accessors? Many examples

Re: [PHP-DEV] Ruby's symbols

On Sat, Jan 5, 2013 at 3:07 PM, Nikita Nefedov wrote: > What symbols can give: > 1. More convenient way to use it almost everywhere as a replacement for > strings and sometimes for constants. There's a lot of code that uses arrays > as a parameter-stores. For example, here's how you usually defin

Re: [PHP-DEV] Ruby's symbols

Hi :-), Nice proposal but I have few questions and remarks. My first question is how to delete symbols? I don't know if it is useful or not. We should discuss about that. Is `unset(:foo)` enough? How are they handled by the GC? Another question is: where are we able to use symbols? Is it all

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

2013/1/5 Nikita Popov > I think that's a very interesting question, thanks for bringing it up. I > think a good approach here would be the same one used for function argument > typehints, i.e. allow NULL when NULL is specified as the default value. So > `public DateTime $date;` would not allow an

Re: [PHP-DEV] Ruby's symbols

On Sat, 05 Jan 2013 10:27:01 -, Crocodile wrote:Sounds like it could make some sense. However, I've got a question..array(  'label' => 'Comment', 'required' => false,  'property_path' => 'properties.comment') is actually equivalent to array( 'label' => 'Comment',  'property_path' => 'pro

Re: [PHP-DEV] Ruby's symbols

Sounds like it could make some sense. However, I've got a question.. array( 'label' => 'Comment', 'required' => false, 'property_path' => 'properties.comment' ) is actually equivalent to array( 'label' => 'Comment', 'property_path' => 'properties.comment', 'required' => false, ) (Notice t

[PHP-DEV] Ruby's symbols

I know I shouldn't write "Ruby" in the subject of a letter for php-internals ML, but... Just wanted to ask, is anybody interested in this feature in PHP? You can read about it here: http://www.randomhacks.net/articles/2007/01/20/13-ways-of-looking-at-a-ruby-symbol It can be implemented in P