Re: [PHP-DEV] $http_response_header
Hi all, On Wed, Feb 4, 2015 at 3:42 PM, Stanislav Malyshev wrote: > > About $php_errormsg , we have error_get_last(). > > About $http_response_headers, we have no replacement. > > > > Why not get rid of both ? > > I agree. Magically appearing variables are bad design and if we can get > rid of them, PHP 7 is the time. +1 -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] [RFC] Anonymous Classes
Hi! > For anyone else concerned, an anon class inside a parent class is only > able to act with its public interface. Yes, that is weird, but there > is currently no support in PHP for nested classes. True. I'm just thinking we'll end up in the same position as closures in 5.3 where scope support is sorely missing and I have to deal a lot with apps having to still support 5.3 and doing weird tricks because of that lack of support. OTOH, implementing it may not be easy as we have to reconcile 2 scopes there. Not a reason not to do it (I voted yes :) but a reason to prioritize fixing it soon. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
Hi! I was never happy about this particular hack but that said, unless we *know* it is not used widely (and I suspect it is in Japan etc. where we don't have a lot of visibility due to language barrier) we can't really remove it. Also, I'm not sure why should we remove it. Yes, it's a PITA for the code, but looking at it in another direction, it is only a PITA if people actually turn it on, which means they're using it (otherwise why turn it on?). Deprecating it may be ok provided we actually have some proposal as to what people should do instead. If we have consensus on deprecating it, I don't think it's a problem have it done in 7.0 since it's not a substantial code/feature change and beta period provides ample time for people to scream if it's unacceptable. If there's no consensus yet, I'd go for 7.1. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
On Fri, Mar 27, 2015 at 7:12 PM, Rowan Collins wrote: > Ferenc Kovacs wrote on 27/03/2015 16:50: > >> yeah, but we already mentioned/discussed this that the removal would >> require introducing another way (eg. adding a method) for fetching the >> headers. >> I think that introducing this method can happen in a minor version(without >> removing the $http_response_header variable), so I will create a pull >> request and ask Julien about including it in 5.5 and upwards. >> > > I've seen comments to this effect before, and don't really understand the > motivation for adding functions in patch versions. Personally, I'd never > rely on such a function, because it would mean my code relied on a version > spec like "(>= 5.5.23 && < 5.6.0) || >= 5.6.7", which is just horrible. > In general this is because we used to do this and because our releaseprocess rfc allows it. In this specific case I have a couple of reasons to not wait for the next minor: 1, 5.7 got voted down, so the next minor will be probably 7.1 and that is like 1.5-2 years in the future, depending on how much if any delay the 7.0 gets. 2, I could try to argue that this doesn't require an RFC and target 7.0 regardless of the feature freeze (which technically wouldn't be any more risky than targetting 5.5/5.6 and simply merging up) but that would probably cause drama and people would use it as precedence to try to get bigger/more destabilizing changes into 7.0. 3, just bumped into this issue today myself (and the lack of option to elegantly pass context options to get_headers() aka https://bugs.php.net/bug.php?id=55716 planning to send a PR for that one too) and seeing how fell under the radar I tried to see what I can do. > > And on the negative side, there's the (admittedly very small) possibility > of unexpectedly colliding with someone's existing function. > yeah, that is always a possibility, usually this is why we look around on google/github to avoid the common collisions, but technically we don't consider this BC break in a sense that it is still allowed by the releaseprocess RFC. > > The definition at SemVer.org (I know PHP doesn't officially follow this > definition, but it's a well-thought out point of reference) makes clear: > > > Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards > compatible functionality is introduced to the public API. > agree, albeit people rarely follow that properly: http://massalabs.com/dev/2014/03/12/battle-of-semver.html which is somewhat defeats the original idea. > > Isn't it enough if the new function, and the deprecation of the variable, > is snuck into 7.0, or added in 7.1? > that would be the safest option, I just don't think that in this specific case there are much risk doing it in a micro. if it turns out that we have a general consensus about changing our ways, I would support it (as you can find a bunch of mails/threads from me on this topic on this list), I just don't think that it is a good idea that sometimes we allow this to happen without anybody saying a word, and sometimes when don't. we should make up our mind and stick to it whatever we end up deciding.
Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
Le 15/03/2015 04:23, Sammy Kaye Powers a écrit : A two week discussion period has been held for the reliable user-land CSPRNG RFC to add `random_bytes()` and `random_int()`. The RFC has now been moved into voting. Hi, We've talked about this RFC with other people at AFUP and are +1. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
Ferenc Kovacs wrote on 27/03/2015 16:50: yeah, but we already mentioned/discussed this that the removal would require introducing another way (eg. adding a method) for fetching the headers. I think that introducing this method can happen in a minor version(without removing the $http_response_header variable), so I will create a pull request and ask Julien about including it in 5.5 and upwards. I've seen comments to this effect before, and don't really understand the motivation for adding functions in patch versions. Personally, I'd never rely on such a function, because it would mean my code relied on a version spec like "(>= 5.5.23 && < 5.6.0) || >= 5.6.7", which is just horrible. And on the negative side, there's the (admittedly very small) possibility of unexpectedly colliding with someone's existing function. The definition at SemVer.org (I know PHP doesn't officially follow this definition, but it's a well-thought out point of reference) makes clear: > Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. Isn't it enough if the new function, and the deprecation of the variable, is snuck into 7.0, or added in 7.1? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
On Fri, Mar 27, 2015 at 5:42 PM, Ralph Schindler
wrote:
>
> About $php_errormsg , we have error_get_last().
About $http_response_headers, we have no replacement.
Why not get rid of both ?
>>>
>>> I agree. Magically appearing variables are bad design and if we can get
>>> rid of them, PHP 7 is the time.
>>>
>>> --
>>> Stas Malyshev
>>> smalys...@gmail.com
>>>
>>>
>> did we miss the opportunity?
>>
>
> Maybe so. Truthfully, I came to the conclusion I did not want to propose
> removing $http_response_header unless we had a reasonable replacement for
> the somewhat common workflow of file_get_contents('http://...'); then
> usage of $http_response_header.
>
> I think there might be room to have added http_get_last_header(), or
> something to that effect.
>
>
yeah, but we already mentioned/discussed this that the removal would
require introducing another way (eg. adding a method) for fetching the
headers.
I think that introducing this method can happen in a minor version(without
removing the $http_response_header variable), so I will create a pull
request and ask Julien about including it in 5.5 and upwards.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] $http_response_header
About $php_errormsg , we have error_get_last().
About $http_response_headers, we have no replacement.
Why not get rid of both ?
I agree. Magically appearing variables are bad design and if we can get
rid of them, PHP 7 is the time.
--
Stas Malyshev
smalys...@gmail.com
did we miss the opportunity?
Maybe so. Truthfully, I came to the conclusion I did not want to
propose removing $http_response_header unless we had a reasonable
replacement for the somewhat common workflow of
file_get_contents('http://...'); then usage of $http_response_header.
I think there might be room to have added http_get_last_header(), or
something to that effect.
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
On 26 March 2015 at 20:19, Dmitry Stogov wrote: Hi Dmitry, > however the patch looks a bit surprising to me. > We have special function to do this - zend_ctor_make_null() and some tricks > in the VM. > I made just a quick look over your patch but didn't find any references to > them. Surprising is usually not good, so let me see if I can explain. I touched the minimal amount of code needed to achieve the desired behaviour. For the intl classes, the exception is being thrown by telling the intl error handling code to use an exception, no matter what the intl.use_exceptions setting is, if the error was emitted during a constructor: https://github.com/Danack/php-src/blob/InternalClassClean/ext/intl/intl_error.c#L114 I didn't touch any of the code zend_ctor_make_null. I guess if it's only used in these special cases, and they are going away it could also be removed? But it sounds like that would be a job for someone who understands that bit. > Please don't commit it yet. That won't be difficult, I don't have commit rights, and don't particularly want them. > Nikita, could you also take a quick look. Nikita pointed out that I may have missed a couple of classes. I'll try to get those updated before you have a look. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Anonymous Classes
On Sat, Mar 14, 2015 at 6:33 AM, Nikita Popov wrote:
> On Fri, Mar 13, 2015 at 8:33 PM, Philip Sturgeon
> wrote:
>>
>> A two week discussion period has been held and there are no outstanding
>> issues.
>>
>> Serialization has been disabled, and generated names have been
>> explained better in the newest version of the RFC
>>
>> https://wiki.php.net/rfc/anonymous_classes
>>
>> The implementation needs to be updated with changes from master, but
>> that can be done at a later point and should not be used as a reason
>> to vote against.
>
>
> I'm not yet sure which way to vote on this RFC. I don't think there's
> anything principally wrong with anonymous classes, but the current RFC seems
> incomplete to me with regard to scoping (and as future changes in this area
> are not necessarily backwards-compatible, I'd rather solve this now than
> later). Lets start off with an example from the RFC:
>
> class Outside {
> protected $data;
>
> public function __construct($data) {
> $this->data = $data;
> }
>
> public function getArrayAccess() {
> return new class($this->data) extends Outside implements ArrayAccess
> {
> public function offsetGet($offset) { return
> $this->data[$offset]; }
> public function offsetSet($offset, $data) { return
> ($this->data[$offset] = $data); }
> public function offsetUnset($offset) {
> unset($this->data[$offset]); }
> public function offsetExists($offset) { return
> isset($this->data[$offset]); }
> };
> }
> }
>
> So ... WTF. It probably took me 10 minutes yesterday to finally understand
> the evil, evil things this code is doing and why it is doing them. This is
> what happens: The new anon class extends Outside (the wrapping class) and as
> such also inherits the parent constructor. The new class($this->data) bit
> passes $this->data to the constructor (the one inherited from Outside), as
> such $this->data will be assigned in the inner class as well. Because the
> anonymous class extended from Outside it is allowed to access the protected
> $data member.
>
> Why is this (imho very weird and unintuitive) approach used? Quoting from
> the RFC: "[E]xtending Outer [sic] allows the nested class implementing
> ArrayAccess permission to execute protected methods, declared in the Outer
> [sic] class, on the same $this→data".
>
> So the reason behind this is that anonymous classes as implemented by this
> RFC - and much unlike the anonymous class implementations you will find in
> other languages like Java or D - are considered to be totally unrelated to
> the wrapping class and have only "public" access to its scope. I don't think
> this is good. The solution ("extends Outside") to work around this that is
> presented in the RFC has a number of problems:
>
> * As PHP does not support multiple inheritance, extending Outside for scope
> access means no other class may be extended.
> * Extending the wrapping doesn't just give you access to restricted
> methods/properties of the wrapping class - it will also import everything
> into the inner class. This means that the anonymous class will have a bunch
> of additional methods and properties (potentially public ones) which have
> nothing to do with whatever the class is actually for.
> * The approach used to pass the data into the inner class by using the
> constructor of the wrapping class assumes that the constructor a) only
> performs simple assignments and b) accepts the entire state of the wrapping
> class as parameters - if this is not the case you will likely not be able to
> duplicate the state of the wrapping class in the inner anonymous class.
>
> To solve this without such hacks, two things are necessary:
>
> a) Assuming that the anonymous class somehow got hold of an instance of the
> wrapping class (i.e. it has an object $obj instanceof Outside), it should be
> able to access private and protected properties and methods of that object.
> This is consistent with the general rule that any code within a class body
> can access it's privates, unless explicitly rebound. For example, the
> following code should work:
>
> class Outside {
> private $private;
> public function getAnon() {
> return new class($this) {
> private $outside;
> public function __construct($outside) { $this->outside =
> $outside; }
> public function getPrivateOfOutside() { return
> $this->outside->private; }
> };
> }
> }
>
> b) Providing some easy way to access the instance of the wrapping class. The
> previous example passed it in as a constructor, which is somewhat verbose. A
> possible syntax for accessing the wrapping instance would be Outside::$this
> (to borrow Java syntax):
>
> class Outside {
> private $private;
> public function getAnon() {
> return new class {
> public function getPrivateOfOutside() { return
> Ou
Re: [PHP-DEV] Contributing to PHP Wiki
Sure. Custom groups need to be added to http://git.php.net/?p=web/wiki.git;a=blob;f=dokuwiki/conf/acl.auth.php;h=2b2c7711422cce99e018abb21b7a003b168cf06a;hb=HEAD and then you can be put into that group from the admin interface. I'd say however, if Avindra is interested in those docs, I'd bet he'd be interested in helping with the PHP7 migration chapters in the manual - so could just as well apply for vcs karma. -Hannes On Fri, Mar 27, 2015 at 12:12 AM, Ferenc Kovacs wrote: > > > On Fri, Mar 27, 2015 at 12:02 AM, Avindra Goolcharan > wrote: >> >> I want to help detail the PHP NG build documentation and fix build >> instructions. For example, enabling openssl should not be listed so far >> below in the ./configure command. >> >> Avindra. > > > Hi, > > I don't think that it matters in which line is the --with-openssl listed as > long as the configure command is otherwise correct. > You want to have access to the https://wiki.php.net/phpng page, right? > Hannes, should we grant edit karma for Avindra for that page? (similarly how > we did for internals:windows:* for the user wintendo) > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?
> De : Xinchen Hui [mailto:larue...@php.net] > > I don't think freeze should block bug fixes... Strictly speaking, not sure it can be considered as a bug. But, even if it is, what about bugfixes that cause BC breaks ? What is the rule ? Can we introduce BC breaks after feature freeze ? The question, IMO, is about the BC break, not whether this is a bug or not. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
On Wed, Feb 4, 2015 at 7:42 AM, Stanislav Malyshev wrote: > Hi! > > > About $php_errormsg , we have error_get_last(). > > About $http_response_headers, we have no replacement. > > > > Why not get rid of both ? > > I agree. Magically appearing variables are bad design and if we can get > rid of them, PHP 7 is the time. > > -- > Stas Malyshev > smalys...@gmail.com > did we miss the opportunity? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?
On 26 March 2015 at 22:40, Michael Morris wrote: > It's not a feature though - it's a bug. It's just one of those bugs that > the fixing of which may break something. > > TL;DR -1 for 7, and -1 in general. It's not really a bug, it works according to the defined behaviour, the issue is that some (I think most) people disagree with the correctness of the defined behaviour. The rules are quite clear that this cannot go into 7 at this point, and no exceptions can be made to this rule otherwise there may as well not be a rule at all. On the more personal level of my own opinion, I don't believe there is enough benefit in fixing this to do it at all. It will likely break a lot of codebases and slow down the adoption of whichever version introduces the "fix", and all it does is give people the ability to do something which some (and again I think most) people would agree is a horrible thing to do from a readability and maintainability perspective. It also suffers from a similar issue to the "API cleanup" idea that come up again and again - yes, some arguably poor decisions were made a long time ago which have left us with inconsistencies and that favourite phrase of proponents of these ideas, "cognitive overhead". Fixing the inconsistencies only serves to *add* cognitive overhead. People may not like how it works, but at least they know how it works - and anyone writing "run anywhere" code would still do what they do now, which in my experience is generally write the ternary chain with brackets to disambiguate it, then realise it looks horrible and change it to an elseif tree. On Thu, Mar 26, 2015 at 6:31 PM, Rowan Collins > wrote: > > > On 26 March 2015 20:54:12 GMT, Michael Morris > wrote: > > >Per PHPsadness... > > > > > >http://phpsadness.com/sad/30 > > > > > >Since 7 is allowed to have BC breaks this would be the time to fix > > >this. > > > > > >I'll let someone with more seniority actually write this up - but > > >please, > > >please fix this - it's a very long standing annoyance. > > > > I used to think this was a major nuisance, but recently thought about it > > and decided I've never once wanted to do this - the result is really ugly > > code whatever the associativity. > > > > What I've always been annoyed by is the *precedence* of the operator - > > having to add brackets to mix it with string concatenation, etc - which > it > > turns out to is the same in all sorts of languages. > > > > Regards, > > -- > > Rowan Collins > > [IMSoP] > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > >
Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?
On Fri, 2015-03-27 at 08:03 -0400, Michael Morris wrote: > While breaking backwards compatibility for its own sake is bad, avoiding it > to keep a bug in the system is worse in my opinion. And again, this is a > bug. If the way PHP associates could be used for something that would be > different, but it can't. I honestly doubt any code even exists that takes > advantage of the current behavior. What you are suggesting is not just "breaking BC" but "Changing behavior of code in a hard to debug way" as previously working code will suddenly start to do something else than expected probably without emitting any error. If you want this to run this requires a clear migration strategy for the billions of lines of code out there. Till this is provided please help focusing on things we can actually improve, like testing PHP 7 to make sure it will be a stable release. Thanks, johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?
Michael Morris wrote on 27/03/2015 12:03: Rowan, I seriously, seriously doubt anyone would write PHP 7 compliant code that only takes advantage of ternary associativity, a feature that is only occasionally useful. If they can't take the hint from the parse errors arising out of the spaceship op and all the other stuff being added, they're too dumb to be programming and need to find another line of work. I disagree. It would be perfectly easy for someone used to another language to be developing in a PHP 7 environment, use the idiom that's familiar to them (chained ternary operators as a kind of if-else expression), and see the results they're expecting, all without knowing it will work completely differently run in a PHP 5 environment. The rest of the code might well run fine on PHP 5, since other than scalar type hints, there's really not that much that's changed. Do you really think every PHP library is suddenly going to find loads of uses for the spaceship operator that are so pressing they'll bump their minimum version requirement to 7.0? Breaking loudly when moving between versions is always going to be better than behaving differently in a very hard to debug way. While breaking backwards compatibility for its own sake is bad, avoiding it to keep a bug in the system is worse in my opinion. And again, this is a bug. If the way PHP associates could be used for something that would be different, but it can't. I honestly doubt any code even exists that takes advantage of the current behavior. Yes, that's why I suggest non-associativity - very little current code will break, anyone trying to use the unavailable idiom will get instant feedback that it's not supported rather than unexpected behaviour. And then later, when 8.0 rolls around, we can look at adding in the correct associativity, knowing for sure that no PHP 7 deployments will be affected. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?
Rowan, I seriously, seriously doubt anyone would write PHP 7 compliant code that only takes advantage of ternary associativity, a feature that is only occasionally useful. If they can't take the hint from the parse errors arising out of the spaceship op and all the other stuff being added, they're too dumb to be programming and need to find another line of work. While breaking backwards compatibility for its own sake is bad, avoiding it to keep a bug in the system is worse in my opinion. And again, this is a bug. If the way PHP associates could be used for something that would be different, but it can't. I honestly doubt any code even exists that takes advantage of the current behavior. On Fri, Mar 27, 2015 at 4:57 AM, Rowan Collins wrote: > On 26 March 2015 22:40:56 GMT, Alain Williams wrote: > >On Thu, Mar 26, 2015 at 10:31:00PM +, Rowan Collins wrote: > > > >> What I've always been annoyed by is the *precedence* of the operator > >- having to add brackets to mix it with string concatenation, etc - > >which it turns out to is the same in all sorts of languages. > > > >It is the ''all sorts of languages'' that is key here. The point is > >that PHP > >associativity for ?: is different from other languages and it is that > >that > >confuses and leads to bugs. What is right/wrong is not as important as > >all > >others doing it the other way. > > This reply is competely out of context to the message you quote. Yes, I > know that the *associativity* of the operator is wrong. My contention is > that in practice, few people ever try to associate multiple instances of > the operator, so few bugs result from it not working. > > I contrasted this with *precedence*, particularly the precedence of an > expression mixing the ternary operator with string concatenation, which is > a much more common thing to do. But here, PHP is doing the "right" thing, > if measured by other languages doing the same. > > Personally, I'd be in favour of making the operator non-associative, thus > breaking obviously if people try it. Changing it now would result in people > using it in PHP 7, then running the code under PHP 5 and having obscure > bugs to fix. > > Regards, > -- > Rowan Collins > [IMSoP] > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] is_callable and function_exists with disable_functions
Hey:
On Fri, Mar 27, 2015 at 5:02 PM, Dmitry Stogov wrote:
> Unfortunately this id not so simple :(
>
> If we change class_exists() the following code will stop working
>
> if (!class_exists("SomeInternalClass")) {
> class SomeInternalClass {}
> }
> ?>
>
> On the other hand function_exists() already behaves differently. (so
> function_exists() and class_exists() are inconsistent) :(
> Changing is_callable() semantic may be dangerous as well.
> What is we disable strcmp() and then pass is as a callback to usort()?
>
too bad :<
>
> I wouldn't make any changes in hurry. this should be discussed and analysed
> carefully.
>
> However preventing conversion of disabled functions into opcodes and their
> optimization makes full sense.
>
okey, I will separate these part to a single fix
thanks
> Thanks. Dmitry.
>
>
>
> On Fri, Mar 27, 2015 at 9:41 AM, Xinchen Hui wrote:
>>
>> Hey:
>>
>>
>>
>> On Fri, Mar 27, 2015 at 1:14 PM, Yasuo Ohgaki wrote:
>> > Hi all,
>> >
>> > On Fri, Mar 27, 2015 at 11:57 AM, Xinchen Hui wrote:
>> >>
>> >> On Fri, Mar 27, 2015 at 3:06 AM, Kalle Sommer Nielsen
>> >> wrote:
>> >> > Forgot to CC list
>> >> >
>> >> >
>> >> > -- Forwarded message --
>> >> > From: Kalle Sommer Nielsen
>> >> > Date: 2015-03-26 20:06 GMT+01:00
>> >> > Subject: Re: [PHP-DEV] is_callable and function_exists with
>> >> > disable_functions
>> >> > To: Remi Collet
>> >> >
>> >> >
>> >> > 2015-03-26 16:32 GMT+01:00 Remi Collet :
>> >> >>> do you mind if I change the current behavior of is_callable , to
>> >> >>> return false on this case?
>> >> >>
>> >> >> Make sense
>> >> >>
>> >> >>> or, at least, change function_exists's behavior instead?
>> >> >>
>> >> >> Seems a bad idea.
>> >> >
>> >> > I agree with both points here, I think is_callable() should mimic
>> >> > function_exists() behavior, is this the same case for
>> >> > disable_classes?
>> >> >
>> >> yeah. but a little bit different
>> >>
>> >> class_exists return trun with disabled classes :<
>> >>
>> >> $ sapi/cli/php -d disable_classes=ArrayObject -r
>> >> "var_dump(class_exists('arrayobject')); new ArrayObject(); "
>> >> bool(true)
>> >> PHP Warning: ArrayObject() has been disabled for security reasons in
>> >> Command line code on line 1
>> >>
>> >> Warning: ArrayObject() has been disabled for security reasons in
>> >> Command line code on line 1
>> >
>> >
>> > Returning true for is_callable/class_exists even when it isn't usable
>> > does
>> > not make much sense. How about fix them all?
>>
>> I filed a bug here: https://bugs.php.net/bug.php?id=69315&thanks=4
>>
>> will make a fix soon
>>
>> thanks
>> >
>> > Regards,
>> >
>> > --
>> > Yasuo Ohgaki
>> > yohg...@ohgaki.net
>> >
>>
>>
>>
>> --
>> Xinchen Hui
>> @Laruence
>> http://www.laruence.com/
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_callable and function_exists with disable_functions
Unfortunately this id not so simple :(
If we change class_exists() the following code will stop working
On the other hand function_exists() already behaves differently. (so
function_exists() and class_exists() are inconsistent) :(
Changing is_callable() semantic may be dangerous as well.
What is we disable strcmp() and then pass is as a callback to usort()?
I wouldn't make any changes in hurry. this should be discussed and analysed
carefully.
However preventing conversion of disabled functions into opcodes and their
optimization makes full sense.
Thanks. Dmitry.
On Fri, Mar 27, 2015 at 9:41 AM, Xinchen Hui wrote:
> Hey:
>
>
>
> On Fri, Mar 27, 2015 at 1:14 PM, Yasuo Ohgaki wrote:
> > Hi all,
> >
> > On Fri, Mar 27, 2015 at 11:57 AM, Xinchen Hui wrote:
> >>
> >> On Fri, Mar 27, 2015 at 3:06 AM, Kalle Sommer Nielsen
> >> wrote:
> >> > Forgot to CC list
> >> >
> >> >
> >> > -- Forwarded message --
> >> > From: Kalle Sommer Nielsen
> >> > Date: 2015-03-26 20:06 GMT+01:00
> >> > Subject: Re: [PHP-DEV] is_callable and function_exists with
> >> > disable_functions
> >> > To: Remi Collet
> >> >
> >> >
> >> > 2015-03-26 16:32 GMT+01:00 Remi Collet :
> >> >>> do you mind if I change the current behavior of is_callable , to
> >> >>> return false on this case?
> >> >>
> >> >> Make sense
> >> >>
> >> >>> or, at least, change function_exists's behavior instead?
> >> >>
> >> >> Seems a bad idea.
> >> >
> >> > I agree with both points here, I think is_callable() should mimic
> >> > function_exists() behavior, is this the same case for disable_classes?
> >> >
> >> yeah. but a little bit different
> >>
> >> class_exists return trun with disabled classes :<
> >>
> >> $ sapi/cli/php -d disable_classes=ArrayObject -r
> >> "var_dump(class_exists('arrayobject')); new ArrayObject(); "
> >> bool(true)
> >> PHP Warning: ArrayObject() has been disabled for security reasons in
> >> Command line code on line 1
> >>
> >> Warning: ArrayObject() has been disabled for security reasons in
> >> Command line code on line 1
> >
> >
> > Returning true for is_callable/class_exists even when it isn't usable
> does
> > not make much sense. How about fix them all?
>
> I filed a bug here: https://bugs.php.net/bug.php?id=69315&thanks=4
>
> will make a fix soon
>
> thanks
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?
On 26 March 2015 22:40:56 GMT, Alain Williams wrote: >On Thu, Mar 26, 2015 at 10:31:00PM +, Rowan Collins wrote: > >> What I've always been annoyed by is the *precedence* of the operator >- having to add brackets to mix it with string concatenation, etc - >which it turns out to is the same in all sorts of languages. > >It is the ''all sorts of languages'' that is key here. The point is >that PHP >associativity for ?: is different from other languages and it is that >that >confuses and leads to bugs. What is right/wrong is not as important as >all >others doing it the other way. This reply is competely out of context to the message you quote. Yes, I know that the *associativity* of the operator is wrong. My contention is that in practice, few people ever try to associate multiple instances of the operator, so few bugs result from it not working. I contrasted this with *precedence*, particularly the precedence of an expression mixing the ternary operator with string concatenation, which is a much more common thing to do. But here, PHP is doing the "right" thing, if measured by other languages doing the same. Personally, I'd be in favour of making the operator non-associative, thus breaking obviously if people try it. Changing it now would result in people using it in PHP 7, then running the code under PHP 5 and having obscure bugs to fix. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Contributing to PHP Wiki
On Fri, Mar 27, 2015 at 12:02 AM, Avindra Goolcharan wrote: > I want to help detail the PHP NG build documentation and fix build > instructions. For example, enabling openssl should not be listed so far > below in the ./configure command. > > Avindra. > Hi, I don't think that it matters in which line is the --with-openssl listed as long as the configure command is otherwise correct. You want to have access to the https://wiki.php.net/phpng page, right? Hannes, should we grant edit karma for Avindra for that page? (similarly how we did for internals:windows:* for the user wintendo) -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] WIKI Account Authorization
On Thu, Mar 26, 2015 at 10:57 PM, G. M. Shaharia Azam < shaharia.a...@gmail.com> wrote: > === > *PHP Wiki Username:* shaharia > === > > *Hello,* > I am Shaharia, recently created PHP Wiki account with this email address. > My username was *'shaharia'. * > > As a PHP programmer since 7.5 years I always love to contribute to any > kinds of open source project. And PHP is my passion and using it since long > time and managing my app development with it. So personally I think it's my > responsibility to work to contribute PHP. I know this is a very big > community but let me start from here and from the beginning I am interested > to work with PHP Manual (English). There are lots of places where people > should get more use case or example to explain every single functions in > much easier way and I would love to contribute in that types of work at > first. > > Then one by one I will try to move forward to another part for contribution > as I will be familiar more with the community. So it would be great to get > authorized to get started. > > Waiting for reply from someone. > > *Regards,* > Shaharia > http://blog.shahariaazam.com > http://github.com/shahariaazam > Hi, you don't need a wiki account or any extra karma for contributing to the PHP Manual. the usual process is that you start working on the docs either via sending in svn diffs attached to bugs.php.net bugreports, or via using the online editor at https://edit.php.net/ then after a couple of good patches you can apply for a php.net account and get granted with doc karma, so you can push your patches for yourself instead of asking others. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
