Re: [PHP-DEV] [RFC] Typed Properties
Hi! > Well... it's not being voted on because, despite being six days till > the originally planned feature freeze date, neither sponsor has opened > a vote. And I think it's a good thing. Both for selfish reasons (I haven't actually have the time to read the proposal and the mail thread properly yet, though I might be able to get to it next week) and for procedural reasons - we're already in release process, we shouldn't be voting on one of the biggest features in years this late. For me it just doesn't feel right. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
Hi! > Although it is true that an upgrade from PHP 7 to 8 will involve more > work, it is not true that it does not hurt anyone. This is a well > known problem in design: > > https://www.nngroup.com/articles/reduce-redundancydecrease-duplicated-de > sign-decisions/ This is all generic advice which is nice and well if we would be designing language anew. As it is, we are not - we already have lots of code using var. For code not using var, removing var does not do anything. For code using var, removing var means no upgrade. It is unnecessary breakage for the sake of feeling that we follow the advice somebody put on the website. That feeling is not worth very real work that people would have to do to achieve what they already have now. > - "What is the difference between *implode* and *join*?" Yes, PHP has aliases. Nothing wrong with that, provided you bother to look in the manual once, and then you are enlightened forever. > It confuses users and wastes their time. It only wastes their time if they don't read the manual but instead chat on Stackoverflow :) Which I have nothing against, -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct
Hi! > > own custom one, there are two reasons for this. First, it's a standard > > that's been adopted by a number of significant scale projects. Second, > > I completely disagree that Contributor Covenant's text is any kind of > "standard". I've seen a number of CoCs, and it's not the worst (though > their homepage is... meh) but also not the best, and certainly not only. Here are couple more: Django: https://www.djangoproject.com/conduct/ FreeBSD: https://www.freebsd.org/internal/code-of-conduct.html I think all those have several common threads: - more space spent on good conduct than bad conduct - advice on how to resolve conflicts without escalation - clear guidelines for reporting problems - specific one for the project, not a prefabricated copy Comparing this one to the Covenant one, I clearly think any of those examples is superior. Is reflects specific project, is helpful, is positive, and looks like is is written by actual people, not copied from somewhere because we need to have something. I think that if we think having CoC is important, then we should have one that is actually helpful and positive, and not a cookie-cutter one. And if it's not important enough for us to spend some time on formulating it, then maybe we don't need it that much? :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Serializing exceptions
Hi! Looking into some issue, I've discovered that, to my surprise, > Exceptions are serializable. Except that it doesn't always work of > course (e.g. see http://stackoverflow.com/q/9747813/214196) because > exceptions contain backtraces, and those can contain non-serializable > objects. So in reality, you never know if you can serialize it or not. > > So, I wonder - would it be ok to make exceptions not serializable at > all? I think that would prevent major WTF factor when people try it and > it randomly fails. > Since discussion on this did not lead to a definite conclusion, but I did not hear from anybody that they need serialized exceptions, and we keep getting bug reports about exception serialization and various issues triggered by it, I propose this change: https://github.com/php/php-src/pull/1442 Since it is kind of BC break (even though I assume it breaks something that needed not to be allowed in the first place) I'd like to merge it in 7.0.0. Please object if you think this should not be done and explain why. Otherwise I intend to merge it after a suitable wait and after adding necessary tests/docs. Thanks, -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] Safe execution timeout handling
On Mar 11, 2015 7:01 PM, "Stas Malyshev" wrote: > > Hi! > > > Instead of throwing zend_error() from signal handler, now we just set > > EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt) > > flag on each JMPx instruction (potential loop iteration) and then throws > > JMPs are not the only operations that can transfer control and thus > potentially form a loop. Oops, please ignore this, it was a draft sent accidentally.
Re: [PHP-DEV] Safe execution timeout handling
Hi! > Instead of throwing zend_error() from signal handler, now we just set > EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt) > flag on each JMPx instruction (potential loop iteration) and then throws JMPs are not the only operations that can transfer control and thus potentially form a loop. > Unfortunately this approach doesn't support interruption of long-running > internal functions yet. It should be extended in some way. May be > additional timeout. Doing additional setjmp when entering internal function probably would be too expensive. So the question is how to get out of the bad function without incurring per-function overhead... Not sure how to do it. -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Hi! > So rather than go for the 70-75% consensus that we **know** we have, How we magically know that? We have the (unfinished) vote, which has a tiny bit over 66% for the proposal. Where 75% comes from? > I created a forked RFC. You can keep her as lead all you want, that > doesn't mean I can't move forward with my RFC. I think it would really be better to have a lot less "us vs them" and a bit more cooperative spirit here. > That's fine. Let's let the votes decide rather than relying on strongarming. And cooperation means a bit more than "we've got 66% so we don't care about anything else". > Saying a problem doesn't exist doesn't make it go away. Except if it really doesn't exist, so there's nothing to go away :) -- Stas Malyshev smalys...@gmail.com
[PHP-DEV] Re: [PHP-CVS] com php-src: Fix tests I broke with the E_ERROR > E_RECOVERABLE_ERROR change: tests/output/ob_010.phpt tests/output/ob_011.phpt tests/output/ob_start_error_005.phpt
Hi! On Sun, Dec 28, 2014 at 10:54 PM, Kalle Sommer Nielsen wrote: > Commit:334b9718d578caa9f4c6d3c2f7e2fb9b65696dc3 > Author:Kalle Sommer Nielsen Mon, 29 Dec 2014 > 07:54:44 +0100 > Parents: 3bd96e0735f45359bc3cff2981acbd34c60770c9 > Branches: master > > Link: > http://git.php.net/?p=php-src.git;a=commitdiff;h=334b9718d578caa9f4c6d3c2f7e2fb9b65696dc3 > > Log: > Fix tests I broke with the E_ERROR > E_RECOVERABLE_ERROR change > The CI tests still seem to be failing: = FAILED TEST SUMMARY - SPL: spl_autoload() and friends [ext/spl/tests/spl_autoload_001.phpt] SPL: spl_autoload() with methods [ext/spl/tests/spl_autoload_005.phpt] SPL: spl_autoload() with inaccessible methods [ext/spl/tests/spl_autoload_007.phpt] SPL: spl_autoload() with exceptions [ext/spl/tests/spl_autoload_008.phpt] = Please take a look.
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! > Please refer to CWE/SANS TOP 25, Monster Mitigation especially. > > http://cwe.mitre.org/top25/#Mitigations > > and ISO 27000. (I cannot provide link to it, since one should buy the > document to read) Could you please be more specific about how this relevant to this specific case? "But an ISO standard and read it whole" is not exactly a good argument discussing specific issue. > Programmer should control over all inputs as the most important security > measure. > There are two strategies in general. > > - Convert inputs to secure values and ignore possible attacks. > (Sanitization) > - Validate inputs to reject malformed values and record possible > attacks. (Validation and logging) Thank you, I am aware of what sanitizing and validating input is. > to_int can be used as validation. It has advantage to record possible > attack (or bug). Logging is > one of important security feature. Therefore, validation could be said > more secure than sanitization. This is just your personal opinion. Logging is not a security feature, and if it were, it could be established independently, and should be anyway since to_* log nothing. So claiming to_* is a security feature is just wrong - it's like saying fopen() is a security feature because you could use it to open a log file to which you'd write security-relevant data. > Which strategy to adopt is that depends on organization/application > policy. Public web sites may ignore This is right. So your claim that one is more secure than the other is not correct. -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] forbid use declaration outside of a namespace in PHP 7
Hi! > I don’t like the sound of changing the spec before the implementation. I agree - whatever are our considerations and limitations on what we can and can not do in PHP 7, the spec should reflect what is there. Otherwise we end up releasing an implementation that does not match our own spec, that'd be embarrassing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
Hi! > makes user land code more readily equipped to enable the user to do that > handling. In the same way that it does for POST. This creates some more Well, for POST PHP actually parses the data - url encoding, form encoding, files, etc. - and puts it into the data structure. For generic REST case, it'd be harder to do the same because there are too many options of how the data could arrive. > For this to be possible in a more generic sense this would mean that PHP > only relies on the Content-encoding and Content-type headers to > determine how to decode the payload and parse its contents into super > global variables such as $_POST and $_FILES. This is currently what > PHP's SAPI implementation already does. The changes required to make Currently, it supports only basic form encodings. But if we get into handling all application types, it's a huge can of worms to have in core. > If the Content-type is applicatoin/json, for example, instead of the > normal application/x-www-form-urlencoded, PHP would simply parse the > enclosed entity body as JSON rather than urldecode it. If the That's not as easy as you think. Even JSON can have different encodings, be parsed in different way (json_decode right now has three options, and could have more in the future) an so on. But that's only JSON - why would then we single out JSON and not support XML or YAML or iCalendar or any other 1001 formats? > multipart/form-data MIME in the same way that post does, so encoding > can't vary. If the Content-type header is application/binary, for > example, we can simply make the file available in $_FILES or just leave There's no application/binary in standard MIME, ITYM application/octet-stream, but files do not have to be octet-stream, they can be of any type. And when you get the data, you in general don't know if it is meant to be a file or field or something else - that's on the app to decide. In the specific multipart/form-data case, we have content-disposition which tells us it was a file upload, but if it's not that format, all bets are off. In fact, nothing prevents a client from sending a file contents but the server treating it as a regular data field. > Here, I'm just proposing that PHP take on the addition of PUT handling > in a similar fashion that it does for POST, but only in the even that The problem is that while POST is used for forms (not only, but frequenly especially in webform context), PUT can be used for anything. We could of course make the core to identify PUT with mulitpart/form-data and parse it in the POST manner, I don't see any technical reason preventing that, but I think if you're already doing generic REST, then you'd be better served by generic parsing library (or a set of them) than by selecting one use case. I could be wrong of course, if PUT+mulitpart/form-data is a frequent use case and I just am not aware of it, then it makes sense to make RFC to add handling of it. So the question here is how common is the case of PUT+mulitpart/form-data? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
Hi! > Again, I think you're oversimplifying the problem. For one, you don't know > that the payload is JSON unless you check the Content-type header yourself, > and you really shouldn't have to since PHP could easily do this for you. Sure, PHP could easily do this, or any other one specific use case for you. What it can't do, however, is to do all 1000 use cases that modern REST application presents, automatically for you. What if you use XML and not JSON? What if you use both and determine which one it is by request URL suffix being .xml or .json? What if it instead is switched by query parameter? What if also it can be compressed, encrypted and wrapped in some MIME multipart message? Having all these complications handled in the core of PHP would be extremely hard, not because each of them is hard, but because there can be so many of them. And you'd run a big change of PHP still not matching your specific case exactly, or being behind times, because core can not evolve as quickly as userland does. That's why it's better done in extensions or user space - unless you can identify a case which covers a huge proportion of all cases - just like forms are for POST. For generic REST, I'm not sure there's such case, except for very generic API giving access to the basic request, its fields and supporting basic URL/MIME parsing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thresholds of backwards compatibility breaks
Hi! > - major BC break: major versions only. 5 major BC breaks allowed per major > version. I'm not sure how such numbers make sense. Why 5 and not 3 or 7 or 17? If that breaks your code, even one is too much. If your code is not affected, why would you care if it's 5 or 15 or 150? I'm afraid this would just devolve into semantics discussion and arguments about how to count them and why it can be 5 but not 6. I don't see any reason to put any numeric value on it. > - minor BC break: > - minor versions: 5 minor BC breaks allowed. > - patch versions: 1 BC break allowed. Patch & minors should not have BC breaks, excepting bugfixes where it is inevitable. Of course, it is an ideal situation, and in practice we may miss stuff, or we may not have a choice, or we may prefer BC break to the alternative. But again I don't see how putting a number on it helps something. If we have two cases where we must have BC break and not one - and we absolutely sure we have no better choice and that's what we have to do - how having arbitrary limit of 1 would help? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator
Hi! > This is exactly what I'm doing right now, requiring the expression to > always be enclosed in parenthesis. I think it's way better to be able to > do this instead of creating temporary variables just to assign a class Why? What's so bad in variables? It doesn't cost that much and makes you code clearer. > name. Also, is_a, since it's a function, is significantly slower than > instanceof, which is a construct (but of course you already now that). I find it very hard to accept this particular argument. First, if your code significantly depends on the speed of instanceof, you probably have some very uncommon code that does some very uncommon things. For such code, changing syntax of PHP may be not the best idea. Secondly, if we discover that the speed of is_a is a common problem, we can treat it - i.e. by converting it to opcode, etc. - but in general the argument "function calls are too slow in PHP so we should have duplicates for them" sounds wrong. They are not *that* slow and in most cases it's completely fine to use functions. If your particular code is so performance-sensitive that the speed of instanceof really matters so much that function call is not acceptable, maybe it's time for a little C extension? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator
Hi!
> Also one thing not mentioned in the initial letter - this will also allow
> you to use expressions for new operator in the same way: `new
> (str_replace('/', '\\', $classPath))()` - just an example.
OK, if we apply it consistently - i.e. say anywhere that we allow
literal or ${variable-like expression} we also allow (generic
expression) - then it would probably work. I'm still not sure I like it
too much - for instance, if I saw something like the example above in
the code review, I'd ask to rewrite it with a variable, since it's
unreadable and all too easy to make a mistake. Variables are not that
bad, and not everything needs to be a one-liner.
> I would say that it's just not logical to have some operator that can
> accept dynamic (runtime-defined) value but not an expression.
Right now, many constructs do exactly that - they accept literal or
variable (with some stretching of what "variable" is, esp. with uniform
syntax RFC which allows to stuff quite a lot in a variable) but not
generic expression. However, the same uniform variable RFC allows many
operations now to accept expressions via (expression) syntax, so maybe
we can expand on that further and allow this in any context where
literal+variable previously were accepted. I.e. now FOO() accepts FOO
being (expression) but new FOO() does not, which does seem a bit
inconsistent. So maybe it can be done. I'm still not sure personally
doing this is a good thing - it is too easy to make code completely
incomprehensible with this - but maybe I'm wrong here.
I think it may be worth asking Nikita Popov if if it's be feasible to
extend his RFC to these cases.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator
Hi! > What I want to implement is the ability to allow arbitrary expressions on > the second operand, so instead of having to write something like this: I'm afraid there's a problem with this. Arbitrary expressions include constants, right? So what this means: var_dump($foo instanceof Bar); is it checking $foo for being instance of class Bar (that's what is happening now) or is it taking the value of the constant Bar (whatever it is) - since constant is an expression - and using it as a class name and then checking if $foo is an instance of that class? You could of course require the expression to always be enclosed in (), but that produces weird syntax where some forms of instanceof work without () and some only with (). Given that you can easily assign your value to a variable, is it worth it? Also, you can always use is_a($foo, $bar->getClassName()). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
Hi! > No, classes are not loaded for type checks, since it would be pointless > - if the class is not loaded, you could not have a value of that type, > so if the class is not present, the answer is "no". > > > It's not true anymore, with this proposal. This is not good. The base premise of type checks always was if you don't use them, they are basically free - you don't load the classes, you don't do any work, until you actually need them, and by then your class is supposed to be already loaded, so again it's not costly. But if just declaring a type could trigger loading of code, this may significantly increase the footprint and loading time for classes that have many options but only use some of them at the time. Also, it is kind of weird that arguments require exact match but return types do not. Not that we care for consistency anymore... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
Hi! > Do we always load the class in the hint? We could perhaps only do it > for inheritance checks? No, classes are not loaded for type checks, since it would be pointless - if the class is not loaded, you could not have a value of that type, so if the class is not present, the answer is "no". -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > C++11 adds suffixed types for returns despite having prefixed types > for everything else, including previous return types. C++ does it for entirely different reasons, related to scoping, and it still has "auto" type at the beginning. In any case, I'd be very vary taking late C++ hacks as a guide for syntax, as advanced C++ syntax is not something I would recommend as an example of clarity. > 3) Claiming compatibility for things which aren't proposed is meaningless. > > People have already asked for support for static return types; doing People asked for a lot of things, it doesn't mean it makes sense. "static" as return type doesn't, since it does not specify any type at all - it just says "I will return a type that is this class or derived from this class" - which is the same as saying 'self'. There's no additional information one can gather from 'static' declaration which is not in 'self' declaration, and I see no use case to ever use it. > ` "function" "( ")` would > then be ambiguous. This is not some pie-in-the sky issue. It's not, it's a non-issue at all, since "static" does not make sense in that context. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > What arguments do you have in favor of doing ` "function" > "( ")`? So far I haven't heard any We already using "type before entity" for parameter typing, and it is a natural way to do it, both from linguistic perspective (in English, we say "green house", not "house: green") and it is the way used in all languages that PHP borrowed the concepts from, such as C, C++, Java, etc. No language I can think of (excepting Hack) does parameters as but functions as : - they use or always the former, or always the latter. Making PHP the only language that uses half that and half this would further add to the reputation of PHP being inconsistent and haphazard language. If we consistently used "entity : type", it would be acceptable, though detaching somewhat from PHP roots. But what is being proposed is to use half this and half that. And this is not a very good idea, IMHO. I already wrote all this in previous emails, but for those who accidentally missed them I don't mind repeating. > Other examples not already included are generics and function signatures as types. We did not see any proposal for generics or anything else, but as examples of C++ and Java amply prove, there's no problems working with generics and having this syntax. In any case, we do not have any proposals right now and any argument relating to generics whatsoever, so telling "oh, my proposal is better because generics and other awesome stuff that maybe will happen but I'm not telling now" is a meaningless argument, since it does not specify any connection between your proposal and generics - it only uses a vague dream of having generics in the future to hint at nonexistent advantage your proposal would provide in the present. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > Except `static function()` and `static function foo()` already have > meaning, and if we allowed static return types (very possible) that > would be ambiguous. This syntax is a no-go. If it is possible, why it's not the part of the RFC? Probably because there's not much place where it would make sense. So, the only objections so far have been: 1. Foo function bar() somehow is not greppable 2. It is not clear that Foo function bar() means function 3. We could somehow in some undefined time in the future allow static there, even though we're designing it right now and we actually *do not* allow it and see no reason to allow it. 4. People would think in "Foo function bar()" "Foo" is somehow type of the whole function, not its return value, despite PHP having no concept of function type at all and no means to express such type and no need to do so. 5. Using ":" is more consistent, because it's "output type", so it is not the same as type on parameters. 6. It's inconsistent with "normal function declarations". 7. We discussed it on Stack Overflow, and decided it's not inconsistent. 8. "It is weird". 9. "It is a no go". Does this really sound convincing argument to anybody? Because it definitely doesn't to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotation PHP 7
Hi! > Primarily, I do not see docblocks as the right place to store class' metadata information. Metadata != Comments. I personally regard this as a kind of superstition. There's nothing wrong with extending what can be in comments. In fact, Javascript was officially "HTML comment" for years, and it didn't prevent anybody from using Javascript. There are instances of significant comments in various environments. Outright refusing comments can be significant is just arbitrarily limiting our options for no reason. I don't say it necessarily the best option, but we should not reject it because "oh noes, significant comments!". It has been done, and it's nothing special, just one of the possibilities > This brings the next piece of the puzzle. We have to update lexical and > semantical understanding of PHP. Taking Java's approach (@) does not > work in PHP, because it conflicts with error supression. Same thing Except for the mental context, how @ conflicts with errors? Suppression is always in runtime context and applied to expressions, annotations are always outside of it and apply to declarations. Unless of course you want to annotate variables and closures, but I'm not sure annotating expressions is such a good idea anyway. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()
Hi! > To clarify: I don't think it makes sense to add an additional security > option, if we cannot say that unserialize() is to our knowledge *fully* That's where we disagree. I think security is a spectrum, and you can make it better. It looks like you think it's binary - either it is *fully* airtight secure, or there's no point even bothering. I think there is a point. > Just looking at your implementation again, it looks like "false" is not > a special value and you actually accept anything, regardless of type. So The RFC is not about specific pull, it's about the design. If there are bugs in the pull, it can be fixed. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi!
> But it’s rather weird for closures:
>
> $foo = Foo function () {
> };
Not much weirder than:
$foo = static function () { ... }
which we already have. Putting modifiers in front of the function is
nothing foreign to PHP.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()
Hi! > I'm -1 on this RFC, because I think this only further encourages > ill-advised usages of unserialize() on user-provided strings. I don't I guess that's where we disagree. I think that security is a layered approach (see more here: http://php100.wordpress.com/2014/11/03/unserialize-and-being-practical/). Some people think that if somebody deviates from the best practice, however good are the reasons, there should be no support whatsoever in securing the alternative approach since it "encourages" departing from best practices. I think this approach is wrong. > format allows you to create references. I'd imagine that you can easily > use this to cause a DOS condition if the code processing the unserialize > output uses any kind of recursion. I'm not sure what you mean here. I'm not aware of any way to cause any recursion or DoS when parsing serialized data, as for user-side data processing, of course I do not attempt to cure the world and solve the halting problem, I only give you a tool to filter data. If you store recursive data structures in your data and process it, this RFC does not provide recursion protection, we can not do everything in one RFC :) > Furthermore I dislike some details of the particular implementation: The > ability to use false as a synonym for [] seems unnecessary. Directly I could make it produce an error on false, but I don't see what use case it would help. If you have such use case, please describe it. > using an extra argument will be inconvenient for future additions, e.g. > if you really wanted to more this secure, you'd probably also want to > have options to disable references and to limit the cumulative number of > array elements (hashdos). I'd prefer using an options array for this. I sill have hope named parameters happen some time, which would eliminate the need option arrays. Since right now we have only one option, I think option array is redundant here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > Because if that function has a return type, e.g.: > > public function Foo bar() > > Then you couldn’t grep for “function bar” because of the Foo. And that's not what I have proposed. Would anybody actually *read* what I am proposing? Or reading is optional for discussion now? > If we used this syntax instead, which wouldn’t disrupt grep: > > public Foo function bar(); > > It’d be inconsistent with normal function declarations which would have to > have Foo after function. What's "normal function" and why it would have to have "Foo" after function? What's wrong with "Foo function bar()"? It reads nicely (at least in English, where the natural word order is adjective-noun, not noun-adjective), it does not disrupt any searches, what exactly is wrong with it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotation PHP 7
Hi!
> The approach for annotations that I like best would actually be not
> annotations, but Python-style decorators. They’re very simple, but
> very powerful. They would allow you to do annotations, but also add
> extra functionality to functions.
For python-style decorators, at least the way they work in Python, we'd
need to organize our function tables differently, as Python just
replaces the function with another one while decorating, and I'm not
sure it'd be as easy to do with PHP.
> Which would be equivalent to the following PHP code:
>
> $myfunc = function myfunc() { # function source code here }; $myfunc
> = some_decorator($myfunc, foo, bar);
Not really, because functions work differently in Python and in PHP. You
can not just replace a function in class's function table with random
closure in PHP, at least easily.
You'd have to convert all such functions to closures (or something that
can be both, maybe) and have the engine be aware that function table now
can store closures. And, also, inheritance may get a bit weird there. It
would be very powerful, but it may not be very simple to do.
Also, it is a major overkill for what annotations are commonly used -
attaching a piece of data to an entity. In Python, decorators are very
powerful for modifying function behavior (i.e., attaching pre/post
conditions to functions or doing some things phpunit does is really
easy) but it is too much for just attaching data.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotation PHP 7
Hi!
> All projects mentioned in this thread use:
> http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html
> That makes a pretty good base spec.
Reading it, it looks pretty big - strictly typed values, named
parameters, default constructors linked to properties, support for enum
types, support for typed arrays, separate constant syntax within
annotations. These are all features not supported in PHP, and it seems a
bit weird to me to have mini-language inside PHP that would support
these. And, of course, arbitrary depth recursive annotations, and for
some reason separate array syntax using {} and not [].
Moreover, there's extensive checking for annotations with exceptions
thrown if any of the above doesn't typecheck - I'm not even sure where
that would fit in PHP parser.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] Types on the right or on the left
Hi! > In PHP, input types go on the left and output types go on the right. What is the "output type"? If I wanted to type a variable - is it input or output? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] Types on the right or on the left
Hi! > I thought it was inconsistent, but after discussions on > StackOverflow, I don't think it actually is. If you specify the type once as "Foo something" and once as "something: Foo" then I don't see how there's even a place for discussions that it's inconsistent. > Return types describe the return type of a function, not the type of > a function. Given that in PHP functions do not have types, not being objects of the language, this seems to be argument invented just to ignore the inconsistency. Moreover, in languages where functions do have types - e.g. ML for example - the return of the function is specified in exactly the same manner as parameter type, and type of the function itself is never specified explicitly, but if needed, it is referred to with different syntax (->). See: https://en.wikipedia.org/wiki/Standard_ML Same situation with ActionScript: https://en.wikipedia.org/wiki/ActionScript both parameters and return type use ":" and nobody thinks that specifies type of the function - as, again, nobody ever specifies type of the function as such. In fact, I can remember no language that would specify type of the function (as opposed to parameters + returns) when declaring a function, even among languages with first class functions. > Also, it's worth bearing in mind that `public Foo function` was > rejected previously. Many things were rejected previously, but the RFC does not bring any argument about it and never even mentions it as far as I can see. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] Types on the right or on the left
Hi! >> "public Foo function bar()" would be so much worse than "public function >> bar() : Foo" > > Because when you grep for "function bar", in future you'd have to know > the return type too. Sorry, I do not understand - why to grep for "function bar" you'd have to know the type? Just grep for "function bar" as you did before. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotation PHP 7
Hi! > As I do consider personal tastes important, there are times where we should > listen to our users. It would be nice to take "paving the walkways" approach, but last time we tried, IIRC we've got into something very over-engineered. Maybe if we try again with more restricted scope (i.e. not trying to put a DSL for describing arbitrarily complex data structures into it :) it would be more successful this time. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] Types on the right or on the left
Hi! > put types only on the right, or only on the left or mix it. I > followed the return type RFC and thus know that many people think it > has to be on the left hand side. Fair enough, I do not have anything > against such a decision. I also have nothing against putting the type > on the right hand side. What merely bothers me is that it would be > another inconsistency in the language design. It's not very intuitive > for a user if a type hint is once on the right hand side and once on > the left hand side. I agree, this is not a very good situation. It would be much better to take a systematic approach to this, but this is impossible since there is no systematic approach to strict typing in PHP, just some pieces here and there. I think this is not right, but obviously many people here disagree and are happy to have the inconsistent syntax. I don't see why "public Foo function bar()" would be so much worse than "public function bar() : Foo" but for some reason this possibility wasn't even considered as far as I can see. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG scope
Hi! > - PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb > like commands to debug, and step through code. That was also my impression when the RFC was discussed. Now, I do not object in principle on growing the scope of phpdbg. But this needs to be done the right way if it's the php.net core part - having an RFC that explains what exactly happens and why, getting consensus, and only then merging. > Then later, they "documented a way that you could use it to emulate an > HTTP request, by setting those superglobals and executing your index.php > - your code doesn't know the difference between a real request, and a > cli-like script with the same super globals set." I don't think this as such is a bad idea, I wouldn't mind having such thing available, I can see use cases where it would be handy. So I think it would be useful to have some ordered RFC describing where phpdbg wants to expand to and then we can discuss it and see if we can arrive at something that would be ok with everybody. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()
Hi! > I wonder how often the final parameter will simply be > get_declared_classes() That would be quite dangerous as there are a lot of classes in the extensions, not all of them are your friends. Also, in a big projects, you don't always know which classes may be currently loaded. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()
Hi! > Coming late to the discussion. Was there any discussion to make the > new argument a callback instead? Pass it the fully-qualified class > name, have it return true (the class should be loaded) or false (the > class should not be loaded). Deprecate the `unserialize_callback_func` > mechanism at the same time. That was not discussed. It can be made this way, though it would be more complicated and have more moving parts, but that's not part of the present RFC. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [VOTE] Filtered unserialize()
Hi! I'd like to put to vote my proposal about the filtered unserialize(): https://wiki.php.net/rfc/secure_unserialize It was discussed a number of times before and I think it is time to have a decision on it. If you need any clarifications on the proposal, please do not hesitate to ask. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > Again, an unfair comparison. Hack isn’t intended to be a completely I'm not sure what you refer to by "fair". Hack is not "intended", but IS a separate language - just read the manual and you will see, it is a new language which borrows some syntax from PHP. Just read their own site: Hack is a programming language for HHVM that interoperates seamlessly with PHP. I completely agree with this statement - Hack is a programming language that is different from PHP but built in a way to interoperate with it. > separate language. It’s supposed to be an augmented PHP, which is The fact that you can run (some) PHP code in Hack is a feature of Hack, the same way as if you craft Perl code I'm sure there is some code that you can run with minimal modification in PHP. So what? I'm not sure what you mean by "augmented" - you can claim C++ is an "augmented assembly language" since you can insert assembly pieces into C++ code and it would work. But that would make little sense, since C++ goes way beyond and is a separate language. That yes, with some iterations, borrowed some things (one may say too many if so inclined) from lower-level languages, but it does not mean it *is* any of those. > compatible with PHP. PHP code can use Hack code (in HHVM, anyway) and PHP code can use C, C++, Java or Lua code with suitable extensions. So what? > Hack code can use PHP code. Hack is a superset of PHP. There are > transitional modes, too. I'm not sure how this is relevant. Hack is a new language and a new project, with its own design, its own rules, its own governorship, its own community, its own everything. It's not something that is an opinion, it's an obvious fact. Trying to present it as if it is some part of PHP project just makes no sense to me. Yes, it build on PHP and it is great for many practical and theoretical reasons. But it does not change the plain fact of Hack being its own project and its own language. I honestly do not understand why recognition of this simple fact is such an issue. > The damage is in fragmentation. Hack threatens to fragment the PHP > community by making people jump ship to use its added features. While I don't understand that "jump ship" mentality. In last couple of months, I have used at least 6 different programming languages (not counting stuff like config languages, shell scripts, etc.) Did I "jump ship" every time? If I use PHP, am I somehow married to it and using another language is somehow becomes "cheating"? Is it the case that once I use Hack I somehow not allowed to use PHP again because I "jumped ship"? What is that "jumping" thing? I say - let people use Hack as much as they want. Let them use PHP as much as they want. Let them use anything their heart likes as much as they want. There's absolutely no "damage" or "threat" in that. PHP is not diminished because somebody is using another language, even if that language uses dollars before variable names. If PHP is ever diminished, the only reason would be because PHP is not serving its community needs well enough anymore. That what we should be thinking about - how to make PHP better suited for its users, not how to prevent people from using other languages. > the whole Hack community can use PHP libraries, only some of the PHP > community (HHVM users) can use Hack code. The consequences of this > could be severe. I do not see any "severe" consequences on that at all. If there are Hack libraries that are so awesome PHP community wants them, they'll be ported or interfaced - as happened to number of other libraries. > I’d rather there are less differences between PHP and Hack so there > are less reasons to switch. Though I suppose the specific syntax of > types is probably not a major issue. If you need Hack, by all means use Hack. There's absolutely no problem and no threat in this. If you need PHP, use PHP. I think our work here is to make PHP better, not somehow prevent people from using Hack or change PHP in a way that would make people less inclined to use Hack. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > This is an unfair comparison. Hack is a compatible superset of PHP, > much like TypeScript is a compatible superset of JavaScript. So? PHP once borrowed Perl syntax, and Java syntax, and so on. Hack borrowed PHP syntax, and that's great. But that doesn't mean what they do in their own language should constraint what we do in PHP. > I’d rather there be less divergence between Hack and PHP, to limit > the damage that it causes to the community. I don't see any damage to the community. How PHP not matching other language's syntax does any damage to the community? What kind of damage and where this damage comes from? Are we damaged because PHP arrays and Perl arrays have different syntax, despite obvious Perl roots in PHP? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > PHP doesn’t need more inconsistency, sure, but we must be practical > here. It is bad if PHP and Hack have the same feature with different > syntax, it will cause developer confusion and further segment the > communities. Given that Hack is a different language, which was designed AFAIK with little input from PHP community, I don't see how there would be any confusion - it's like saying PHP and Perl or PHP and Java having different syntaxes leads to segmenting the communities. In fact, there are two different communities - though, of course, people can belong to both - and two different languages. I do not think Hack syntax should have much weight in decisions about what syntax to choose in PHP - it's a different language, even though it has many similarities. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
Hi! > Also, removing $_GET and $_POST is a *massive* > backwards-compatibility break. I would vote against this proposal and > I hope everyone else will join me in doing so, for that reason > alone. I think removing $_* is a no go and even discussing it is kind of pointless unless somebody wants to create a completely new language only barely connected to PHP. Creating a more advanced HTTP API is a good thing, but I'd look to cooperate with pecl/http on that maybe? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team
Hi! >> I would like to propose the creation of a team to triage the pull requests >> on GitHub, to help ensure that the pull requests are handled in a timely >> manner. I am also volunteering to lead such a team, should the RFC be >> approved. I've read the proposal, and the idea of labeling the PRs and having reports looks good. The only thing I would be more careful about is closing the requests - 2 weeks sounds a bit too aggressive, I'd chose something like a month. Inactive pull does not consume any resources, and it's much better to have a pull lie around for some time and be picked up when somebody has time to look at it than to bury it and lose a contribution. Many PRs also get stuck in limbo because they either need some minor modification that the original author does not provide because he either lost interest or unaware of the need, or need somebody interested to push the discussion forward. In the former case, it would be nice for someone to make the minor change, which is mostly the question of time investment. In the latter, it's more the question of need - does somebody need this change enough? Closing such requests would be ok provided it'd be easy to resurrect them in case somebody gets interested. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team
Hi! > Slightly off-topic, but how about the same thing for bugs.php.net and > patches? I'd say this would be excellent - somebody contributing time to triage the bugs on bugs.php.net and separating "I made a typo but I'm sure it's PHP's fault" from "I discovered a major case of broken but nobody knows about it", giving suitable feedback for the former and raising profile of the latter on internals - that would be awesome. I think that would also have more people that have knowledge to fix bugs but only have limited to spend on them be able to contribute much more efficiently. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
Hi! > The behaviour of PHP is ABSOLUTELY in compliance with the RFC 6265. > Setting two headers may not follow best practice but it is conformant, > and it is only doing what the users PHP script told it to do. I think I agree here - we're providing a low level API, and if somebody uses this API in a manner contrary to best practices, it's on them, but as long as it is not prohibited by the RFC, we should support this behavior in case the users have good reasons to do this. Yes, in 99% of cases it would not be a good reason - that's why it is not the best practice - but as it is not prohibited, there would be valid 1% of cases where it is required by the user. As I see now, the behavior of following user instructions does not break anything, right? It just allows the user to do something that the RFC says he SHOULD NOT do. But I don't think this is a priority to enforce best practices in a low level API, risking breaking BC and causing trouble. If there's a case for higher level API enforcing the best practices, fine, HTTP classes (like pecl/http ones) or frameworks can always handle this. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi! > My only concern at this point is the default value of the hash. If we > were to use spl _object_hash, we could be setting a precedence that a > hash must be unique to each object. I don't think there should be any default value. Most objects are not suitable as keys, only some of them are (they must be immutable and have easily derived identity). So the default is to not allow it for arbitrary object. The programmer should specially designate the objects to be suitable for hashing by creating the hash function - and there the suitable function can be used, spl_object_hash or stringification or anything else, depending on the actual case. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi!
> Put another way, I think a key question here is:
>
> class Foo {
>public $bar;
> }
>
> $a = new Foo;
> $a->bar = 'baz';
> $b = new Foo;
> $b->bar = 'baz';
>
> $arr[$a] = true;
> $arr[$b] = true;
>
>
> Does $arr now contain one value or two?
That depends on the semantics of class Foo. If Foo is something like
UString, then it should contain one value, since UString is a value
object (https://en.wikipedia.org/wiki/Value_object) - or at least it
should be. However, if Foo represents something having separate identity
- i.e. it's a Person class and 'bar' represents name - then of course it
should contain two values, since the name is not the sole source of
Person's identity. So the decision is on you as a programmer.
And to give you the tool to make this decision and let PHP engine know
about is exactly the point of this RFC.
> If the desire is for it to contain 2, then spl_object_hash($a) already
> has that covered, I think.
>
> If the desire is for it to contain 1, then the proposal sounds like a
> way to normalize Foo::stringifiedValueObjectEquivalent().
You can describe it as such, but in a proper standartized way and with
syntax that allows you to use same syntax constructs on all keys and not
have to check each time if it's a special value and call a special
function on it (same purpose as for __toString).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: phpdbg situation in PHP-5.6
Hi! > An alternative would be just putting a few #if 0 in code > (phpdbg_out.c where the outputting of anything is centralized) to > make XML stuff not usable. Maybe that one is the cleanest and least > invasive with still allowing us to change the whole XML stuff. And at > the same time the normal improvements would still go into 5.6.3? Hot-patching with if-0's is not how things should be done in stable branch. If the code is not ready for prime time - which is obviously the case here - it should be developed - and tested! - in the feature branch. Then merged to master. And only then, after proving working - wait for it - put to discussion on internals about getting it into stable branch. Dumping it into a stable branch and hoping "maybe we get lucky and can get it into the next release" is not how release management should be done. Stable branch is called "stable" for a reason. This is not something critical that we have to release ASAP or the world burns. It's not a security fix. It's not even a critical feature millions asked for for years and this is the only chance to get it in. There is absolutely enough time to do it right. So let's do it right. >> To add for 3.: Issues where with what I really couldn’t think of >> (separate build dir on Linux…) or the issues with a JSON dep or >> Windows which I couldn’t test. And that's exactly the point. It's not your failure. It's nobody's failure. That's how the software world works - you can not foresee everything. You have to test. That's why we do not start with merging into the stable branch a day before the RC. It's not because somebody's code is particularly bad. It's because the release practices are the result of experience - if you don't do it, you *will* have trouble about which you had no way of knowing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Hi! > phpdbg is under php.net ; every decision about phpdbg should then be > debatted with all the team, and new ideas, such as a protocol, RFC'ed, > whoever are the maintainers of the code. It's like that for every > piece of code, of every extension. This is PHP process. If you dont > want to Do I understand it right that after all we've being discussing here about not putting big new stuff into PHP without discussion, we've got new stuff in phpdbg now merged not only to master but into the stable branch of 5.6? Am I missing something here? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Serialize filtering
Hi! > Suggestion on improving the API: Why bother with three values? > > If there’s no parameter, use current behaviour. If there’s an array, > it’s allowed classes. If that array is empty, obviously there are no > allowed classes. You are right, empty array probably would do the same thing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Currently supported versions of PHP
Hi! > It hasn't propagated to all the mirrors yet, but we now have > http://us2.php.net/supported-versions.php, as suggested. I used the The page looks good, but we've moved 5.4 to security-only on 18 Sep 2014 (5.4.33), and it'll be supported for 1 year starting that date. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi! > As others noted, it also prevents a full-fledged objects-as-key > implementation in the future. You do realize to have such implementation we'd need to rewrite our hash layer completely and also introduce the concept of immutable object, otherwise changing the object would make the hash completely broken? Which means it would probably never happen unless PHP engine is radically rewritten. > > In the end it causes issues and brings very little compared to an > explicit call to convert an object to a key. Same as __toString obviously is useless as you could just call a method explicitly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi! > Is the resulting value intended always to return the same object > independent of what has been done to the object in the mean time? That's on you to decide. If you have immutable value object, then yes. If you have mutable value object (which usually isn't a good idea, but who knows) then no. If it's not a value object, then probably you don't want __hash on it at all. > A fixed 'address' for the physical data when used as an array key? If > that is the case, then __toKey seems more comfortable. To me a hash is I'm fine with __toKey, if that's what seems better to the majority. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Serialize filtering
Hi! I'd like to have a vote on unserialize() improvement proposal outlined here: https://wiki.php.net/rfc/secure_unserialize soon-ish, but since discussion on it has been more than a year ago I'd like to give it some prior notice and some time to re-consider. I still think it is a good improvement, not fixing all problems but allowing to fix some at reasonable cost. I've added some outline of arguments discussed before, but still open for comments. The patch is probably outdated but I'll fix it if it's accepted, if not I don't want to spend time on it. I'd like to have a vote sometime next week, but if there's more discussion it can be postponed. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi! > Once your proposal is in the language, you will never, in the future, be > able to add real support for objects as keys, because the semantics is > blocked. This implies this support is not "real" and we want some other support. I don't think I agree with either. > I do understand where your proposal is coming from and what it is trying > to accomplish. But I think, at least, that it should clearly spell out > that any ambition to really support objects as array keys in the base > language, will then be given up. Was there ever such an ambition? Does somebody have any idea how to properly do it and a reason why? > I hardly see how that would make sense. SplObjectStorate operates with > object identity as determined by spl_object_hash, right? Changing that Now, it does, since there's no other option. However, in the future there may be other options - i.e. objects whose identity is not the same as their memory address. For example, for an object representing number (GMP) or string (UString) their identity is their content, not their memory address. Thus, if you want to use UString as an index, or have an unique set of strings, spl_object_hash would not be your friend. Of course, there's always an option of just telling it - e.g. by providing an option to the ctor. > Right. Somehow python manages to live quite fine with that fact. For some definitions of "quite fine", I presume - I can't see how a hashtable that repeatedly calls user code can be efficient. It probably isn't. > Right. You don't do that when your object implements __hash__ and __eq__. Or, more precisely, you're asked nicely not to do it - because there's no way to actually ensure it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi! > I don't like this, mainly because it blocks a future direct use and storage > of objects as keys in an array, i.e. what SplObjectStorage does. It does not. It just allows the objects to control how they are seen when they are used as keys in regular PHP arrays. That does not prevent SplObjectStorage or anything else from doing whatever one wants. I personally would say SplObjectStorage probably should respect __hash if provided, but we can discuss it separately. > It is also badly named, because it does NOT implement objects as keys. It > implements deriving surrogate keys from objects when used in an array key > context. That's how the objects are used as keys. Storing objects in the hashtable would really require rewriting the whole hashtable and would probably be very inefficient as you'd have to call PHP code each time you compare two objects in the chain. Moreover, modifying such objects would probably create havoc. So having an immutable value sounds like the best solution for the practical use cases. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi! > It seems __toScalar might be a good name, this is what the method > actually does, the engine then coerces to a type suitable for use as a > key, but you can return a double. It might be more forward thinking > therefore to use the name __toScalar, while today we'd only be using > it for this, __toScalar does not express the fact why we are calling it - to use it as a key. It's not just a scalar conversion, it's conversion for the purpose of hashing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi!
> I’m trying to wrap my head around a real-world use-case with this.
> We have spl_object_hash, which effectively provides a unique hash for
This hash has nothing to do with object's contents. But imagine number
GMP("42") and imagine you actually want two GMP objects expressing "42"
actually represent the same hash key. Or imagine you want to generate
the key somehow in a way related to object's content and not just a
random number. As I said in the RFC, evidence that so many languages
implement it shows that this use case is quite real. Of course, you can
always default to spl_object_hash, but now you have control over it.
> an object. If the intent is to provide an opportunity of individual
> classes to decide what their hash is, couldn’t they provide that via
> __toString? I know many frameworks use __toString to build out some
> implementation of an object (Zend form for example), but the point of
> __toString is to provide a string representation of an object.
This is covered in the RFC, right in the introduction.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Using objects as keys
Hi! I would like to present to your attention an RFC about using object as keys: https://wiki.php.net/rfc/objkey It was discussed in the past on the list: http://marc.info/?t=14114596961&r=1&w=2 and I think it makes sense to propose a formal RFC for it. Both the text and the code in the patch includes bits done by myself and Joe Watkins. The patch does not cover 100% of cases but should work for most reasonable scenarios, if something is wrong or you have ideas how to make it better please tell. The name __hash is not final, I am open to using __toKey instead or any reasonable alternative, we may also include a couple of options in the vote if that will be a point of disagreement. Thanks, Stas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi! > The only way to do this in PHP now is write a userland function that parses > multipart form data, which is non-trivial. I had written one, but would It is true that PUT data need to be parsed, however it is not true you have to implement MIME parsing from scratch. There are frameworks that implement that. Not everything must be written in C. But if you want C, doesn't pecl/http already have the required bits? > Having the ability to access the data provided in $_POST for other methods > is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if you want to do WebDAV? Wouldn't having separate superglobal for each be taking it a bit too far? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Hi! > Just a minor question, Derick. If you care about phpdbg, why are you > only dropping any comment about it by the time it got into php-src > repo? It’s known that all the development currently (except for > master, but that just was a merge and then a pure rewrite on top of > that merge, nothing related to the protocol) is going on in > krakjoe/phpdbg github repo. There was now an xml-protocol branch for > three weeks before it got merged into krakjoe/phpdbg#master. You had > vast time to notice it and complain before, if you’d really have > cared. I would like to weigh in here. If we're talking about things in PHP core repo, "we did it somewhere in public repo and nobody complained" is not a good stance. People do literally hundreds of things around PHP in public places, but not everything is part of PHP core. phpdbg now is. That involves not only good parts (by-default acceptance by millions of PHP users) but some obligations - like proper discussion and notification. Of course, since master is not stable yet, we have somewhat relaxed rules there, but even then introducing new debugging protocol into PHP core seems to be something that warrants some notification. As a person who spent significant time on implementing and maintaining one of PHP debugging solutions in the past, I, for example, would be interested to take a look into what is being checked into core repo in this regard. However, the first note I see about this happening is the commit messages. And that takes us back to old and not-so-good "check in first, discuss later" times. With project of the size of PHP, it having good process matters no less than having good code. So saying "we had this branch for whole three weeks before merging it into PHP repo" is not really saying much. That said, we are where we are, and I think it would be great if this would somehow server as a starting point for developing a unified protocol for debugging PHP. There are a number of good tools for debugging PHP, and it would be a pity if everybody invented their own protocols and required to install half-dozen of extensions to be compatible with all tools doing the same in slightly different way. We have so many unification efforts with PSR and the spec and so on, I'm pretty sure we can make a protocol that would be workable for all, debugging PHP is not exactly rocket surgery and there are not that many things there that we couldn't find a common ground. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
Hi! > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties that > makes them readable and writeable from different scopes. For me, this seems both too big and too small. Too small, because if you really it assigns a keyword to special use case of a generic feature, and thus I think does not lead us on the right path - we could not assign keywords to every behavior of properties, so either we forever reject the idea of having any generic solution there, or we'd eventually have two solutions, working in two different ways. Too big because this particular case is already very easy to implement by just making the property protected and having a public getter. It doesn't add any capability that we already don't have, and having a keyword just to save typing () seems unnecessary to me (performance is really irrelevant here, if your performance is bound by speed of accessors, you should be writing that code in C). Also, the name "readonly" appears misleading as it's not really read only - it's only read only for some classes, but writeable for others. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
Hi! > P.S. u() is a bad name, will break lots of code, i.e. Maybe __u()? It's a bit ugly but you're not allowed to use __ so it's safe. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
Hi! > Not ready for discussion yet ... > > https://wiki.php.net/rfc/hashkey Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess we should combine them :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! > Are you opposed to the existence of ext/filter given it has > FILTER_VALIDATE_INT, a “primitive for handling type conversions”? FILTER_VALIDATE_INT is an option for a filter_var function, and it is not introducing any new rules for handling types in the engine. What you are proposing is not like FILTER_VALIDATE_INT, it's like (int). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! > Yes, that’s still merely an implementation detail. If HHVM decides to > make explode() into an opcode, it’s not a language change. It is not > any different if PHP does the same. If HHVM decides to introduce new type handling rules, however, it is. Even if they are going to be called using ( and ). >> You propose to add completely new type conversion rules into the >> engine, in addition to ones already present and used there. It's >> not the same as merely changing how the engine internally runs >> pre-existing code. The new rules are definitely becoming major part >> of the language, not an implementation detail of some random >> function like str_pad. > > No, they’re just a set of new validation functions. No, they are not. They are new engine primitives for handling type conversions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! > No, it wouldn’t require a 2/3 majority. The optimisation me and > Dmitry are referring to is merely an optimisation, it’s an > implementation detail. This doesn’t touch any of the language spec or > the language as understood by users. Sorry, it's not "merely an optimization", it's making it an engine primitive, like (int) or empty() are. > Or would you argue that the fact is_long is now an opcode is a > language change, and Dmitry should’ve made an RFC before making a > change that is completely non-user-facing?! is_long existed long before that, and nothing changed for it. You propose to add completely new type conversion rules into the engine, in addition to ones already present and used there. It's not the same as merely changing how the engine internally runs pre-existing code. The new rules are definitely becoming major part of the language, not an implementation detail of some random function like str_pad. Saying "oh, we just add it like a random function and _only then_ we'll make it an opcode and it will be implementation detail" sounds a lot like gaming the system to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! > Thinking a bit more on this, if we don't want the 2/3 hurdle and perhaps > make this a bit (or actually a lot) less controversial, we should change the > names of these functions. to_float() strongly implies that this function > represents PHP's standard typing ruleset, which these functions do not. If it's done as part of filter or maybe even some aliases, like filter_float for example (I still not completely getting why one needs them, but assuming it's just my problem), then it can be considered filter part, under the condition that these rules are not set in the engine as "the rules" for treating the types - otherwise it's still be language change. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! >>> - it's probably make sense to implement these function as a new >> opcode(s) in VM >> >> That could be an optimisation later, yes. I note that you’ve added >> function replacement with opcodes for certain commonly-used functions. We >> could make these functions use that. Then they’d still be usable as >> callbacks. If those are opcodes, those rules will require 2/3 majority for acceptance, since those will be the engine rules for type conversion, not just a set of functions. And, of course, the rules not matching the other engine rules for type conversion, sorry for sounding like broken record. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
Hi! > Just a quick point: most of the core is not ASCII. PHP strings are byte > strings, completely divorced from any encoding. A few native functions > assume ISO8859-1 (or possibly Windows CP1252), but mostly they just > juggle which ever bytes you give them. True, but not all extensions and functions behave this way. Some (especially with intl, but not only) assume it's utf-8, for example, and for some utf-8 is a changeable default, which in practice often becomes the used encoding since people are not aware of need to track their encoding and most of them do use utf-8 anyway. > The main exception I can think of is that numbers are often handled > specially, with digits and separators as defined by ASCII. But since > we're talking UTF-8, that doesn't need to change. More interesting case actually is, well, case conversion. We unknowingly used locale-dependent lowercasing routines until the inevitable encounter with the dreaded Turkish 'i'. At which point we switched to forced ASCII. So identifiers in the engine are kind of assumed to be ASCII, even though you can somethimes sneak non-ASCII past it and it will work, but weirdly. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
Hi! > I wish there was a way for specific objects to opt into this. There will be, if __hashKey() or whatever would be the properly bikeshedded name, becomes reality as discussed elsewhere. It shouldn't be hard to do and it's exactly what many other languages do when trying to use objects as keys for maps. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
Hi! > https://wiki.php.net/rfc/ustring > > This is the result of work done by a few of us, we won't be opening any > vote in a fortnight. We have a long time before 7, there is no rush > whatever. Couple of thoughts: - I like the idea of having a unicode string class. May be a way to figure out the right way to do it without messing up the whole core. - I wish there were more description of which API this class provides. If it's planned to be direct copy of UnicodeString, some of the operations there are not how PHP strings usually work (i.e. in-place modification) and it's not really enough to make it useful - e.g. what if I need to do regexps on it, for example? Or does it cover whole mbstring API too? What about something mbstring doesn't cover, like ucfirst or strrev? - Do we really need different encodings, different backends and so on, internally? Note that each backend has its own quirks, limitations and bugs, and there's nothing worse than dealing with unpredictable set of dependencies. The user cares what they send into the class and what comes out, but very rarely they care what happens inside - why not just do it one way everywhere? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! > No, not quite. One of the nice things about rejecting whitespace is > it lets you handle it however you want. Want to reject all > whitespace? to_int($foo). Want to accept all whitespace? > to_int(trim($foo)). Want to trim only tabs? to_int(trim($foo, “\t”)). > This is actually allows more flexibility than filter_var does with > its maze of flags. This looks like "if you don't like my rules, you can easily apply string handling functions to implement any rule you like". Which makes total sense, except if I wanted to play with string handling functions, why not just write a regexp and be done with it? Of course you can do any transformation you like to the data, but if you propose it as a default solution, then "you can add more transformations" is not an advantage - you could always do that. > It would be possible to make to_int() merely an alias of > filter_var(…, FILTER_VALIDATE_INT). Though that would make it depend > on ext/filter or otherwise duplicate functionality. You seem to sound like depending on something already existing in PHP is a bad thing. > Also, treating whitespace differently wasn’t actually my idea. I’m > perfectly fine with ignoring it, but Nikita convinced me I shouldn’t > tolerate it. He has a point - it opens more possibilities than > allowing it. The point is not whether ignore or not ignore the whitespace. The point is that having multiple APIs doing the same but differing in one small detail because somebody thinks this detail is not exactly to his liking in existing API - IMO is not a good thing. > Not quite. With strict type hints, FALSE would fail for an integer PHP is not a strictly typed language, so arguing as if it were or just about to become one doesn't sound like a very good selling point. For me, it exactly the reverse - you're emphasizing the fact that for it to work, you need to change the whole nature of PHP not being a strictly typed language. > parameter. Even without them, this still makes validation more > straightforward. I suppose there are varying degrees of laziness. I'm not sure how using function starting with to_ is "more straightforward" than using function starting with filter_ - which seems to be the only thing different here. Except, of course, for whitespace handling. Which in my opinion, still does not explain why we should ignore existing API and create a completely new one. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! >> Wait, we actually already have FILTER_VALIDATE_INT and >> FILTER_VALIDATE_FLOAT, > > Actually, to_int is very close to FILTER_VALIDATE_INT, and I’m not > sure, but I think to_float may be close to FILTER_VALIDATE_FLOAT. The > main difference with integers is rejection of whitespace and > toString-able objects. So essentially we have a number of rules, which all are only slightly different. And when somebody wants to skip spaces, but not tabs, we'd have yet another set of functions? I don't think it's good for the language to have a set of functions doing exactly the same, but in slightly different way, because some people had different preferences. The language should not be just a bag of use-cases that somebody wanted to implement. We're getting a lot of criticism for parts of the language not always playing cohesively together, why make it worse? > The main point of the RFC is to add casting functions as an > alternative to the built-in explicit casts. Currently, the easiest > way to convert to an integer is (int), but this is quite dangerous as > it performs no validation whatsoever and cannot fail. to_int() and So, why not have filter_var($suspected_int, FILTER_VALIDATE_INT) and filter_var($suspected_int, FILTER_CONVERT_INT)? We already have infrastructure for that, why ignore it completely and build another solution that does exactly the same but treats whitespace differently and has couple of other tweaks? OK, you want to treat the whitespace differently, I get it - but why ignore whole filter infrastructure? > the like are intended to be just as convenient as an explicit cast, > so that doing the safer thing (failing on garbage input) is not any > more difficult. The hope is that the lazy developer will use is_int() > instead of (int) when they need to explicitly cast, and avoid the > problems of the latter. The lazy developer won't check the return value anyway and would get 0 as the result of false-to-int conversion, thus making the whole exercise pointless anyway :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
Hi! > I am presenting a new RFC to add a set of three functions to do validated > casts for scalar types: > > https://wiki.php.net/rfc/safe_cast > > Please read it. The main problem that happened with scalar typing RFC remains here: third set of rules for casting types. Of course, since it's "just" functions and not language constructs, we can have a set of functions for any set of casting rules anybody wants. But I think it's still the same problem here - having three sets of casting rules is not good. Wait, we actually already have FILTER_VALIDATE_INT and FILTER_VALIDATE_FLOAT, so that would be the fourth set of rules, and the second set of validation rules, despite already having an extension specially dedicated to filtering and validation. I think we should not multiply entities needlessly - if we need some different validation primitives, why not add them to filter, for example? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question regarding #67309
Hi! > resurrecting this thread in the hope of getting a bit more feedback. About removing functions - I don't really see any particular win in it. I mean, we'd have enough BC concerns in PHP 7 without having to worry about missing functions that didn't hurt anybody. However, it may be fine to add a note in the manual saying "please use ini_*, it's better style" or something like that. About adding getter for execution time - not sure if there's any practical need for it, though I wouldn't lose sleep if it were added :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.34 Released
Hello! The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.4.34 Stanislav Malyshev PHP 5.4 RM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi!
> I added the variable field, how do I get its value, with use the query
> method PUT and enctype="multipart/form-data"?
>
> This debate not for tediousness, this is a real problem, if you want
> to use the query method PUT and enctype="multipart/form-data",
> variable $_POST is empty and file_get_contents('php://input') is empty
No, file_get_contents('php://input') is not empty - I just checked it
and if you send PUT request the whole request - files and all - is in
the php://input. If you don't see it you might be doing something wrong.
You are talking about PUT, but post example about POST for the second
time. I'm not sure what you mean by that as certainly your script does
not demonstrate what you are saying.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi!
> if($_SERVER['REQUEST_METHOD'] == 'POST')
> {
> var_dump(file_get_contents('php://input'));
> exit;
> }
I tried this script, if you do POST, your data is in $_FILES, if you do
PUT, your data is in php://input. Still not sure what is the big problem.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi! > PHP today to enable successful & easy implementation of RESTful interfaces. Having done this, I beg to differ. > Try to send a parameter in the body, by PUT method, for reading > parameters have to use an ugly way file_get_contents(‘php://input') What exactly is the problem in this one-liner? > But yet worst, you can not do upload files and send parameters because > - php://input is not available with enctype="multipart/form-data" I'm not sure I understand what you're trying to do, could you explain in more detail with examples? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
Hi! > For the array-to-object conversion, no scanning is necessary, since the > internal implementation already knows which keys are integers and which > strings. For the vast majority of cases, the array passed in will have Could you explain this? How you know which keys are integers and which strings without actually checking them? > object. I would strongly suspect that most objects have very few > properties, and very few property names would pass a simple test of "is > first character a digit" but subsequently fail the full is numeric test. You still have to scan through all of them, even if they have no digits at all. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
Hi!
> Please correct me if I'm wrong but object properties should be strings
> in all cases.
In all cases where they are assigned as object properties. If they were
produced by other means, it can be different.
> So all properties set should be converted to string means the following
> should be equal but isn't and I don't see any performance issues forcing
> strings here:
While for objects all keys are strings, for arrays keys '123' and 123
are the same - integer 123.
>
> |$obj = (object)array('123' => '456');
> var_dump($obj);
Here the array had numeric index, so the object property became numeric
index too. The alternative for this would be for this operation to scan
through whole array and convert each key from numeric to string, which
given how exotic is this case seems to be a waste of time.
> For the case of object to array conversion a numeric check could be very
> improved by simply check if the first character between 0-9 before
> starting the complete numeric check. That would be very fest and it
You seem to ignore the fact that you still have to go through the whole
array and scan each key and convert some of them, and all this work in
99.9% of real cases is for nothing and is useful only in an invented
abstract example. So the question is - would this check be useful for
anything than fixing an exotic case which nobody ever encounters in
practice?
> produces right results. It's poor to say "... very narrow use case with
> hardly any legit uses ..." in programming languages. In my opinion the
> right result have to be the first goal and performance optimization is
> something to keep in mind but should never produce wrong results.
No. Performance is a feature. If we can have something that works for
all practical uses and is fast, it is much preferable than having
something that works in 100% of theoretical invented corner cases and in
practice is too slow to be useful since it is ridden with useless checks
just to cover the theoretical corner cases. So the question is - do we
really need this working that way for anything useful? If not, then
there's no point in fixing it, if yes - there is.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
Hi! > You throw an error. Just as plenty of functions already can’t handle > ridiculously large integer arguments. The problem is, if you function can handle the int range and you checked for is_int() and everything worked fine - now it's broken because is_int() no longer implies fixed range and there's no way to check if you're dealing with fixed-range number or infinite-range number. > No, it does: There are now integers, and objects that represent large > integers, which behave differently. IS_INT and IS_BIGINT would necessarily behave differently too - since some functions may support both and some only integers. Again, no change here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
Hi! > We already have this danger for another type: boolean. phpng got rid > of IS_BOOL in favour of IS_TRUE and IS_FALSE. If we can update > everything to handle the IS_BOOL change, surely we can update > everything to handle bigints, too. No, it's not the same thing at all. For bool, you still have only true and false. For bigint, your function now should be able to handle infinite integers internally, but what if it has fixed resources that assume integers have fixed range? For extensions, it's a commonplace, but even for user code that can happen. That means, any call that you do to an internal function with int argument now could fail since the internal function is unable to support bigint, and you can't even guard for this since your code can not distinguish regular int from bigint. I don't think it is a good situation. > Then get weird results when someone passes a large number in. Why would you get weird results? You describe some vague dangers but I didn't see any concrete example of what is different. > The main point of the RFC is to make integers completely consistent > across platforms and to remove the need to worry about overflow. Which does not change with my proposal. > Adding optional overflow to GMP means you still have to worry about > it. It doesn’t solve anything. You can already use GMP for You seem to misunderstand what my proposal is. It doesn't add any additional overflow, it just changes from using separate type masquerading as int to using objects. All the rest stays the same. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
Hi! > Still, it’s inconvenient. More for developers to worry about. I still have no idea why one would need a bigint constant, could you give an common example where you would do that? > No, only extensions. It is *completely* transparent to userland. > That’s the whole point. I'm not sure how it can be completely transparent if it's a different type. Is it still identifying as int? In this case, this is dangerous as some functions may not be able to accept big integers when accepting int arguments, but checks for is_int, etc. would pass. > Yes, but they don’t handle large integer objects already. So you pass > it a GMP object, it converts to a string, then that overflows and you > end up with a float when it converts it to a number. Which isn’t what > you wanted. Or, it handles it as a string, which is also not ideal, > as while a string and an int may be the same thing to some > extensions, they are not to others. If it's not, the extension has to handle it, the same way it has to handle bigint anyway if it makes difference for it. The point is many common cases are already covered, e.g. if the extension just needs a string, or if the bigint actually represents a small int, etc. > It’s not about “extensions your code needs”. If you need ext/gmp, you > can already require it. This RFC is about removing cross-platform > integer handling differences. But nothing changes there - it is still removing the diffs and it still requires GMP. The only change is you're not paying for it if you don't need it. > No, but existing code does have to handle float overflow. If you > allow that to optionally be int overflow, you now need to worry about > handling both. What's "float overflow"? I'm not sure I'm getting your point here. You don't need to handle anything - if your code doesn't care about big ints, you just do math as usual. If it does, then you have to check big ints are there, then do math as usual but be aware that int can be now of two different types. I don't see any difference from the RFC here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
Hi! > I'm not sure what this would solve. Sure, you could just use objects > instead of a new type, but both present exactly the same challenges. > Adding a new type isn't hard in itself. The problem is updating > everything which handles numbers and their associated tests. This Exactly. Since objects are convertable to numbers (and to anything, in fact) we get double profit here - we make objects work better and we achieve big integer support. And we don't need to handle new type where we don't need numbers > doesn't make my job any easier. It also wouldn't cover a few places > that a new type can, like constants. Another problem is this means I'm not sure I see much case for bigint constants. Would be pretty hard for me to come up with a case where you need such a constant, and if you do, you could just have a string constant and convert it to GMP in runtime. > that bigints are a separate thing from ints, meaning users have to > worry about a new type which sometimes behaves differently. This > isn't good. Under this RFC's proposal, however, bigints are a mere > implementation detail. So far as the user cares, there are just > ints. No, they are not implementation detail - they are whole new type, which means every extension and every piece of PHP code aware of types now needs to know about it and needs special code to handle it. I.e. you pass it to mysql - mysql needs to handle this type. You pass it to SOAP - SOAP needs to handle this type. Etc. But if it's an object, they already deal with objects, one way or another. > Making it optional destroys most of the benefits of the RFC. Instead > of reducing platform differences, it adds a massive new one. Now I'm not saying we have to make it optional. I'm just saying it's possible. > developers have to check whether or not bigints are enabled and have > two different code paths. That's much worse than the status quo. I don't see why you'd have two code paths. If you need bigints and they are not there, then you just fail, like with any extension your code needs and is not installed. If it's there, you just continue working. All the code existing now doesn't need bigints, and even in the future most code won't need it. But for some code it would just work like before, only with unlimited range now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: PHP 7.0 timeline
Hi! > IMO, AST, INT64, NG, Uniforme variables style is enough for a new > marjor version.. why we still need to wait? We don't need to just "wait", as sit and do nothing. We need to allocate time for other features. > New features which missed PHP7.0, they can target at 7.1 instead. Only features that preserve BC, which is a limiting factor. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: PHP 7.0 timeline
Hi! > we should freeze new features by the end of this year. then we could > release 7 asap I think this is way too aggressive. This means basically next to nothing that is not already has prepared RC gets into 7, since only discussion + vote would take at least a month for anything substantial, and you have to also work on RFC and patch. And not everybody has time to work on all this fulltime, and some discussions can be slow or long-winded. I think Zeev's timeline looks much better in this regard. I think GA mid-October 2015 sounds a bit optimistic, but who knows, maybe it's me that it too pessimistic :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: PHP 7.0 timeline
Hi! > do you remember how PHP6 dies? I do. We failed to implement proper Unicode support. How is it relevant now? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
Hi! > Since I don’t want this to languish as a ‘Draft’ forever, despite the > patch being incomplete, I am finally putting the Big Integer Support > RFC “Under Discussion”. > > The RFC can be found here: https://wiki.php.net/rfc/bigint This introduces new type, IS_BIGINT. However, given that GMP now supports arithmetical operations, I wonder if it won't be easier to do it in slightly different way, specifically create a hook that is going to be called when an operation is about to cause over/underflow and let GMP hook there and produce a GMP number (I'm not sure about the exact details how to actually do it, so it's just an idea now, but if it makes sense we can try to work out technical details). Of course, this would require some rough edges to be polished, such as what happens if you try to use it as int, or convert, etc. but this is already present with IS_BIGINT too, and additionally we already have conversion handlers for objects, which aren't consistently used in all cases but can be made so. The benefit is we're not creating anything completely new, we just improving how objects work. This would also allow anybody who doesn't like GMP big integers easily implement their own module to replace them. Moreover, this also allows to make the support for bigints optional - i.e., if you don't need bigints, you don't have to carry GMP and thus do not have to be bound by its license. What do you think? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
Hi! > ... like the hidden array element: http://3v4l.org/6uFqf > ... like the hidden object property: http://3v4l.org/RPJXH The issue seems to be that array lookup always looks for numeric results when looking for numeric-like keys. But when adding property, the numeric check is not done since properties are not supposed to be numeric. Thus, when converting the object to array, the property named "123" becomes inaccessible, because in array it is supposed to be under number 123. We could, of course, add numeric checks to properties, but it would slow things down only to serve very narrow use case with hardly any legit uses. We could also rewrite hashtable with numeric keys instead of string keys when doing conversion, but again that would be significant slowdown for a very rare use case. Not sure it's worth it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
Hi! I would say we should choose according to the following criteria: 1. Is anybody likely to use it, and if so, will dropping it impede adoption significantly? 2. Would using it get you into some trouble you can't see easily? 3. How easy it's to detect that something is broken due to BC change? According to this, I think it would be really good to do this: - move mysql and ereg out to PECL (disros can bundle them anyway, and pecl is available for all self builders so adoption won't be hurt much). - drop incompatible $this context calls (probably seriously messed up code) - drop magic quotes stuff (if the code relies on magic quotes, something is seriously wrong). However, I'd consider keeping the get function (always false) to keep code that checks for it running. It wouldn't really hurt anybody I think. - drop dl on FPM - this can lead to some bad crashes - drop preg_replace() eval - it's a security problem waiting to happen - I think it can be problematic for: - # style comments in ini files, it's harder to detect and fix and as far as I can see, # doesn't hurt anybody For the rest, don't really have a strong opinion but agree with Zeev on each function being removed gets upgrade barrier a little higher and adds more people to the list of "can not upgrade, need code working". With ini settings, it's a bit easier since one ini edit fixes everything on the server, no need to check millions of lines of code. However, if we just drop them it would be hard to detect that these no longer work, maybe we should produce an error if those are used? Same for removing options from stream context - in general, if the option stopped working, I think it's better to let the user know. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
Hi! >> We have chosen to deprecate features, including ext/mysql. If we now >> decide not to remove some of them for 7, we may just remove the >> deprecation flag as we are going to support them for the next decade >> as well, whether we like it or not. I don't see how this follows. We may keep them deprecated (which means - don't use this, it's bad idea) but not remove them to support older code. Deprecated doesn't have to mean "we will mandatory remove it in the next version", it may also mean "we no longer think this is a good idea, please move on from it". -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API
Hi! > The problem always existed, and it's that it is very hard to escape from > an API that is dictated by the language itself. It is not a problem, at least not a define problem - what is "escape from an API"? Why you would want to escape from the language you're writing in? > Getting gradually rid of those APIs and making them swappable pieces > simply increases the degree of freedom that we get in our applications, No, it does not. It increases the number of moving parts, makes the environment more uncertain, requires more testing and potentially fragments the ecosystem. > by having less people rely on stuff like `array_map` and `array_filter` Why would you want less people to use PHP features? More people should be using array_map, not less. > Right, and now they can be built in a way that isn't coupled with the > engine itself. It's not coupled with the engine, it's part of the PHP core functions (which is separate part of PHP from the engine). And I still have to see one reason why having them implemented in C is a problem. Without having this reason, the discussion is pointless. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API
Hi! > My point is that providing them as "userland implementation" even inside > core would be more interesting than having something magic going on > under the hood. It certainly may be "interesting", and nobody prevents you from writing a blog or implementing a library doing this. However, it is not the reason to change the core functions of PHP. > Yes, I realize that complete removal would completely kill PHP's > adoption for the next version, so I'm thinking about something like an > ini setting: > > "zeh_legacy_includeh = '/zeh/path/to/old/functions.php';" You're trying to solve a problem that did not exist before you tried to solve it. > Yet this would allow removing a lot of internal functions that were > written just for the sake of it, and move them to something that can be > maintained by a larger userbase. These functions weren't written "just for the sake of it". They were written because people needed it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API
Hi! > While rambling with some code today, I realized that `call_user_func` > behaves strangely, appearing and disappearing from stack traces depending > on versions of PHP. If there's a problem with these functions, some bug in backtrace reporting, they of course need to be fixed. However I see no reason at all to deprecate a widely used function and create a myriad of BC issues for no gain at all. Compatibility is a feature, and not only it is just a feature - it's one of the most requested and most influential features. BC breaks delay adoption of new versions by years, even for minor things. For major widely used things Please, when proposing removing something from PHP, check: 1. If it is widely used 2. If its removal gains huge benefit for PHP which can not be achieved by any other way If you answer yes on 1 or no on 2, then there's no point proposing this removal. That would only make the next version unadoptable for a decade. Remember, we still have people reluctant to move to 5.4, and you propose to have them to rewrite all their code and wait until all their libraries are rewritten (major cause of python 3 adoption problems is libraries) for what exactly? Yes, we can rewrite these functions in userland. So we can may others. The long standing tradition of PHP in this area is to go the extra mile for the user and actually provide helpful functions, even when duplicating the functionality already available in user-land, for the convenience of the user. But this is for adding things. For removing things, bar is much, much higher. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
Hi! > When do you plan to release a new 5.4.34 / 5.5.18 version with a fix for Next week. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GMP memory allocator, various issues
Hi! > Can you please elaborate a little ? > Doesn't such leak have to be fixed in ext/gmp ? We clean up the memory at the end of the request. But if the request ended abnormally and we had some active gmp objects, with gmp data allocated outside emalloc we could not clean that and it ends up being persistent memory leak. Also, of course, that also excepts gmp objects from PHP memory limit, which makes it less useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c Zen
Hi! > we discussed this issue with Nikita on IRC, and didn't find any use > cases for objects without ce now. > Nor in php neither in pecl. > Do you see any problems? Those were used to create "bridge" APIs - like Zend's Java bridge (not sure if supported now, probably not, and if it's still uses that), as far as I remember. It may be that PECL does not use it but people have internal extensions that are not published. So deleting a chunk of the API without as much as a note on internals is not really a good idea, I think. IRC discussion is not a public discussion, since most of the people are not present on the IRC and have no idea about anything being discussed there. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c Zen
Hi! > Commit:ee5b30fa197046973e813a80dd0b7c67827c0ae1 > Author:Nikita Popov Thu, 9 Oct 2014 13:58:14 +0200 > Parents: 43f1c94ddace679cac008b674ef983199a951542 > Branches: master > > Link: > http://git.php.net/?p=php-src.git;a=commitdiff;h=ee5b30fa197046973e813a80dd0b7c67827c0ae1 > > Log: > Remove support for classes without class entries > > get_class_entry must be non-NULL and return non-NULL. I wonder why this feature removal is done without even a note on the internals, let alone any discussion. Have I missed something? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] EXTENSIONS file (enchant, ereg, hash, opcache)
Hi! > * opcache For opcache I guess that'd be Dmitry probably. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
