Hi!
Within get: $this-Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this-Hours = 1 can write to the underlying property but a
read of the property would go through the getter.
Are the accesses also
Hi!
I see that we do not have a lot of changes in 5.4 since last release. So
I wonder if it may make sense to reduce release frequency now that we
got less bugfixes coming in, say from monthly to 1.5 or 2 months between
release. What do you think?
Just to be clear, I have no problem (excepting
Hi!
I'm thinking maybe the best solution is to have a new class - say,
CurlFile - and do this:
$file = new CurlFile(myface.png, image/png);
curl_setopt($ch, CURLOPT_POSTFIELDS, array(foo = bar, picture =
$file);
This would allow us to do two things:
1. Protect ourselves from injection since you
Hi!
I know this topic was opened a long time ago, but I would like to get
it resolved before 5.5 got released.
I agree, it looks like a place where we could use improvement, current
API is kind of dangerous.
A last solution would be to something similar to libcurl curl_formadd
(this one
Hi!
Max-Age would simply be added to all Set-Cookie headers, after the
Expires attribute. I thought that was obvious, but I'll make sure to
add a few examples to make it clearer.
I think it makes sense, only note is that it makes no sense to set
Max-Age to any negative number, especially
Hi!
I've been hearing this argument from time to time and I don't understand
it; aren't exceptions created with the sole purpose of (error) flow control?
No. Exceptions are meant for something that should never happen. I.e.,
if your application reads its config files and they are not there, or
Hi!
Sebastian had responded off-list that he'd rather have DateTime inherit
from DateTimeImmutable, instead of the current variant where
DateTimeImmutable inherits DateTime. While this OO-design principle wise
makes perfect sense, practically it is not as handy. I've played with a
Hi!
Oh? Did I understand you correctly? If you can code PHP that crashes
PHP, it's that codes fault not PHP's fault? I've always thought PHP
to be high level programming language where PHP handles things for
you and you can't code anything that crashes it like that with
bus error?
There
Hi!
?php
if ($argv[1] 0) {
while ($argv[1]--) file_put_contents('test.tpl', ?php
#.str_repeat('A', mt_rand(4000, 5000)). ?\n, LOCK_EX);
} else {
$p2 = popen(sapi/cli/php -n test3.php 100, r);
while (1) include 'test.tpl';
}
?
Yes, I can now reproduce this on my machine too.
Hi!
Is include supposed to take a LOCK_EX somehow? I can neither see that in php-
src (5.4.9) nor APC-trunk, doing a cursory grepping.
I'm not sure how any lock would help, since locks are optional, meaning
you still can do the same thing without the locks.
The prudent approach, which should
Hi!
I did come up with a problem in my server crashing with SIGBUS.
After long testing/tracing found:
https://bugs.php.net/bug.php?id=52752
Just tried to reproduce it on Centos 6.2 install (without APC), works
just fine for me. I suspect it's some APC issue, does it reproduce for
you
Hi!
I'm going to take a deep look into trait implementation and provide a
better solution for 5.5.
The current implementation is really wired and makes a lot of troubles for
maintenance and each new fix, makes new troubles :(
I'm really sorry, I didn't pay enough attention to treats before
Hi!
Steering things back to the original topic, my objections to collaboration
with FIG seem to be pretty much centered around their edictal approach to
userland style guidelines and how our involvement could be construed as an
endorsement of said style. If they would agree to make some
Hi!
Basically the method allows you to do delegate error handling to the
coroutine, rather than doing it yourself (as you are not always able to do
it). It is particularly useful in more complicated settings, e.g. if you
are doing task scheduling through coroutines. For a small sample of how
Hi!
Al the methods will *still* return the modified DateTime object - it's
just that the one that you *call* f.e. -modify() on won't change
anymore.
Doesn't it mean you can just call clone() on it in modifier methods
before doing anything else?
--
Stanislav Malyshev, Software Architect
Hi!
As Nikita says, from an ORM perspective, an object is always immutable
(at least with current implementations I know of), and that's because
they can simply use the object hashes to identify two different objects.
Why for ORM Date is even an object? In most databases, date is a basic
Hi!
strings/timestamps (it could be database's representation of date like
2010-10-23 or just integer with timestamp) or it could be objects of
DateTime. More efficient and logical way would be objects, but that way
you must aware users that they shouldn't modify values of DateTime
Hi!
@Stas a DateTime object is the perfect representation of what in DB
world has dozens of different representations. The reasoning behind it
is exactly the same as having a DateTime object vs having a date+time
string.
You are confusing internal PHP representation with object identity vs.
Hi!
what do you think about improving the modification functionality of the
DateTime class. I always get a cold shiver, when I write something like this:
?php
$date = new DateTime()
$date-modify(‘+15 day’);
In my opinion it would be nicer if one could write:
$date-modify(15,
Hi!
As long as we know, it's not so good - date is immutable by nature. I
don't want to write here why it's so, I will just throw this link:
http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html
Date is immutable, but there's no reason why date object should be able
to
Hi!
As it stands now, calling a method can mean two different things:
calling the method directly, or handling the method invocation within
__call(). Checking for a method first, a closure instance next, and then
falling through to __call() seems like it would have been a reasonable
Hi!
Has anyone else wanted this functionality? Has anyone else thought of ideas
of addressing this (or come to the conclusion it really isn't safely
addressable without causing disproportionate amounts of grief?)
Yes, there were people that wanted this functionality, but since having
the same
Hi!
Okay. But does the patch look okay? Is it sufficient? How can I force a
rebuild of all files generated through re2c to remove the date from the
files? To which branches should the patch be applied? Thanks!
I think 5.5, since we're not touching 5.4 that much anymore, especially
not in
Hi!
Any objections to applying the attached patch? This would suppress date
output in the generated output so that (hopefully) files generated by
re2c are not changed during the build just because of the date.
I think it is a great idea. If we ever need a date for checked in files,
we have
Hi!
It seems that NEW in PHP 5.4 is not ready for 5.4.10
I've fixed that.
I need to add 2 missing entries (Imap + Sqlite3)
How should I proceed ?
In general, if release branch already created, all bugs should go to the
next release. So, if the release branch (such as 5.4.9) is there but
The PHP development team announces the immediate availability of PHP
5.4.9 and PHP 5.3.19. These releases fix about 15 bugs. All users of PHP
are encouraged to upgrade to PHP 5.4.9, or at least 5.3.19.
The full list of changes are recorded in the ChangeLog on
http://www.php.net/ChangeLog-5.php
Hi!
It's the inconsistency that bothers me. I think a rule like Never remove
a ~function without it first emitting E_DEPRECATED can be followed 100%
of the time, and don't see this as a bureaucratic rule but instead think
this consistency would make PHP better.
I guess that's where we
Hi!
Actually, I'm going to retract my statement, and here's why:
http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.php
I think breaking this code is an advantage :) That's definitely not how
php_logo_guid should be used and using it as a secure salt makes
Hi!
Proposal: I propose we revert this change. Future consideration might
I see no reason to revert the change and keep dragging around the GUIDs.
Data URLs are much better and cleaner solution, and only reasons not to
do it are purely bureaucratic, for which I don't care much. We could
keep
Hi!
The issue I have with this is just that we don't seem to be making
much of an effort to stick to the promises we've made around BC when
We make a lot of effort to do this. But it does not mean we should be
blindly and stupidly following the rigid rules even when it makes zero
sense in
Hi!
Hi internals!
It happens quite often that you need to extract an integer from a zval and
you also want it to work for integers in strings, etc. In order to do so
you currently have to cast the zval to integer. This is always rather
complicated because you often don't want to actually
Hi!
1) what's the difference between zend_object and zend_object_value? what is
each for? Because i'm confused..
2) What are zend_object_store_bucket; and zend_object_store used for?
It may be easier to look at it this way:
For the engine, the object is an abstraction, which has an ID and a
Hi!
Again, though, this is a long way down the road: today's discussion is
purely about deprecation.
So these people using mysql-based code will have for years to live with
applications generating thousands of warnings and not be able to do a
thing about it? How is it good for them?
--
Hi!
Fatal error: Call to private method a::__setb() from context ''...
Or...
Fatal error: Cannot set private property a::$b.
Which makes more sense to the most people?
Either of these is fine. I'm not talking about that though. You said:
stack traces, reflection, etc would hide the
Hi!
Been AWOL for a while and getting back to this, doesn't seem like any
resolution has occurred, just the conversation has died down.
I would propose that:
1) Internal accessor methods that are defined are callable directly.
2) Said methods are not reflected or revealed by the engine
Hi!
But with a strong warning that on a later version of PHP things WILL stop
working altogether? More often now E_DEPRECATED is already switched off
simply
Why again we must breaking people's working code?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
2. Mention how to turn off E_DEPRECATED warnings in the RFC?
Done and done. I've added a (short) workarounds section towards the
bottom, which can be moved up later if the RFC is accepted.
Please note currently PHP has no mechanism of turning off any warnings
or errors. The best you
Hi!
Doc bug? Or code bug? I'm inclined to call it a code bug, but wanted
others' thoughts.
I would say comparing object to a number makes little sense, so no
reason to define any specific result there. It may be true, false or
bologna sandwich.
The docs say what happens when the first
Hi!
Well, LSP is typically not applied to program semantics, since this is
not a generally decidable problem. The only post-conditions that LSP
normally enforces is type based, i.e. the covariance of the return
type.
Err, I'm not sure where you are taking this from, but LSP is certainly
not
Hi!
http://wiki.php.net/rfc/uconverter
Discuss!
Looks nice. Some points:
1. transcode() accepts options, but there's no comparable way to set
options to the object. I think these APIs should be synchronized.
Imagine code keeping options in array/config object - it's be really
annoying to
Hi!
Stas, you seem to have missed the point behind my mail. This wasn't
about what the exact details of the implementation will be, the
message was that the semantics of a dedicated accessors syntax and the
semantics of a magic implementation can not match.
I see your point now, thanks, but
Hi!
I'm not sure why you are expecting this, and also this is probably an
LSP violation, since such override would change semantics of the value
that A clients expect. It may be possible to implement, technically, but
I'm not sure it's the right thing to do.
Why would it be not expected
Hi!
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this-b = $x; }
}
}
$o = new a();
if(!isset($o-b)) {
/* delete files */
}
echo (int)isset($o-b); /* This should return false and not emit any
sort of warning/notice? */
Hi!
Is there another class of error that would make more sense? Don't most
people turn off E_NOTICE errors? Perhaps emit an E_STRICT?
I always run with E_NOTICE in development, that's kind of what E_NOTICE
is for :) I don't think isset() should produce any warnings/notices -
this is how it
Hi!
If I got it right now, what Stas wants is that we introduce __getFoo
and __setFoo methods that will be called whenever an undefined -foo
property is accessed and that the normal property accessors syntax
is made nothing more than a fancy notation for this.
Yes, pretty much, though
Hi!
1) Currently __get() is only checked/invoked if there is not a property
already defined; ie properties shadow __get() (no performance penalty)
Yes, that's kind of the point of it - extending __get.
2) It would dramatically reduce performance because every property
access would have to
Hi!
Stas, you should probably do some research before posting such non-sense:
Which part is non-sense? I've brought you examples of Python and Ruby
not doing exactly what you claim all languages are doing. By your
definition, they don't have accessors - as you define accessors as
hidden methods
Hi!
Sorry I guess I should have been more clear. The recursion would
prevent the accessor from being called which would allow the ordinary
property code to execute, thus accessing the property directly. I
This could lead to weird scenarios where the same $foo-bar in random
function could
Hi!
On Windows there is no logrotate by defautl, so that would be a nice
feature ;)
I agree. This would definitely be a nice feature to have, at least for the
Windows build.
There are a number of solutions for that:
https://www.google.com/search?q=logrotate+windows
PHP doesn't have to
Hi!
Excuse my persistence. There must be a fix for this at the PHP level
that's palatable to you folks...
I'd suggest talking directly to PGSQL maintainers... In general, the
pull seems to be fine to me, but I'd rather have the people that
understand something in PGSQL APIs look at it :)
--
Hi!
Recursion is guarded by the same mechanism __get uses to avoid recursion.
__get on recursion returns undefined, __set on recursion does nothing.
However you're saying No direct access to the property would be allowed
except from within the accessor - but what this not allowing means?
Just
Hi!
That's why I think they shouldn't even be visible to users, they aren't
relevant to them and in fact it could mis-lead them into thinking that
they could simply define __getHours() and expect $foo-Hours to call
it, which it wouldn't.
I think it should. That's how __get works.
--
Hi!
What is reflection hiding patches referring to? Reflection is changed
to reflect what the user has defined, that's what reflection is supposed
to be.. no?
No. Reflection is supposed to show which methods exist on a class, which
can be called from certain context, etc. This has nothing
Hi!
Some people are in favor of the internal functions being generated by an
accessor declaration should be invisible and non-callable directly.
Others are in favor of leaving them visible and callable.
I think these types are not right. It has nothing to do with
internals/userland, it has
Hi!
v1.2 Proposes that this be inverted such that if there is an accessor
defined for a given property name, the accessor will always be used. The
accessor would be able to get/set/isset/unset the property with the same
name as the accessor. No direct access to the property would be
Hi!
/* Would be equivalent to this */
class TimePeriod {
public $date {
get() { return $this-date; }
set(DateTime $value) { $this-date = $value;}
}
}
I don't think this has a use case and this encourages mixing variables
with properties (which I'm not sure is
Hi!
1. If all cases can be tested for during compilation, prefer
compile failures.
Not likely. isset($foo-$bar) is completely opaque since we don't know
what $foo or $bar is.
2. Let the compilation occur and at runtime when a disallowed
action is attempted, emit a
Hi!
I just have one question: can we drop `public`? Default visibility in
We already had var, it didn't prove a good idea. PHP is explicit for a
reason, to be clear.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP
Hi!
users control. Actually, both approaches are exactly the same, the
only difference is whether we additionally put the accessor function
into the method table or whether we do not.
They may be almost the same technically, but very different
conceptually. Your approach means we introduce
Hi!
an accessor setter method for a property $_state IF that method would
follow the __set$PROPNAME pattern. As a solution for that, I'd propose
naming the new magic methods with a so-far-not-taken common prefix: __prop
- i.e. name them __prop_get_xxx, __prop_set_xxx, and so on.
I think it'd
Hi!
Stas, if you define an accessor, how do you define it? Do you say
Either way, doesn't matter.
According to the current proposal at least you can write the first
code *and the first code only*. If you write the second code then you
That's where I think it is wrong. It would be much
Hi!
My tendancy would be to target 5.5 only, but I can see the argument made
that it should target 5.3/5.4 as well... Thoughts?
I think it'd be fine for 5.4. Please do a pull req first though to be sure.
Thanks,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
Hello, list. I want to propose generics.
Please no. If you need Java, you know where to find it. Java has a set
of great tools, great books, great community. And it's completely free.
Anybody who needs Java can just do it. I see no need to turn PHP into Java.
--
Stanislav Malyshev,
Hi!
I'd like to propose a new short tag that echos with HTML escaping.
What is HTML escaping? Different contexts need different escaping. For
outside tags it's one escaping, for tag attribute it's another, for JS
code context - yet another. Selecting just one use case and integrating
it into
Hi!
I think we are still not on the same page here. The exact point is
to *not* put accessors into the method table. As such the accessors
aren't special, half-hidden methods (like they are with the current
implementation), rather they are *just* accessors and nothing else.
Accessors are
Hi!
get() { return $this-Hours; }
final set NULL;
It looks like some unobvious piece of magic - what exactly set NULL
means? There's no obvious parsing of this thing for somebody that
doesn't already know what the magic means. I'd rather have people
implement a method throwing
Hi!
Class A created property accessor $z that you can not set. Class B can
extend me just fine, but they can not alter that basic rule that I laid
out for my and all my children's property accessor $z: You can not set it.
I'm fine with the idea of methods that are not overrideable, even
Hi!
That makes some sense, still the issue Nikita brought up is that the
__getHours() should not be callable.
I don't see any use case for this requirement. What *requires* that it
won't be callable and why it is so necessary that we introduce
additional complexity into the engine just to do
Hi!
It is foolish to think that these two bits of code are behaviorally different:
class Entity {
DateTime $last_modified;
}
The are different because this one looks like a strongly typed variable
which brings with it a lot of connotations which aren't immediately
obvious, and in fact
Hi!
I see this argument crop up with every typehint discussion and just
don't understand it at all. Why would you want to check the variable
type everywhere? You just assign it and if it doesn't work, then you
get an error. Just like it should be. I mean, do you seriously check
No, you don't
Hi!
You have already written seven mails all saying how much complexity
this would introduce. Could you maybe elaborate a bit on that? How
would it make anything more complex? I mean, the only really
Any code that deals with methods would now have to consider - is this
regular method or
Hi!
public DateTime $date;
This is *real* progress, even if under the hood all it does is wrap
I think it's a movement in wrong direction. Again, it is an attempt to
make PHP a strongly typed language, which would not work well in a
dynamic language like PHP, for reasons that were amply
Hi!
The RFC states
ReflectionClass::getMethods() will not return accessor functions
(hides implementation detail).
Up until now reflection is leaky and is telling the truth. We should
either keep that or completely clean up reflection. (mind also
get_class_methods() and
Hi!
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
My feedback on the RFC:
1. Accessors IMO should be regular PHP methods that PHP generates with
two additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same
thing as
Hi!
Does the PHP programmer need the truth of underlying language
implementation details or do they need the truth of what they've
defined?
If the method exists, he needs to know it exists. For the rest, see below.
I would argue that if the PHP programmer has defined a property
accessor
Hi!
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes on this until all fine details
aren't hashed out. This is a *huge* feature - one of the
Hi!
I think that accessors should be allowed with interfaces because an
interface really is a specification on how to communicate and while
accessors do pass messages, properties do not.
Communicate is a loaded term. Property access is communication too,
but properties aren't defined in the
Hi!
#5: From what I understand, an extending class can not override an
accessor with a non-accessor.
This should be in the RFC then - along with what exactly happens. Note
that this will represent a sort of BC break in terms that you could have
two properties $a before, but if you change
Hi!
Not necessarily strongly typed. (sorry to land on this topic afterwards)
As I see PHP, it's a language that can be used as an informal scripting
language, but also as a rock-solid modern tool.
I have no idea what rock-solid modern tool means, though PHP is
trivially a modern tool by being
Hi!
Not necessarily strongly typed. (sorry to land on this topic afterwards)
As I see PHP, it's a language that can be used as an informal scripting
language, but also as a rock-solid modern tool.
I have no idea what rock-solid modern tool means, though PHP is
trivially a modern tool by being
Hi!
In regards to #11, yes, you'd just write {}. I imagine you could also
This doesn't work for the same class (and for traits which put things in
the context of the same class) - it would not behave as no setter, it
would behave as there's a setter doing nothing. Is this the proposed
solution?
Hi!
Stas, the proposed solution thus far is to make the getter or setter
final and private and not have a body. This would naturally throw an
exception if it was accessed from anywhere but the class it was defined.
The class it was defined in has to remember that it is virtually a
read/write
Hi!
If the first could be useful, the second could be useful too. Or you are
saying that parameters type hinting was a bad idea?
Given how it is understood now - as a first step to make PHP a strongly
typed language - yes, I'm starting to think it was. If it was understood
as it was intended -
Hi!
I apologize for my confusing terminology - let me elaborate. There are
no special syntaxes. The below code should help clear things up a bit:
class MyClass {
private $otherProperty;
public $property {
get() {}; // Does not have a body, as there is no code
Hi!
that supports properties in interfaces. Again, not exhaustive either
but there is one language that does support accessors in interfaces
and that's C#.
So what C# does when mixing regular properties and accessorized properties?
Think about it, if you allowed an outside caller of your
Hi!
This is the way it is, though Nikita strongly disagrees that they
should be callable, visible methods on the object and I agree with
Nikita on this issue, I never did like the idea that __getHours() and
I think PHP engine has enough complexity and we do not need to add more
unwarranted
Hi!
If you have a public property $a which internally can only deal with
it being set to 2 or 3 and someone external to the class sets it to
4, your class either has to check that it's 2 or 3 and deal with the
fact that it is now 4 or have indeterminate results when it is set to
4.
Most of
Hi!
I very much disagree, engine details should not be visible to users.
It is irrelevant to them and only serves to confuse.
It's not engine detail. We're not talking about exposing C pointers or
zend_op values. We're talking about implementing methods that have
special meaning. They are
Hi!
Now if you pass a closure to the scan method which doesn't follow the
signature of the __invoke method, the engine should throw an error.
What do you think?
You are trying to take typing way beyond what PHP (or probably any
mainstream dynamic language that exists now) provides. There
Hi!
I was looking into generators topic and I couldn't find answer to this
question: how generators are supposed to interact with PHP tools, such
as debuggers, profilers, etc.? Specifically, how calls to generator are
handled? Usually, the tool overrides zend_execute and
zend_execute_internal and
Hi!
object. When running `make test` I found that we already have a test for
the serialize/unserialize of DateTimeZone. The test checks that we are
_not_ able to serialize/unserialize the DateTimeZone object:
Hi!
I'm currently working on https://github.com/php/php-src/pull/186,
which fixes a problem with PostgreSQL when passing a float to
pg_query_params() with a locale setting that uses , as a decimal
point. pg_query_params() uses convert_to_string(), which uses %G as a
format string for floats,
Hi!
Quick follow-up, PDO::quote() and mysqli::real_escape_string() suffer from
the same issue.
Why would you feed doubles to escape_sting functions? I don't think it's
the right thing to do.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
We already have filter extension. Is it really necessary to invent yet
another way of filtering data?
Also,
Hi!
The point of the RFC is to ensure a consistent API for escaping is
available to all PHP programmers without resorting to userland
I do not see why without resorting to userland is a worthy goal in
every case. It's like saying I want to code in Python without ever
using import or I want to
Hi!
Filtering is very different from escaping. They each handle similar but
unique problems:
It is a purely artificial distinction. Filtering is taking one set of
data and returning other set of data, it can be applied on input,
output, or anywhere you want to. Just because we used filtering
Hi!
No it's not. A filter removes, but escaping lets the original content
pass through unchanged, with the necessary in-band signalling to make
sure that its content is not treated as in-band signalling.
Again, you are confusing particular implementation of a particular
filter with the idea
Hi!
No, he's not. Filtering and escaping are two very significant concepts
in security. Just because PHP implemented some escaping concepts into
the filter function does not mean that the concerns are co-related.
Again, you are taking very narrow definition of filterting, which is not
Hi!
Programmers haven't figured out how to use the 1-2 covering functions
that already exist and you expect them to do it in userland code?
I expect them to use libraries. I don't think anything that is written
in PHP means it's wrong and has to be rewritten in C.
Maybe we should ditch
Hi!
Filter has already gone down this road--I doubt the value added by having a
second, much
more verbose way to call htmlspecialchars()--but I don't see why we must
continue down
that path.
So, you don't think there should be second, more verbose way to call
htmlspecialchars - that's
601 - 700 of 1748 matches
Mail list logo
