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
ou 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
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
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
to get out of the bad function
without incurring per-function overhead... Not sure how to do it.
--
Stas Malyshev
smalys...@gmail.com
On Mar 11, 2015 7:01 PM, Stas Malyshev smalys...@gmail.com 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
.
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
Hi!
On Sun, Dec 28, 2014 at 10:54 PM, Kalle Sommer Nielsen ka...@php.net
wrote:
Commit:334b9718d578caa9f4c6d3c2f7e2fb9b65696dc3
Author:Kalle Sommer Nielsen ka...@php.net Mon, 29 Dec 2014
07:54:44 +0100
Parents: 3bd96e0735f45359bc3cff2981acbd34c60770c9
Branches: master
is
not correct.
--
Stas Malyshev
smalys...@gmail.com
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,
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
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
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
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
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
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
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.
--
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
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
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
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
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
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
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
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
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
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:
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:
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*
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
Hi!
What arguments do you have in favor of doing `return_type function
identifier ( parameter_list )`? 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
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
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
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
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
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.
--
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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,
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.
--
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
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=14114596961r=1w=2
and I think it makes sense to propose a formal RFC for it. Both the text
and the code in the patch
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
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
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
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
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:
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
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
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
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 (
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
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
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
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
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
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
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
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
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
Hi!
?php
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
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
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
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?
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
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
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:
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
Hi!
Commit:ee5b30fa197046973e813a80dd0b7c67827c0ae1
Author:Nikita Popov ni...@php.net Thu, 9 Oct 2014 13:58:14 +0200
Parents: 43f1c94ddace679cac008b674ef983199a951542
Branches: master
Link:
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
Hi!
yes, this was also suggested before, but that will be also a BC break
for those people already using the name of the new parent class
(https://github.com/search?l=phpq=EngineExceptiontype=Codeutf8=%E2%9C%93
for example).
This btw looks like a bigger issue (though many of them are
Hi!
1) I'm not sure if cacth(Exception $e) should catch engine and parser
exceptions. May be it's better to introduce interface or common parent
class Catchable and then make Exception, EngineException and
ParseException implement it. In case user would like to catch all the error
at once
1 - 100 of 1748 matches
Mail list logo
