Re: [RFC] [Vote] var_info

Many thanks for the feedback to both of you. :) On 7/8/2016 11:54 PM, Nikita Popov wrote: > You are doing a callability check for all arrays and strings. I wouldn't be > comfortable passing any data that potentially derives from external sources > (aka all data) to that function. E.g. this could trigger autoloading on > user-provided values -- while we have some protections in place to avoid > the most egregious security vulnerabilities, I wouldn't be comfortable with > that. There probably other funky things that can happen here. > That is true for anything that uses is_callable anywhere. On 7/8/2016 11:54 PM, Nikita Popov wrote: > Lastly, I'll just leave this list of type-related improvements I'd actually > like to see: > * Make is_object() return true for IncompleteClass. This is just > ridiculous. I care zero about the theoretical BC impact. I figured that this situation is on purpose and I don't think that it is ridiculous per se. It makes sense if is_object() is defined as only identifying valid objects (and incomplete class is by definition invalid). On 7/8/2016 11:54 PM, Nikita Popov wrote: > * Make gettype() return 'resource (unknown type)' instead of just > 'unknown type' for closed resources. This makes the output clear while > still leaving the closed resource distinction. Will prepare a PR. 8) On 7/8/2016 11:54 PM, Nikita Popov wrote: > * Normalize error message. IIRC currently our type error messages are > really weird, in that they use terms like "integer" which are not actually > valid type hints (or have different meaning). Fixing this doesn't even need > a proposal, just a PR. > Definitely on my roadmap anyways and yes stas, this requires going through a sh**load of existing tests but it is definitely worth it. I will most probably start work on all of this this weekend after being on vacation for the last days. -- Richard "Fleshgrinder" Fussenegger

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc