Hi!
Does anybody know who is responsible the snaps.php.net machine? It seems
to be serving 5.4 builds under then name of php-trunk and that confuses
people. Not only we don't have trunk as such since the move to git,
people expect the latest dev build there which is master and not 5.4.
--
Hi!
Perhaps get_class_fqn(string:ClassName) ?
Do you propose a function? Because I don't see how it can work as
function - namespace resolution is compile-time.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP
Hi!
I would expect $variable::class to work (like late static bindings).
What this would mean? ClassName::class has a clear meaning - ClassName
is a name of the class (possibly aliased) and class is the property of
this class, namely its full name. However I do not see how
$variable::class can
Hi!
* Here are the edge cases / implementation details that need a decision:
- $variable::class (should it even be supported?)
I don't see it doing anything useful.
- self, static, parent::class not in a class definition
- self, static, parent::class in a method signature
-
Hi!
In the current patch, this does not work and would need another run in
the parser.
Couldn't we just stuff it in ZEND_FETCH_CONSTANT? I'm not arguing for
it, I'm just saying *if* we wanted it...
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900
Hi!
The salt parameter, if provided, will be used in place of an
auto-generated salt. This is setting someone up for failure by
letting them put in something weak, you should be forced to get an
auto-generated salt. If this is for unit testing then it should be
explicitly stated.
This
Hi!
The benefit is that it can be tested properly and bugs discovered and
ironed out first.
This is not the sort of thing you want to get security bug reports the
day after its released in core.
If your ego is big enough you can guarantee you have tested this
thoroughly and want it to
Hi!
That's more about internals APIs, which is not what is meant in the
release RFCs for x.y+1 releases.
The idea though wasn't about internals APIs. The idea was that for users
it's better to have platform that they can expect to work with their
code 10 years after than to have a platform
Hi!
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a BCB (Backward Compatibility Break) as well as what only
minor BC breaks could mean.
Stas' recent topic on internals On BC and interfaces may serve as a
reflection basis.
As our release process told us that
Hi!
Change in phpinfo related stuff are minor. Adding a notice or warning
is minor or irrelevant. Changing return values (like suddenly
I'm not sure I agree about warning/notice. Depends if it's a clear bug -
either in our code (like, opening non-existing file produces warning but
opening it
Hi!
This is concerning me a bit. Does this mean that PHP 5.5 will be
branched off PHP 5.4 and we will then backport features from master?
If so, this would seem like a Very Bad Idea to me, from a purely
technical point of view. Unless I'm much mistaken this would have to
I think also it's
Hi!
We do not have this clue in master and there are for sure non
acceptable BC breaks in master. They won't be in 5.5. I'd said before,
Why don't we have a clue? We definitely do have a clue, we have git logs
and we know what went into master - it is not that old. Could you list
the
Hi!
Back on the namespace topic. I won't judge on anything, but i know
namespaces from c++. I understand that PHP isn't a compiled language
and quite frankly that doesn't matter at all. What does matter is that
PHP uses the name: namespace which C++ obviously had earlier.
Here is something
Hi!
The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks,
Hi!
Nikita is doing an amazing job with PHP_Parser, which is such a
third-party tool. However, it will always lag behind the canonical
parser. And it will (probably) never match 100% the behavior of the
canonical parser.
Wait, so the arguments that it will be amazingly easy to
Hi!
Well, apart from perhaps leaving them with a simpler language that
doesn't have the inconsistencies and corner cases that currently exist
(and documented ad nauseum) not because of any design decision but
because the parser is written that way.
If you think writing new parser gets rid
Hi!
Yes, PHP namespaces are completely different from what you'd be used
to in C++. In all honesty namespaces were never well designed in PHP
and were implemented in a haphazard way, which is why I generally
don't bother using them.
I just love how people assume if something does not fit
Hi!
How about adding ability to import the entire namespace?
This option was explicitly excluded because this defeats the whole idea
of having namespaces - i.e. having names to live in different spaces -
by explicitly bringing unknown set of names into global space. If you
allow global import,
Hi!
In C++ when you type:
using std;
Then you can use all methods/classes/whatever is defined in std
without typing std.
so: std::cout becomes just cout.
PHP namespaces do not work like that. In PHP, namespace is a permanent
part of the class/function name. All namespace translations are
Hi!
That's true, but we do got the ability to import only one class from
given namespace and classes aliasing so we can, for example, do
something like:
When you import one name, you see this name in import statement. It's
explicit. Global imports are not.
I really hate to rehash discussion
Hi!
I wasn't assuming. I was outright making a factual statement. I never
made any implications of the intellectual levels of those implementing
the spec. I understand the RFC full well and know why the design is
the way it is. I was answering the ops question. Please read what I
said before
Hi!
The complexity of the current grammar is working against development.
I'm not sure that undertaking a task of rewriting whole grammar, with
all disruptions etc. that this is going to cause, will speed up
development a lot. But if you want to try it and show how easy it would
be with your
Hi!
To date, I've been basing work, which exposes syntactic structure, on
phc's maketea grammar (Phalanger's is more up to date, but also more
complicated what with its provenance and the Linq and generics and all),
but it's reverse-engineered and certainly wrong (oh, that reminds
Hi!
The problem is that the only formal definition of the language _is_ the
parser - there's no grammar outside
zend_language_scanner.l/zend_langauge_parser.y.
I'm not sure - why exactly is it a problem here? I can understand how
having such document might be useful and interesting (not
Hi!
Given many discussions on the list about changing stuff in PHP, I'd like
to bring everybody's attention to comment by Linus Torvalds in this
topic: https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk
It talks about Linux kernel and discussion has next to nothing to do
with PHP,
Hi!
I keep being told that there is nothing wrong with E_STRICT, and again
someone
has said that it does NOT cause crashes. I beg to differ here - IT DOES!
If you have a scenario where E_STRICT causes PHP to crash - please
submit a bug to bugs.php.net. If this is your application that is
Hi!
The terminology negative indexing seems to imply that the feature
should work with arrays. To restrict it to just strings might involve
creating a term one would only associate with strings.
I do not see any way to change behavior of $array[-1] that would make
sense. So either only
Hi!
They are seen and promoted as core features. Whether we like that idea
or not is not really relevant. We messed that up by making most of the
Standard PHP Library an extension for only political and licensing
reasons.
I think you using core here in two difference meanings, and the
Hi!
I've replied here:
http://www.mail-archive.com/internals@lists.php.net/msg60706.html
I have a feeling you're concocting a very far-reaching scenarios and
making a lot of unbased assumptions there to arrive to pre-defined
conclusions. Any programming error can cost a business money, and
Hi!
indicating such mental model is widespread and (2) given that the
exceptions you claim to be surprising don't happen but for a programming
error (i.e. they're not exceptions that need to be caught).
Following this logic, we'd have to convert all E_NOTICE and E_STRICT to
fatal errors or
Hi!
And no BC in 5.5 as well. Which will cause us some issue for 5.5 as
master actually has BC breaks as far as I remember.
We accept binary API changes in 5.5, but only very slight PHP-level API
changes (such as removal of functions like logo GUIDs).
Another important point - any such change
Hi!
First, E_NOTICE exists to permit a compromise between people like Zeev
that think its introduction was an error and that one should be able to
refer to undefined variables and people who prefer a stricter model. For
the programmers that follow this stricter model, an E_NOTICE ends ups
Hi!
to be gained vs. the additional risk. And there is little to no benefit
in a model where rewinding a closed iterator is allowed, so the
threshold for acceptable risk is very low. This is not a difficult case
at all, IMHO.
We are discussing whether it should lead to the fatal error. I
Hi!
Stanislav I though that the discussion on adding this type of functionality
to
strings was already a done deal? Despite the obvious problems it introduces.
I'm not sure what you mean by done deal. There was this RFC:
https://wiki.php.net/rfc/strncmpnegativelen
but that wasn't
Hi!
Hi, Stas. This has been on my mind as well. I've considered that maybe
an INI wide setting would be beneficial here. In fact, there are many
places within applications I've worked on where the format for many
DateTime objects are the same. What are your thoughts on that?
I think yet
Hi!
SPL is not a part of basic language syntax. There are no SPL keywords
and no SPL classes used unless you explicitly instantiate those classes.
So SPL is different.
End users do not see nor buy the difference between what is Zend/ or
what is ext/spl (or other) and can't be disabled,
Hi!
* If users do not expect exceptions in the core, they are mistaken. There
are indeed exceptions in the core. See ZEND_FE_RESET and
zend_interfaces.c. Of course, no evidence has been provided one way or
another.
This is not right either, but that was done in 2005. We're now in 2012
Hi!
More importantly, there is no other satisfactory solution (except a fatal
error). foreach has no return value, so it has no other way to signal a
failure. If we used a notice or a warning here what would happen is that
code that used generators with an invalid state would, except
Hi!
The idea was originally proposed by Marc Easen who created a patch
and asked for help with putting together an RFC. I have yet to see a
formal proposal but on the list Easen modified his idea so that it
should apply to strings alone. With that in mind, would it really
cause problems to
Hi!
illegal state was written on the RFC when voting opened, and the RFC was
accepted almost unanimously. As the proposal was accepted as such, I saw
no valid reason not to merge. In fact, changing the proposal after it was
voted on would be much more objectionable.
I definitely did
Hi!
I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.
This must indicate there's actually no default pattern that is default
Hi!
I am noticing that the new way we're doing releases in 5.4 is not
completely clear to everybody, so I would like to reiterate some points.
1. 5.4 releases are done from release branch (PHP-5.4.X, e.g. current
one is PHP-5.4.7). This branch is created 2 weeks before the release,
usually on
Hi!
The spl ext has exceptions all around, so if would count spl as core, we
have exceptions in the core already, so it would be ok to add more
exceptions where appropriate.
SPL is not a part of basic language syntax. There are no SPL keywords
and no SPL classes used unless you explicitly
Hi!
Thanks, this is now fixed. It'll throw an exception now, saying that
you can't traverse an already closed generator.
Nothing in the core throws an exception, why would this?!
I'd rather have it skip foreach, maybe producing a warning/notice. It'd
otherwise also be only place generators
Hi!
While this has no immediate impact for average PHP users, it
basically kills the possibility for an extension like Suhosin to
catch all function starts. This should also be a problem for your
DTRACE support. And IIRC Xdebug was hooking this point (at least in
the past), too.
My
Hi!
That's where it gets ugly, in my experience; there are lots of
mediocre C++ developers (and legions of even expert
PHP/JavaScript/Python/Ruby/etc. devs) who couldn't so much as use a
pointer without insert favorite C++ pointer wrapper here around to
check their NULLs and do their deletes
Hi!
What's the status of session adoption patch?
I've created patches for all 3 versions and I think Stats
is going to merge it to master and PHP 5.4.
As far as I remember there were some things that needed to be
refactored/changed and I didn't see the updates since then, but if you
could
Hi!
I know session ID collision will not happen most likely, but
there are few people who worries collision. We can check
session ID collision when it is generated.
You mean two randomly generated session IDs colliding? I think the
probability of it is pretty low. I mean it'd take PHP's
Hi!
foreach supports list syntax: 11 for yes, 4 for no. accepted.
foreach supports list with silent token: 2 for yes, 10 for no. denied.
And here's again the problem with this voting setup. With all these long
discussions about people not getting votes we have 15 people that
Hi!
I got a PHP Wiki account but couldn't vote. Are you sure the Wiki
accounts got the permissions to vote?
Hm... Not sure, maybe somebody has to enable it?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime
Hi!
Only people with a VCS account (or voting group) can vote.
OK, I stand corrected then, but participation rate is still awfully low.
We can't talk about consensus when everything is decided on one vote.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
And this is how democracy works, Stas. If voters don't bother to turn
up, too bad.
Putting aside the fact that democracy has very little to do with what
we're trying to do here (we're not government, we're opensource
project), that's how democracy *doesn't work*. As you noticed, it is
too
Hi!
In PHP 6 we tried to introduce separate input, script and output
encoding settings. Currently in 5.4 we don't have that, but we have
those 3 separately for mbstring and for iconv:
iconv.input_encoding
iconv.internal_encoding
iconv.output_encoding
mbstring.http_input
Hi!
I think the generators RFC has been discussed thoroughly enough by
now, so I opened the vote:
https://wiki.php.net/rfc/generators#vote
I think it's fine but I'd still like to put forward a proposal to
reconsider the requirement for parentheses in syntax like this:
$data = (yield
Hi!
I honestly don't see what the problem is. If the sample is indeed random,
there's no bias as to what the voters as whole would do, tough for close
votes or for votes where very few people vote the result could differ.
The problem is that this is not consensus, this is apathy and
Hi!
Thank you for the links!
master
https://gist.github.com/1379668
5.4
https://gist.github.com/2224196
5.3
https://gist.github.com/2224360
I think patch of this magnitude is not a good idea for 5.3. As for the
rest, it'd be much easier to track and comment on if you could create a
Hi!
It seems I've already added collision detection when I
last updated :)
It tries to generate new session ID a few times and
if it fails, it does not initialize session.
It'd be nice if we could keep it separate. Could you create a pull that
includes only the strict session
Hi!
To point that out: I _don't_ want to change the behaviour, which means
| $foo['xy'] ?:= 'bar';
would trigger a notice like
| $foo['xy'] = $foo['xy'] ?: 'bar';
Then I personally don't see much point in it. Saving a couple of
keystrokes IMHO is not really worth it.
--
Stanislav
Hi!
Hi everybody,
I would like to merge https://github.com/php/php-src/pull/120 in HEAD, 5_4
and 5_3 to fix splitting of soft line breaks. Any concerns?
Yes. For 5.3, it does not look like a critical bug, so it shouldn't be
there. Also, the tests are still not there - so they should be
Hi!
generator function f() {
echo Hello World;
}
even more interesting,
$a = generator function() {
echo Hello World;
}
or even:
function foo() {
return generator function() {
echo Hello World;
}
}
$a = foo();
--
Stanislav Malyshev, Software
Hi!
What would *actually* make sense here are return value typehints. E.g.
one could have something like `public Iterator getIterator() { ... }`.
And again we're back to inventing syntax to do what documentation should
be doing.
--
Stanislav Malyshev, Software Architect
SugarCRM:
Hi!
I am against this. This is even more magic in PHP. Is it really that
difficult to have to mark the function with a different keyword, such as
generator:
You have a point here, but public static final generator function
foo() sounds a bit long-winded to me... Also, we'd have then to
Hi!
For PHP we would need to have some similar behavior. PHP's current
exception model is incompatible with GeneratorExitException (because
PHP does not have BaseExceptions). So what I'd probably do instead is
monkeypatch a ZEND_RETURN opcode at the current execution position and
Patching
Hi!
My proposal is simple: behave as an inline type hint. The same type hints
you have in arguments lists, but inline. The use case is I want to make
sure this value is of this type and a side benefit is the IDE can know the
variable is of this type too (for autocompletion purposes).
Hi!
And assignment is a kinda common operation. So I hope you can see what's
wrong with it now.
No I do not. Not every imaginable use case should have dedicated
language construct for it - sometimes it is OK to type 2 lines of code.
Sometimes even 3. This case is well served by existing
Hi!
Let me ask you - do you think the existing PHP typehints are pointless too?
Do you feel they don't give you enough flexibility? Do you feel they
reinvented a language construct for the purpose of saving the typing of one
if clause (per argument) (per method) (per class)?
They are not
Hi!
All right, your method accepts an array of objects, instances of Foo. How do
you enforce this contract?
You are trying to re-invent generics/parametrized types and bolt it onto
PHP. I still don't think it is a good idea - PHP is not a statically
typed language. Just check you array
Hi!
How come there is no straight-foward obvious way to simply remove a given
value from an array?
The same reason there's no simple way to undefine variable whose value
is 42 without knowing the variable name. Array is a container indexed by
keys, not values. So if you've got just a value,
Hi!
2. Move instanceof to a handler from the current standalone function. Then
each (pecl level) class could choose its own implementation if it is
needed. The function could still exist for BC reasons, but would proxy to
the handler method if it existed... Then, the wrapped class (the
Hi!
I agree with you. The one case where this syntax may be very useful is if
we want to implement class casting. So introduce a pair of magic methods
I do not think we want to implement class casting. I'm not sure how
class casting even makes sense - if the object is of one class, how can
you
Hi!
That said, rewind() should behave consistently. I don't feel it makes
sense to have rewind() succeed at one point, and fail at another. It
would only cause confusion when not familiar with the behavior. Either
allow it, or don't. Not both.
It does, since foreach uses rewind. So first
Hi!
Simply because your object responds to all the same methods of, for
example, the FooInterface, does not make it a FooInterface subtype. It
just means that in the duck typing sense of the phrase, it can act
like a FooInterface for people that are not necessarily concerned that
it's
Hi!
Have you stopped for a moment to think this opinion through? Look at two
Of course not. Why would I bother thinking? It is always safe to assume
nobody thinks before writing anything to the list.
typical patterns of error handling. The examples below are generalized from
my file cache
Hi!
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires parentheses around? All these complex
Hi!
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on every kind of
exception possible.
This type of thing
Hi!
but sometimes you want to be more precise. With exceptions, we have an
elegant way to manage all failures as a whole, or to differenciate each
reason.
You do not, unless you have 20 exception types and catch them all
separately. Which nobody would ever do for one simple reason - what if
Hi!
Personally, I'm used to what other languages like Python do, and I think
it makes more sense. Exceptions mean you can try/catch the things your
code needs to be prepared for (non-existence, maybe), but other things
No, they mean you need to *always* try/catch since you have to means to
Hi!
circumstance. If it's not, you should be checking for existence first
(via file_exists() or is_readable(), etc)...
This is exactly how we got into this mess with $x =
isset($a['x'])?$a['x']:null;
We're trying to get out of this mess and you're proposing to build
another mess just like
Hi!
Basically Etienne mentioned that the original issue was a good example why
would we reconsider throwing exceptions from the core, which is currently
discouraged.[2]
Stan replied with the idea of turning the current error handling mechanism
in php into using Exceptions for everything, but
Hi!
Many developers use shared hosting as PHP env which not allows them to
install new extensions in PHP.
You do realize they do it not because they are evil people thriving on
suffering of their clients, but because they need controlled environment
they can maintain? If you need environment
Hi!
I'm looking at a segfault in the SPL caused by the blind creation of a
class, which seems to only fail when the class is disabled. I'm
wondering in how many other places this could occur.
This seems to be pretty bad. I'd say creation of an instance of disabled
class should be a fatal
is broken.
If no critical issues is found in this RC, the final version will be
released in two weeks.
Regards,
Stas Malyshev and David Soria Parra
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
https://wiki.php.net/rfc/incompat_ctx
An RFC for deprecating and removing $this from incompatible context.
IMO makes sense. Nulling-out $this makes most of the sane code (like
de-facto static functions not marked as static) work, and breaking
insane code in 5.5 in acceptable.
--
Hi!
Can you try using a stock version of libxml or using the latest version?
I met some issues in the past on Centos because of bad patches applied
to libxml.
I've built both 2.7.8 and 2.8.0 from source - same result. amp; is
ignored when parsing with PHP xml extension.
--
Stanislav
Hi!
The current raft of PHP problems arise from the fact that we actually put a
lot
of emphasis on not breaking backward compatibility seems just to be lip
service
to the real problem ... Taking stuff out in PHP5.4 would be fine if people
are
So what would happen if it would be real
Hi!
PEAR and PECL that work with PHP5.4 out of the box?
At least the core of PEAR that does not throw strict warnings from a stock
install of PHP5.4 as E_STRICT is on.
For PEAR is think it is a wrong list, as for PECL most extensions are
maintained by their maintainers, and internals
Hi!
Only with short tags on ... 5.4 has detached it from that, but 5.3 still
switches it off by default, and convincing ISP to switch short tags on again
is
a lost cause :( Fixing it in PHP5.3 was rejected :(
Errm... So you are complaining we're not going back in time now and make
Hi!
I've looked a bit into other languages (Ruby, Python, Go) and
all of them do not generate an error when an undefined dict/hash/map key is
accessed.
Python would definitely throw an exception:
a = {}
a
{}
print a['a']
Traceback (most recent call last):
File stdin, line 1, in module
Hi!
I was running PHP tests on my freshly installed CentOS instance and I
noticed that two XML tests were failing: ext/xml/tests/bug35447.phpt and
ext/xml/tests/xml011.phpt. Looks like for some reason XML parser when
parsing something like this: This amp; that - produces empty string
instead of
Hi!
but on the hand, we may also consider this as a bug, behavior not
act like the doc said :)
If the library we are wrapping behaves in certain way, our function
should behave in the same way. If docs say otherwise, docs should be fixed.
--
Stanislav Malyshev, Software Architect
Hi!
Secondly, I noticed that Python's PEPs are numbered, unlike PHP's
RFCs. Whilst they aren't quite the same thing, I wonder if this would
be useful, particularly since it provides a simple and unambiguous way
to refer to one, e.g. RFC 123 instead of RFC on how to write an RFC.
Why have
Hi!
The current idea would be to skip every second release (unless security
issues demand something else) both in release date as well as version
number. So for instance 5.4.6 will be released sometime next month
alone. A month later there will be 5.3.17 and 5.4.7.
I think it makes sense.
Hi!
Speaking of parse errors, I'm having trouble parsing this line. I *think*
you're saying that generators are just complex things and that's the way it
should be. I... guess I agree, though I have a lower opinion on the
complexity of generators. Seem like a fairly straightforward concept
Hi!
The implementation is outlined in the RFC-stub here:
https://wiki.php.net/rfc/generators
Before going any further I'd like to get some comments about what you
think of adding generator support to PHP.
Some notes on the RFC:
1. I think we should support rewind() by just creating a new
Hi!
For finally see https://bugs.php.net/bug.php?id=32100
it seems that the core devs don't like the idea, but that feature request
seems to have a lot of supporters, and comes up frequently.
I haven't seen it come with a pull req though ;) BTW, look at how
finally is implemented in Java,
Hi!
In particular this means that...
... if a die() is execute somewhere in the try clause (or a called
function) the finally clause must still be run.
... if a parse error or other fatal error occurs in the try clause (or
called function) the finally clause must still be run.
... if the
Hi!
PHP risks losing some of its uniqueness to fixing things, unfortunately.
But losing bad features and moving forward is good, right?
I'm not sure what you are talking about here, but I'm sure I can not
accept argument Python does it this way, so we must do it exactly the
same way even if
On 7/24/12 4:20 AM, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
I'm not seeing tests for the following situations:
1. Return from catch block.
2. Another try/catch block inside finally block.
3.
Hi!
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2,
ForthSpace\Class3 as Alias3;
I'm not sure it's necessary. If you import a real lot of the classes
from the same namespace, just import the parent namespace. And this
syntax makes less clear what is the true name of
Hi!
Still my point stands. If fatal errors and die are not handled by
finally the feature does not make sense to me. You simply can't do any
kind of remotely important cleanup in there (like releasing locks
etc).
Well, I'm sorry you don't understand it but I think you are too focused
on
701 - 800 of 1748 matches
Mail list logo
