Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
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 applying to called functions/accessors? I.e.
consider this:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t; $this-timestamp = $t; $this-date = new
DateTime(@$t); }
}
}
What happens to it? Would it get into infinite loop or will just set the
value twice? What would be the correct way to write such a code (note
the real code of course could be much more complicated and probably
involve dozen of properties with complex dependencies between them).
Also, if this applies to functions called from getter/setter (which
seems to be the case from the code, unless I miss something), consider this:
class UserContext {
protected $user;
public $logger;
public $username {
get() { $this-logger-log(Getting username); return
$user-name; }
set($n) { $this-user = User::get_by_name($n); }
}
}
class Logger {
protected $ctx;
public function __construct(UserContext $ctx) {
$this-ctx = $ctx;
$this-logfile = fopen(/tmp/log, a+);
}
public function log($message) {
fwrite($this-logfile, [$this-ctx-username] $message\n);
}
}
$u = new UserContext();
$u-logger = new Logger($u);
$u-username = johndoe;
echo $u-username;
What would happen with this code? Will the log be able to log the actual
user name, and if not, how you protect from such thing? $username is a
part of public API of UserContext, so whoever is writing Logger has
right to use it. On the other hand, whoever is using logger-log in
UserContext has absolutely no way to know that Logger is using
ctx-username internally, as these components can change completely
independently and don't know anything about each other besides public APIs.
What I am getting at here is that shadowing seems to create very tricky
hidden state that can lead to very bad error situations when using
public APIs without knowledge of internal implementation.
Within isset/unset: the same rules apply, a read goes through the getter
and a write goes through the setter.
With this code:
class Foo {
public $bar {
get;
set;
}
}
How could I make it set to 2 by default and isset() return true when I
instantiate the class? Currently, I see no way to assign default values
for properties. Is it planned?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] release frequency?
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 unforeseen circumstances, of course) still doing monthly, just not sure it's worth it if we'd have less than 10 bugfixes per release... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
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 can not inject objects (there's still a matter of serialized data, but this can be handled by the class itself). 2. Support much more options in the file - e.g., right now it does not support streams, but libcurl has CURLFORM_STREAM - maybe we could use it, or maybe just read in the stream data and use it as CURLFORM_BUFFER. Of course, that would not work for big files, but here we are able to use much more options than with old @-based API. Any holes in this idea? If not, I'll try to make an RFC for it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
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 could be added to the previous one so that the old way work but there is a more secure way to do it) : curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array( 'firstname' = 'pierrick', 'lastname' = array(CURLFORM_CONTENTS = 'charron'), 'lastname' = array(CURLFORM_FILENAME = 'name.png', CURLFORM_FILE = '/home/pierrick/picture.png', CURLFORM_CONTENTTYPE = 'image/jpg') ); One thing we have to think about this solution is if at some point we want to allow sending array via curl, will it conflict ? I don't think we would allow sending arrays through curl, however there's another problem - theoretically, if user can access the data you put in $lastname variable, in many contexts it's not hard to put an array there either - i.e. if you have a form that has element lastname that posts to $lastname and then you do: curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array( 'lastname' = $lastname, /// etc. Then you could also create a form that posts to lastname[filename] and simulate this array too. So it's not a complete solution. I'm thinking maybe using separate option for files and deprecating the current one may be better idea. Unless somebody has even better solution :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #23955: Cookie Max-Age attribute
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 as RFC 6265 treats all negative values and 0 as the same: If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time. Otherwise, let the expiry-time be the current date and time plus delta-seconds seconds. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding Generator::throw()
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 connects to the database and database is not there - that's an exception. If you just have something like user clicked this button and not that button - it should not be an exception. Thus, exceptions should be used to handle cases which are not part of the normal program flow control. That said, it does not look like in this case (generators) it is being used wrongly, my initial impression was based on the lack of information, and turns out to be wrong. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
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 Actually, I would claim it doesn't make perfect sense, since it would mean DateTime would violate DateTimeImmutable's contract of being, well, immutable. Strictly speaking, they can not either extend from other one, since they have APIs which are not subset of each other. However, doing it strictly OO would mean getting into Java-esque web of interfaces, abstract classes and implementation classes, which would suck. As for established practice, everybody expects DateTime, so IMHO we should leave DateTime as base class even though it's not strictly OO-pure. Speaking of derived classes, though, I wonder how hard it would be to make DateTime factory methods - such as createFromFormat - to be able to produce instance of child class? Now if you want to extend DateTime and use those, you need to implement some weird things like: $dt = DateTime::createFromFormat($format, $time); $mydt = new MyDateTime(@.$dt-getTimestamp()); Maybe there's a better way but I'm not sure what it is. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
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 are a number of ways that you could lead to a crash in PHP. Say, some infinite loops can end up in crashes. Calling some functions with specific parameters on some systems could end up in crashes. Some libraries in some versions can lead to crashes. Etc, etc. We live in imperfect world, and that includes software which necessarily relies on other software. Making it perfectly 100% crash proof would be impractical. If you have any proposal on how to solve this particular problem, you are welcome to propose a patch. Otherwise, much more practical solution would be to fix that code. I think that it should at least gracefully exit, log error, what caused what and where. Better option would be that it just works. We can't really gracefully exit when OS produces bus error on missing part of the file, because you changed it non-atomically. The only way to avoid it would be to not use mmap, which would be a performance hit and also not very helpful as you'd just get a mangled file instead. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
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. Not sure what I did
wrong last time, but now I get bus error. I suspect there's some race
condition between mmap and rewriting the file that creates the problem.
The error seems to happen at offset exactly 0x1000 from the start of the
map, which leads me to thinking that maybe the problem is that the page
needs to be loaded, but since the file is not there, being overwritten,
it can not be loaded anymore.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
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 avoid the problem altogether and not need any LOCK_EX, dictates to ALWAYS write a temporary file (new inode), then rename it when the write completely succeeds. Otherwise any reader, like include, runs the chance of seeing a partially written file, and even without include using mmap internally, syntax errors would happen from time to time. This looks like a very good advice, regardless of bus errors. So, my conclusion would be that it is the code snippet above, and not any part of PHP or the kernel, that is at fault. We could probably add an option to skip mmaps, but since as you pointed out that doesn't really fix the issue completely, better idea indeed is to fix the code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
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 without APC loaded? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete traits redesign for 5.5
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 5.4 release :( The new solution may significantly change implementation and even behavior in some cases (e.g https://bugs.php.net/bug.php?id=62069). Thanks for looking into it! Could you write some description of what functionality changes are needed and why? An RFC would be helpful, so we have a definite reference and instead of going through all bug comments and risking missing something. BTW, could you after that take a look at bug #63462? It's kind of weird, and part of it with protected seems to be a bug (same property name is used both mangled and unmangled when using guards) but I'm not sure yet what to do with it. I may have time to look into it on the weekend, but would appreciate second opinion. Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
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 modifications to this approach, I'd probably be able to withdraw my objection entirely. Any standards group would have edictal approach. That's the point of standard - it prescribes a way of doing something. You may follow it or not, but if it doesn't do that it's not a standard. Now, I do not know if such standards will be successful in PHP world. But I think it's a good idea to try and see if people adopt it. Probably some things should have some standards - even if just to describe some common things - it's much easier to say we follow standard X than to have 10-page description of the coding style and trying to figure out if it's the same as another 10-page description or not. As for having php.net representative, I'm not sure if it is needed since I'm not sure what is the purpose of it. If it's just having a vote, I don't think it makes a lot of sense - php.net is not a PHP framework and does not represent any frameworks, and is to serve any of them and all of them and all non-framework developers equally. If it's to provide some expertise or answers to core/internals question, this can be done by anybody on the list without designating any special person. If it would serve some other purpose, I think additional explanation is needed. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding Generator::throw()
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 Could you expand on this point a bit more? It sounds like using exceptions for flow control, which is usually a very bad idea. this looks like see http://taskjs.org/. What the -throw() method would do in these examples is that it allows to check for errors by try/catching the yield statement (rather than going for some odd solution with error callbacks). Could you point to some specific example? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
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 SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
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 value type, and should be accepted by value, not as a complex object. So, it should also be identified as the value - for number 1, you do not need additional identity or hash except it being number 1, same should be for dates. I don't believe (at all) in if you don't need it mutable, don't use modify() oroverride modify(). If the API is there, people will use it. We tried to implement an immutable DateTime in userland, but it doesn't work out well... Why it doesn't work well and why PHP needs to be changed because of it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
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 objects, and instead they should create new instance when they want to change value of datetime type. And it's just bad that there could be situations when the entity will represent different data, after persisting, than database. You need not be aware of anything unless your database identifies dates by object identities, which is usually wrong since DateTime is a value type in most systems, and should be identified by value, as I already noted. If your data are mutable (which I assume they are, since otherwise the question of saving would not arise), you have to treat changes in title, body, etc. fields - treat the changes in createdAt field the same way. What about user-land implementation - there's one problem: I can't just extend DateTime object, because it has factory methods like createFromFormat, so I need to use decorator pattern and from that point hell begins. It is true that createFromFormat and other factory methods could use an extension that allows to instantiate child classes, however working around it is pretty trivial, not sure what hell begins there. I meant I must either call create new DateTime and pass to constructor timestamp string starting with @ (and there would be parsing involved) or call createFromFormat and pass U as second parameter and timestamp as first one. Yes, but what's wrong with that? It works just fine. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
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. value treatment. There's no reason for dates to be treated as non-value types having complex structure, and if you do not, mutability is not a question. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve DateTime Class
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, DateTime::INTERVAL_DAY); // for adding 15 days $date-modify(-15, DateTime::INTERVAL_DAY); // for subtracting 15 days I think there's a very low value in a new API that does exactly what existing API does but in slightly different way because of tastes of some particular person. If you want to add something that is not possible with existing API, it is welcome (given RFC, etc.) but just adding small variations on the same theme would only add confusion and if needed, can be very easily implemented in userspace. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
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 represent only one date. Reference to Java is not exactly applicable here, as many problems existing in Java (thread safety, long-living object references, etc.) do not exist in PHP. I don't want to change any existing functionality, because some people already use it, but I just wanted to point out that current DateTime class is forcing people to think about it as mutable. It does not - if you don't need it mutable, don't use modify() or override modify() with method that would clone the object and return modified clone. This can easily be done in userspace if you require an immutable object, which most of the users actually do not. Also, there's methods compareTo, createFromTimestamp and createFromDay, it could be another proposal. I think we are very often create DateTime objects just from timestamp or year-month-day. So we could introduce this methods that could not rely on timelib's parsing, and instead just take numbers directly. Timestamp doesn't need any timelib parsing AFAIK, but YMD certainly does - you need to calculate the actual timestamp according to current timezone, etc. And I think DateTime lack comparing method. For now I can compare DateTime objects only by getting their timestamps, but I though that the idea of DateTime objects can be compared directly, why do you think you can compare only timestamps? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call closure stored as object property directly without use of temporary variable
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 approach. This is the same thing. However, what you mean by closure instance is actually a property access, which is not the same thing as method call. Think about what happens if you have both __call and __get (or object implementing both handlers). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call closure stored as object property directly without use of temporary variable
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 thing ($foo-bar()) mean two different things (call method named foo vs. fetch property named foo and then call it if it's callable) is not a good idea this wasn't done. In some languages, the options above are the same - i.e. methods and properties are actually the same thing - but in PHP is is not so, and can be made so without some BC-breaking changes. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re2c --no-generation-date
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 the parser department. I'm not sure how to force rebuild of all files except for manually doing it, though. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re2c --no-generation-date
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 it on git commit, date in the text is not useful anyway. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS in PHP-5.4
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 NEWS does not have 5.4.10 section, please add it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.9 and PHP 5.3.19 released!
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 For source downloads of PHP 5.4.9 and PHP 5.3.19 please visit our downloads page at http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ David Soria Parra, Stanislav Malyshev and Johannes Schlüter PHP Release Team -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
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 disagree. I think in this particular case the change does make PHP better, and I do not value consistency for its sake and having 100% for its sake. If there were any practical reason why the change is wrong, that'd be different matter of course. P.S. I of course did not mean you or anybody else when talking about stupidly following rules, I just described a situation we want to avoid. Sorry if I sounded offensive, it was not my intent. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
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 no sense at all. To add insult to injury, it's wrapped in an if()! Please make me unsee it. The rules are there to protect developers from having functions dropped out from under them without warning. I know why the rules are. I just think in this case the function is clearly abused and delaying this improvement for at least a year because of somebody using logo guids as encryption salts makes no sense to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
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 the functions, but what these functions would do? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
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 practice. it doesn't suit us to. I agree: in practice, I can't imagine anyone caring a jot about these functions being removed, but we've said that when we're going to remove something, we'll deprecate for a minor release, then remove. Why don't we live up to it? Exactly because in practice it is not important. So on one side, you have making PHP better without any practical downside. On the other side, you have delaying making PHP better, but feeling good about strictly following bureaucratic rules. I prefer the former. Rules are important, but it is also important to not lose the sight of the goal - why these rules exist and when they make sense. And when they don't. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Functions for getting long / double from zval with casts
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 change the passed Where it happens quite often outside of function arguments (where it is covered by parameter parsing APIs)? Should it handle all conversions the engine performs or only from string? We could probably expose zendi_convert_to_long() and similar ones, but I'm not sure what the use case for these would be. Could you give more background on this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] questions about php structures
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 set of handlers (see zend_object_handlers structure). That's how the engine talks to the objects. That's what zend_object_value is. These objects can be, in theory, anything. In practice, all user-space objects (as opposed to objects that may be created by the engine) are something that we can call standard Zend engine objects. These objects are created from Zend Engine classes, have properties, etc. - that's what zend_object stores. These objects are kept in the object store and each time you create one it gets stored there and receives a store ID. That's the ID the rest of the engine (see above) uses to talk to the object. Note that custom objects (not standard ones) also can be kept in the store, but do not have to be. Keeping them in the store saves some work though - because you'd have to keep them somewhere anyway... zend_object_store_bucket is just a data structure used in the maintenance of the store - it contains the actual object data and some service values that are needed to efficiently manage store memory. You may also check out Zend/OBJECTS2_HOWTO file in PHP source - it has some more details. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
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? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 engines implementation details. That means that every part of the engine that deals with stack and reflection should be modified, for no reason other than to hide the scary fact of existence of accessor methods. I think this should not be done - stack traces should show stack as it is, and that's it. Reflection should show the methods as they are, and that's it. No additional complications and special exceptions in order not to hurt the feelings of (imaginary) easily scared and confused users. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 (stack traces, reflection, etc would hide the engines implementation details) I think that with the above, #1 makes it easy as no further changes are required to make that happen, they're already directly callable and #2 jives with what *most userland programmers* would expect. Anyone disagree? Yes. I strongly disagree with adding any magic to the engine that messes with reflection and backtraces and removes methods existing and being called from it. I think no userland programmer would have any problem understanding that these methods exist and how they work, just as nobody has problem understanding how __get works. I think adding this magic complicates both engine code (which will have to be supported for years to come) and the language, without absolutely any benefit to anybody except for imaginary people being scared to death by methods that they themselves defined showing up in the backtrace. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
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/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
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 can do is to cause them not be printed. However, any tool that intercepts error messages still sees them, they still consume resources when produced, still may break unit tests if you're not aware of them and they convert errors to failures like PHPUnit does, still will break any code that sets it's won error reporting if it doesn't remember to disable deprecated messages, etc. So adding warnings hurts performance and may hurt functionality even if you don't see them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object comparison
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 parameter is object, but say nothing what happens if the second one is object. This is for reason - if you compare object to array, they can't both be greater, something has to take priority. The docs say first arg takes priority. So by docs, comparison of (number, object) has no defined value, while comparison of (object, number) has. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 limited to return types. See: https://en.wikipedia.org/wiki/Liskov_substitution_principle If you look at classic Square/Rectangle example, it's all about semantics and has nothing to do with types. Instead, LSP simply states that, given B : A, all objects of A can be substituted by objects of B while preserving the validity of the method calls on these objects, and the validity of their return values. This is guaranteed here: I would suggest at that point reading actual description of the LSP. You rendition of it is wrong. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ICU UConverter implementation for ext/intl
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 have two separate procedures to feed these to object and to transcode(). Also, description of options would be helpful. 2. Shouldn't Enumeration and lookup methods be static? They look like independent from encodings and don't use the object. 3. For Advanced Use, I think no error condition should be the default and not requiring explicit action. 4. I think error reporting should match other intl functions. It'd not really be good if intl submodules would be all different in error reporting. 5. What is $source parameter for callbacks? 6. Why toUCallback returns string but fromUCallback gets codepoint as long? Shouldn't those be the same - i.e., if toU returns unicode codepoint, it should be long? Or it can return multiple codepoints? In which case it becomes confusing as we represent codepoints as both string and long in the same API. 7. Link to ICU API from the RFC would be helpful for reviewers and later docs, I think. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 I don't think I agree.
E.g. assuming that magic accessors take priority over properties as
you want it this time I can just turn the examples around:
class A {
public $foo { get() { ... } set($value) { ... } }
}
class B extends A {
public $foo;
}
= Here I would expect that public $foo from class B overrides public
$foo from class A.
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.
Basically any kind of interaction between properties and accessor
properties will be broken and inherently so, simply because magic
methods are not real properties (quite obviously...).
Magic methods are not properties, they are implementation of properties.
But your properties aren't either - see discussion about interfaces,
etc. They simulate regular properties but they aren't regular
properties. E.g., what would happen if you serialize an object with
simulated property?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 and/or a violation of LSP? Accessors
impose stricly more restrictions than properties. This code is fine.
You assume accessors are restrictions, but they don't have to be. Consider:
public $foo { get() { return $this-foo;} set($v) { $this-foo_copy =
$this-foo = $v; } }
You have a postcondition on set() that $this-foo_copy will be the same
as $this-foo. Override with public $foo removes that postcondition.
But proper inheritance should only strengthen the postconditions, not
drop them.
Just like it is fine in theory to have interface A { public $foo {
get(); set($v); } } class B implements A { public $foo; }
That's different. In this case, you say I will have some property
$foo, without promising anything about it. But specific code can
actually make some promises about $foo, and you can violate these
promises by overriding it with public $foo. Interface does not impose
any conditions except that $foo exist and is gettable/settable. Specific
getters/setters can impose much more involved conditions, which public
$foo may not be able to satisfy.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset failable
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? */
isset should return false, since $b is not set value. It should not
produce any warning. Of course (int) would produce 0 then ;)
I mean specifically, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing execution
No, the result is determinate - it's false. That's the point of isset()
in PHP and that's how it is used in existing code.
to stop I don't see it being a good idea to not warn the developer that
what they've attempted is not correct. Without a getter, isset() is
not a legal call (since the value cannot be retrieved).
isset() should always be legal. This is the way to check if $o-b is legal.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset failable
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 is now in PHP. Otherwise there's no point in having isset() operation - you can check for NULL with read, whole point of isset() is that you're checking both for read legality and read result, and it's guaranteed not to be issuing warnings if this variable doesn't exist (while reading may issue warnings). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 undefined bit is not required I think. Not
100% convinced on this, but from user reqs it sounds like they want to
drop the undefined bit.
A) Inheritance:
==
class A {
public $foo;
}
class B extends A {
public $foo { get() { ... } set($value) { ... } }
}
= With the accessors syntax there is an expectation that the accessor
declaration will override the previous plain property. At least that's
what I would expect and that's what the code looks like
That's why I'm not liking the undefined bit.
= With the magic syntax there is the expectation that the $foo
property will not be overridden. Rather the magic functions are
expected to do nothing, because the property already exists.
Err, I'm not sure why that would be the expectation. __get is for
undefined properties, since, well, it doesn't have any property name
attached, so it can't really be for defined properties :) However,
__getFoo (with whatever variations the bikeshedding committee will end
up with :) has property name attached to it, so requiring property be
undefined is not, well, required. Here we need to think which way is
better, and I currently tend to think accessor priority is better.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 create the function string, get it's hash value and do a hash look up against the function table, just to see if there is a Not really, as we have property_info structure where we could record the existence of such functions and we check property_info anyway AFAIR. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 that are uncallable and unavailable and not defined as regular methods. In both Ruby and Python they are callable and defined as regular (or regular with some special attributes) method. I've brought you examples of popular languages that don't have this feature at all - Java and standard C++ don't have it. I was wrong on Javascript - though in Javascript, functions work differently from PHP so there's no real relation to the current discussion. By accessors I am simply referring to getters, setters (and in the case of php, issetter and unsetter). I wish it was so, but it was mentioned many times in this discussion that accessors should be accessors and that only the situation where accessors are special functions that are not defined as regular methods, are not callable and are hidden from reflection, etc. is the situation where accessors are accessors. This is not the case in Python, Ruby, MS C++, D and Delphi by your own link - in all these cases, the properties are defined as regular methods (possibly with some special salt added) and no special effort is taken to hide them from any of the language facilities and make them not callable. Of course, there are also examples of languages going the other way - namely, C#, F# and VB - but by no means the claim that I would be hard pressed to find example of the languages which do not implement your notion of accessors being accessors is true. For most dynamic languages, the concept of accessors being accessors - hidden, non-callable pseudo-methods - is a foreign concept. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
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 call or not call an accessor depending on the stack trace (provided that accessors call out to other functions - which is not frequent but can definitely happen). In case of __get it's harmless since we know $foo-bar doesn't exist anyway, but if we do allow $bar to exist in $foo it might get weird. I'd certainly appreciate some notice/E_STRICT if this happens. Maybe I'd go even as far as issuing E_STRICT on having both $bar and any of the accessors for $bar in the same class - but this of course would scream on the scenario of augmenting existing $bar with accessors - which is legit, unless it gets weird as described above. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recycle PHP Log
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 include the whole world so that nobody has to install any utilities besides it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion
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 :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
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 returning undefined if __getHours was previously called? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 to do with where they were defined. Lastly, this idea that accessors is such a foreign concept is a bit ridiculous. You'd be hard pressed to find a modern/popular language these days that doesn't have them, so if someone is confused about what PHP doesn't have them. Also, by your definition, Python doesn't have them - in Python, __ methods are regular methods. Also, by your definition, Ruby doesn't have them either - in Ruby, you define them as regular methods, and you very well can call them too: http://stackoverflow.com/questions/621176/how-to-dynamically-call-accessor-methods-in-ruby#621193. Javascript doesn't have them either. Java doesn't have them either. So I'm not that hard pressed to find languages that don't follow your model, as you can see. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 to do with wanting more magic that work is a complex way while allowing user no knowledge and control over what's going on, or reduced number of simple concepts that interact in a variety of ways. You can say it's Windows model vs. Unix model, if you need monikers. *Type 1 ( Userland Programmer )** * As a userland programmer, someone who cares nothing for how php works, only how their own code works. If they define an accessor they expect to see an accessor, reflection should reflect that there are accessors and Again, this insists on the notion that there's such accepted thing as accessor in PHP field, which already has a known behavior and set of expectations, and these match exactly the proposal of invisible. But this is not true at all - only successors existing so far in PHP are regular perfectly visible methods. So if you expect to see an accessor, you expect to see __get. If you appeal to natural expectations of PHP user, you can not argue it is for accessors to be accessors, because PHP has never had anything like you proposed, and there's no any accepted definition of accessor that implies what you are implying. no other methods they did not explicitly define. If they were to reflect on all of the methods of their class and see a number of __getHours() they may be confused as to why or where this function came Please do not insult the intelligence of PHP users. They are not some mindless creatures that given property Hours, previous existence of __get and __getHours can not figure out what's going on, even after being told of the new accessors feature (since they're using it in the code). They won't be confused. Nobody knowing how to program a hello-world would. This mythical easily-confusable users do not exist, but if they did, they'd just not use reflection because it'd be too confusing for them anyway. than specially formatted and called methods on the class. This can be understandable because you want all information available to you. You This has very little to do with information available. This has everything to do with would probably not be confused if you wrote $obj?abc = 1 and got back an error like Fatal Error: Class-__setAbc() function does not exist. You can very easily handle the error in the same handler that you look for setter, this is not an issue at all. In general, error messages have very little to do with the whole thing. If the error messages is the thing you're worried about - it should be trivially easy to fix, since all access will go through object handlers anyway, and the object handler would decide to throw the error - so you'd be able very easily to issue any error message you like. *Unfortunately 80 to 95% of all people who use PHP are of the first type.** Not really. There are a lot of programmers that aren't Windows type, and prefer simple interfaces to ones with a lot of complicated magic. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
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 allowed except from within the accessor. One of the deficiencies frequently mentioned for __get was what if I want to override access for existing variable? Given that, I think accessor priority is a good thing. Now, with direct access from within the accessor it may get a bit tricky, especially considering loops, etc. What would happen in the scenario of __getHours calling foo() which does return $this-Hours? Is __getHours called again? Is it a fatal error? Does it return undefined like __get does? v1.2 proposal seems to make the most sense however it would incur a slight (possibly *very* slight) performance penalty. It may be an extra hash lookup, but if we could probably add the existence of accessor (or maybe even pointer) into zend_property_info then we wouldn't need the second hash lookup probably. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration
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 a very good idea) and writing
slower and more complicated code which doesn't actually do any
additional work. I'd rather not encourage it. If you want it - fine,
implement it, but I don't think supporting it is good.
Also, get() { return $this-date; } implies there is a thing called
$this-date which is not the property itself. So what is it? Should
there be additional public $date; declaration in your code? Is it
implied that property definition also creates a variable inside class
automatically - I was under expression this does not happen, and nothing
in the RFC implies it. Should it be $this-__date maybe like in
automatic accessors part of the RFC?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset failable
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 warning and move on. 3. As is currently, either at compilation or at runtime we issue a fatal error and stop execution (probably least preferable if at runtime) Actually, I think the right way is: 4. On isset(), if the value can be retrieved, return true. Otherwise, return false (including the case when the value can not be retrieved because of missing getter). Same holds for empty() but in reverse - if isset() would return false, it'd return true and vice versa. On unset($foo-bar), act exactly as if the code were $foo-bar = NULL; Of course, this applies only for automatic definition of isset/unset. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration
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 Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 new complex concept of not-quite-method, which can be called only in some special circumstances, has special handling by compiler, backtraces, reflection, tools, etc. and requires people to learn this new concept and be always aware of it to be able to correctly operate it. My approach is that you just have another magic method, which we already have plenty in PHP, and does not require any new concepts introduced, and works very similar to existing access magics. I still fail to see where you see complexity come into the picture. Described above. You want to introduce new entity into PHP called accessor, which looks like PHP method, but lives outside of the PHP method table, is not callable by regular means (though might be callable by special means, but you have no way to use methods' reflection to know if such call would succeed or not) and requires special considerations. This is more complex than using already existing concepts, by definition - more concepts is more complex than less concepts. You have mentioned inheritance checking, but from what I see the functions doing the inheritance check take generic zend_function*s, so they wouldn't have a problem dealing with code not in the method table. The same applies to pretty much everything else too. After all, there *is* a reason why we have abstractions in the engine ;) They won't have a problem. They won't deal with these not-quite-methods. That's exactly the problem - we already have mechanism of dealing with inheritance, and you propose to introduce another one to deal with additional complexity of methods not in method table. To me the situation is as simple as this: I declared a get accessor for $foo. I did not declare the method __getfoo(). So why is that method there? This in not simple. You know what accessor is. The other 100% of PHP users have no idea what accessor is. They know what methods are, they know what magics are. So if I tell them we have extensions of __get that allow you to do __getFoo - they instantly know what's going on. If I tell them we have accessors - they'd have to go and read the manual to understand what is going on and which additional restriction you placed on them in order to force them into your preconception of accessor. It seems really pointless, counter-intuitive and hacky to me to automatically create methods that do not actually exist (not under that name at least). What you mean by do not actually exist? Of course they exist, that's the whole point. You will be running them, how they don't exist? You just want hide their existence by introducing a bunch of complex checks all over the engine under the premise that showing the user the real methods in function table would confuse them. It won't. The only thing it would do is contradict your idea that there's some definition of accessors that requires them to not be methods. I see no reason for such definition. It is an option, but having them as methods is an option too, and in my opinion a much better one. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 more natural to make it __set__PROPNAME. Though __set_state is a static method, so maybe we can live with it - except that you won't be able to declare property named $_state. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 simpler and consistent with existing PHP if it were a natural extension of __get instead of a completely new and foreign concept. special behavior for properties. You probably won't start off with telling them that this declaration is automatically converted to a set of __getFoo methods which are registered as handlers for the accessor. I really don't see how going into details like __getFoo makes anything easier. Depending on your purpose and background. If you know how __get works, extrapolating to __getFoo is trivial. Getting special syntax that produces __getFoo from this is also trivial. Getting the concept of methods that are not quite methods and get called only through special intercept mechanism and have special backtrace rewriting engine and reflection hiding patches so you can be inside the method that officially does not exist - not so trivial. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing the default value of true for CURLOPT_SSL_VERIFYHOST
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/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generics proposal
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, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTML escaped short echo tag
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 the language is a bad idea - since you are basically saying everybody should use this specific case in any case, which is wrong. The new tag should be just as short and easy to type as ?=. Personally I'm a fan of ?- or perhaps ?~. Personally I'm hugely *not* a fan of more obscure syntax in PHP. Especially one that will quickly lead people into writing insecure code because of applying wrong escaping function for the context. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 not half-hidden now - they are just methods. That's the beauty and simplicity of it, and that's exactly why it works. I want to keep the simplicity and not invent unnecessary complicated entities. Keep it simple. It's all about making accessors accessors, rather than making them Sorry, I don't understand the meaning of this. You obviously have a preconception of how accessors should be, but please understand it's only obvious and natural to you, because it's yours. To me, and I'm sure to many other PHP users, it's an elaborate and complex, yet unnecessary construct, that works almost like methods but subtly different for some reason, and has no precedence in whole PHP history (and, actually, any other dynamic language history, as far as I can see). In my opinion, this is completely unnecessary, and even more - harmful. I'd like to keep PHP simple and have just methods as methods, just as they were in PHP for many years. Accessors need to be considered separately anyway, otherwise you end up with the problems that we currently have, where you can't override a property with an accessor in an extending class or the other way around. Having those pseudo-methods makes this even more complicated, This has nothing to do with precedence of variable access resolution, and nobody proposes pseudo-methods. The whole point is I am proposing *not* to do pseudo-methods, but use regular methods instead. Again, this has to be done anyway and is already done. Accessors need It does not matter. Unnecessarily complicated code in the engine is bad even if somebody already implemented it - because unneeded complexity is always harmful and it hurts even more over time, as everybody needs to support it and deal with it and make it work with all the rest of the engine. Keeping it simple is a very high priority. I think it's the other way around. As I already said above, the accessors won't be methods. So you don't have to consider anything. That's what I think is completely wrong. They work exactly like methods and that's what they should be. maybe during debugging or whatever). Now you either have to explicitly consider them in your code, for they are not actual methods, or the They *are* actual methods, or they should be. You just don't want them to be, but that's where it is wrong, because it creates unnecessary complexity, both conceptual and technical. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
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 exception manually than have this. It's
unclear what is relationship between set (is it a variable? a
constant? a method?) and NULL (what NULL here means? is it assignment
of NULL to set? is it declaration of NULL with type set?) and it does
not parse naturally with almost any background.
Thinking about it for a while, the whole idea of this class can never
have this method implemented looks a bit strange to me - I don't think
I've ever encountered such concept in OOP. You can say I implement it
this way and you can't override it but NULL does not suggest any
natural implementation.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
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 though I think the real use case for it is not that big. I'm less fine with the idea of methods that are not definable. Whole final NULL business seems weird to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 it? This isn't the way isset() works, isset() will return true for a variable with a value of 0 Exactly my point. Your code (with != NULL) will return false while real isset() will return true. AFAIK, there is no way to implement isset() in the same way, see my previous post about how isset() already causes a fatal error against the return value of a function. Of course there is. Again, you're confusing implementing it in PHP (which also possible but harder) and doing it in the engine (which should be as easy as calling right functions/opcodes). When you say check do you mean not allowed to compile? There is a runtime check that favors a property over an accessor, again Nikita wants to invert that and I agree. I mean issuing E_STRICT or whatever we do in other cases of LSP violations. This is not true, see my previous post demonstrating that isset(a()) causes a fatal error. I'm not talking about applying isset to non-variable. isset(blah bah blah) will also cause a fatal error. I'm talking about applying isset to a proper variable (or whatever is looking as one). isset($foo-bar) should never fail (to a reasonable degree - if you have accessor that gets out of memory, etc. we can't do much there) however $foo-bar is implemented underneath - it should only return true/false. public read-only $xyz;- Tells me that the property $xyz cannot be written to and furthermore cannot be over-ridden (the purpose of the read-only keyword). To be clear, the read-only keyword specifically means that no sub-classes may make this property writable, in other words the non-writable aspect means it is final. This sounds way too complex and too much magic. I'd rather have people implement it in user-space than introduce this complex and un-obvious convoluted concepts into the language. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 most of this is not needed. 99% of use of parameter
typing I've seen is done for purely documentation purposes and that code
would break hard if these types do not match but in the code they never
do since there are no other types that end up there. I think having the
engine run a lot of extra code just for the sake of documentation is not
right.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 get an error. You'd get an error in compiled language. In dynamic language, your client gets an error when his site is launched and instead of happy launch his users get white screens. To avoid that, you'd need to add checks - or just ship it as is and hope your unit tests were as good as you hoped they are (which they never are). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 special uncallable method? Can I call it? Can I list it in the list of class methods? This leads to weird situation where current method may not be callable and may not be found by reflection on $this. And all inheritance functions will have to consider them separately from all other methods, etc. And interface implementation has to be changed to account for existence of not-quite-methods. And so have traits. Etc., etc. Even conceptually, you need to be aware that there are methods of class and then there are non-methods which look exactly like methods in almost every aspect but aren't. This adds complexity and inconsistency - for no benefit whatsoever (I do not consider being not able to call __get* benefit since I see no use case for this requirement). I want to keep this simple - accessors are fine if they just produce a set of methods, everybody knows what PHP methods are and how they work, there would be just couple of more entries in function table, simple enough and every other part of the engine knows how to take care of such thing. But if they introduce a complexity of methods-that-aren't-quite-methods and live in a limbo outside of class table even though they work as methods, except in cases where they don't - I'd really rather go back to old trusty __get then - at least it is clear how that works and you don't have to deal with special cases and exceptions on every turn. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 explained in 9000 discussions we had on this topic before. functions and use function type-hints. This piece of code is SO much shorter and cleaner. Will it be a bit confusing to new developers? Maybe, but I don't care. It is not aimed at making the lives of new I think you should care. PHP is a beginner's language, it always was its core market. Adding more and more complicated features that benefit 0.1% of developers in PHP is a new direction, and I'm not sure at all it is a good direction for PHP to take. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 such) I think the reflection should return all methods that exist. If the accessors are implemented as PHP methods/functions (and I see no reason why not) then reflection should return it. Reflection, as you pointed out, should tell the truth. There's nothing leaky about it, IMO - yes, it's an implementation detail, so what? If you don't want to use implementation details, don't - just ignore all __ functions and don't call them. Python, for example, has tons of __ functions, and people live just fine with it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 __get/__set).
We should keep the amount of magic and special cases to the minimum, the
engine is complex enough as it is.
This of course includes the full range of options available for the
methods - final, reflection, call scenarios, etc.
2. isset is defined as:
isset() { return $this-Hours != NULL; }
This does not seem to be correct - != NULL does not work like isset now.
Try this:
class A { public $x = 0; }
$a = new A;
var_dump(isset($a-x));
var_dump($a-x != NULL);
This needs to be fixed - generated isset() should be defined to work
exactly like regular isset and actually use the same code path. Argument
to isset() call can be retrieved using accessor but it should not differ
from isset() result in any possible way or situation (including error
situations - e.g. notices, etc.)
3. How references and complex cases are handled? Didn't find anything
about it, e.g. how it handles $foo-bar++, $foo-bar[] = 1,
$foo-bar[123] = 4, etc. ($foo-bar being property with get/set defined
of course)? How $foobar = $foo-bar is handled? The sort() case
mentions by-ref return but does not explicitly mention all other cases.
These need to be covered explicitly in the RFC.
4. We have some LSP controls now in place to ensure non-LSP overrides
generate E_STRICT. Will this be the case for properties too? Meaning,
what happens if you add overriding protected getter to a property that
was previously fully public - thus violating the LSP?
5. What happens if you override accessor property with plain old
variable property? I.e.:
class A {
protected $secret {
get() { return secret; }
}
}
class B extends A {
public $secret = not a secret anymore;
}
Also, what happens here if A extends B in the same scenario (this refers
to the #4 too).
6. Thinking more about isset/unset - why not make isset/unset always be
the default unless overridden? I can't really see the case where you
want echo $foo-bar to work but if(isset($foo-bar)) echo $foo-bar to
not work. I think isset() and unset() should always use automatic
implementations by default (fixed in accord with #2 of course).
7. Error messaging section is not clear. Some examples would help -
what is being translated to what?
8. Static accessors section is not clear, namely this one:
This yielded the possibility that a getter call was being made while it
should not be allowed (if there was no getter defined) and so pass_two()
was changed to look for these non-backpatched illegal static getter
calls and a compile time error is produced.
When the code is compiled, the class definition (and, in fact, the name
of the class we're talking about) may not be available, so how can you
known if certain property of this class has getters defined?
Also, I'm not sure what is the thing about backpatching and converting
to function calls - I think it should work via engine handlers just as
the rest of the things work in the engine, is it not the case? If not,
it should be made the case.
9. This:
Eliminate the ability for an accessor to be called via $o→__getHours(),
the accessor functions will be completely unavailable for use except as
property references ($o→Hours)
I think it a mistake. More magic and complication in the engine is not a
good thing and would require tons of special case checks in all places
where we deal with functions. I think it is wrong - if we create a
callable entity, it should be callable. __ in the name is the indication
enough that you're dealing with special method and you should tread
carefully, we should not go out of our way to mess up the engine to
prevent it.
10. I'm not sure what the point about debug_backtrace() is but again, we
should not create more complicated magic there, it just should show what
really is happening.
11. About read-only/write-only thing - I like not having the keywords,
but it is still not clear how final produces read-only property - do I
say something like final set(); or how can I say there's no set and
never will be?
I'm sorry if some points were already discussed - I scanned through the
multiple threads but may very well missed something in 100+ messages
that there are, in any case I feel most of the questions above must be
reflected in RFC explicitly.
Thanks,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 then the truth to him/her is that it's a property accessor and should be reflected as such. The fact that the underlying php One does not contradict the other. Reflection can have specific calls to see properties and accessors, but if accessors are PHP methods - which they should be, since producing more unneeded separate entities that look like methods but aren't quite is wrong - they also should be seen as methods. See for example in Python - special methods have __ to specify they aren't something you should mess with, but they also do not go out of the way to make it a separate concept. We should do the same. We could have option for Reflection to skip __ methods in list calls, maybe - if there's a use case for it - but I currently do not see any use case for it at all. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 biggest ones recently, and has a lot of implications for various scenarios. Property access is what virtually every script in existence does, and doing changes there have implications that touch every corner of the engine. I think Clint is doing a great job with this RFC, but we need to carefully work through all the corners and side cases and relationships with all other features before we can declare it's ready for the prime time. Exactly because it is such a big deal it needs to be refined and polished. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
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 interfaces. In any case, if you're allowing accessors in interface, you should bring back automatic implementation of accessors, since if you're saying you must provide property $a I should be able to say OK, here's property $a, working exactly as plain old PHP property. Either that or I'd have to write a boilerplate code (and make a couple of errors on the way such as breaking references and isset, which 99% of less-experienced PHP programmers would do). I think accessors in interfaces are a huge can of worms because of their potential of mixing function calls and property access, while the latter is traditionally not the domain of the interface. We should carefully consider if we really have use case for it. Especially given that PHP always has underlying default property access functionality that is always available - unlike methods which if not defined lead to fatal error. So while if you do $foo-bar() on wrong $foo it will break, if you do $foo-bar on wrong $foo yu just get default behavior. Given that, do we really need an interface there? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 implementation of $a in base
class from plain old property to accessor property, the child class
would break. Which is not good, since compatible changes in parent class
should not break child classes - and which will also impede adoption of
this feature, since you can not guarantee no child class does it.
#11: If you set an accessor's get or set to /final private/, you are not
able to extend and it are only able to invoke it from the current class.
If you don't invoke it, then it is virtually read or write only.
I get this, but what do you write as a method body if you want to just
disallow it? Do you write just {}? Then it's not good for get() since
get() is supposed to return a value, and also not good for set() since
base class still can call private methods, and we want set() to be not
available for everybody.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 a tool and existing right now ;) Type hinting in parameters is a really good thing, and it doesn't transformed PHP in a strongly typed language. It however gave a permission to people to try sneak in strong-typedness through various backdoors arguing exactly that: but we have strong typing for parameters, why not for other things? I think it is not the right approach. Also, the fact is that other dynamic languages do not have strong typing. It may be they just aren't smart enough to recognize everybody needs it - or there may be a reason why it doesn't happen. I think there is a reason, which again was outlined some 9000 times here on the list. Doing the same for object properties (always optional) could be very useful. Not really, since PHP is not a compiled language and as such does not have static type controls. Now not only every foo($bar) can blow up but also every $foo-bar = $baz. Not very useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 a tool and existing right now ;) Type hinting in parameters is a really good thing, and it doesn't transformed PHP in a strongly typed language. It however gave a permission to people to try sneak in strong-typedness through various backdoors arguing exactly that: but we have strong typing for parameters, why not for other things? I think it is not the right approach. Also, the fact is that other dynamic languages do not have strong typing. It may be they just aren't smart enough to recognize everybody needs it - or there may be a reason why it doesn't happen. I think there is a reason, which again was outlined some 9000 times here on the list. Doing the same for object properties (always optional) could be very useful. Not really, since PHP is not a compiled language and as such does not have static type controls. Now not only every foo($bar) can blow up but also every $foo-bar = $baz. Not very useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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?
Exception is a possibility but then everybody would do it differently
which reduces the value of standardizing it (the whole point of having
accessors since otherwise we could just do __get and throw exceptions).
We went through multiple alternative options to read/write-only, and the
implementation you see in the 1.2 RFC is the most widely agreed upon
proposal. I don't doubt that there is room for improvement in this area,
but we haven't had any further proposals as of yet.
Actually, I do not see anything explicitly said in the proposal that
works for the cases outlined above. I wanted to just make sure if that
means no solution currently (then should be on TODO list) or we have
a solution but it's not outlined in the RFC (should be added then).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 only accessor. What you mean by not have a body - is there special syntax for body-less methods introduced? Then it should be in the RFC. How it is implemented - what exactly is stored in the function table then? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 - as a small hack to catch obvious code failures - then it'd be OK (not that great, but fine) idea, but given that more and more people misunderstand it as declaration of intent for PHP to be strongly typed language - I think maybe we would be better off not doing that after all. Last thing: I agree with Clint and you. If it was early checked, it would be better. But the current type hinting is far better than nothing at all. Yes, we can't lint it, but it was pretty useful a big number No, it's not better. Having code that can randomly fail with one error message is not better than having code that can randomly fail with another error message. It is more or less the same. It can actually be worse since it'd introduce more boliterplate checks in wrong places (i.e., you'd have to check every variable for correct type before assigning it to typed property) and does not provide any control over how the situation when something is wrong is going to be handled. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 between
the curly braces.
It does have a body. This body is just default empty method body
returning null - which does not throw any exceptions and is completely
indistinguishable from the outside from property being equal to null.
I'm not sure it's what the intent of *-only variable is, though I guess
it is a way to hack around it. I wonder however if it can be done better.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
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 class to
modify your internal state, any time you needed to use that internal
state you would have to validate it before you could rely upon its
value to be set correctly. No such issue exists with accessors in an
I do not see why this assumption is made that I need to do some special
validation each time state is changed. In fact, in 99% of existing code
it is not happening, and I assume this ratio will be kept even when
accessors are available. Most code will be very straightforward, not
doing anything complex with the state.
Now, I think the bigger question is: what exactly you want to
say/require when you write:
interface a { public $xyz { get; } }
and what is the use case for this requirement?
Just to be a bit more concrete here, as the code is presently written
and because I have strongly separated the concept of a property vs an
accessor, this code:
interface a { public $xyz { get; } }
class b implements a { public $xyz; }
Produces the following error: Fatal error: Class b contains 3
abstract accessors and must be declared abstract or implement the
remaining accessors (get a::$xyz, isset a::$xyz, ...) in %s on line
%d
I think this is wrong. 3 abstract accessors is especially wrong since it
doesn't match the direct interface definition and is very confusing (see
my earlier point about isset/unset always having fallback defaults) but
even with get as abstract I do not see a valid use case that would
require such behavior. What you want is for any $foo that is instanceof
a to be able to respond to read request to $foo-xyz, right? Class b
satisfies this requirement, why you reject it then?
Also, if you reject it - how I should fix it to make it work? Would I
have to implement a bolierplate getter/setter just to make interface
work? Doesn't look like a good proposition to me.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 one. These are methods, they exist - so they should exist
everywhere methods exist. Doing otherwise will result in a tons of
inconsistencies and weird occurrences. If you are in __getHours method
but the engine says __getHours does not exist and can not be called, it
is bad magic. There's no use case for this bad magic and I see no reason
for it except for us trying to restrict users for purist reasons. I do
not think the engine needs complex bad magic when simple solution of
making regular methods would work just as well in all cases where
methods work.
If I were to go about this again, they probably will not be methods
of the class. Internally there is little requiring an op_array to be
attached to a class in order to be executed.
So methods of what would they be? What would be their scope? What would
$this mean? What would method name and backtrace report? How
debugging/profiling tools would work with them? I see no need to
reinvent complex APIs that would require dozens of changes in all tools
dealing with PHP engine when simple methods approach would work as well.
If they won't be regular methods I think it would be too much trouble to
have yet another entity which is like method but not really a method
in the engine.
The reason that = NULL and != NULL was chosen is because isset() and
unset() are special states that are available only to a variable or
property, since a get/set do not return a real property they cannot
be used with isset/unset. Now that there has been discussion of an
I'm not sure I understand here. Property can be either set (exists and
not storing null) or not, there's nothing special about it - all
variables and properties work this way. Automatic isset should work
*exactly* like plain PHP's isset(), and unset should make variable into
the state where isset returns false (and resources are freed). The code
in the RFC for isset() is not working like PHP's isset. That should be
fixed.
This is covered in the RFC, perhaps not clearly enough (let me know
how I could expand on it further for clarity). To answer each of
Yes, it needs to be expanded, since no examples right now show how it is
supposed to be working.
I, perhaps mistakenly, assumed that if return-by-ref and sort()
worked properly, then all other usages of references should equally
work the same, is that not right? If it's not right, why not?
I'm not sure, I didn't check all of them yet. All these need to be tested.
Certainly, this basic object oriented functionality, of course it is
upheld. This is one of the reasons I leveraged standard functions in
the first place, because these issues were automatically handled by
the existing core.
I'm not sure overriding public $foo with public $foo { protected
get() {} } is covered by existing code. Existing code has no way to
cover such things.
This is currently up in the air on the RFC side and is being referred
to as which shadows which. The code currently has it that
properties shadow accessors, Nikita suggested that should be inverted
and I agree, so unless someone else thinks otherwise, accessors will
probably shadow properties.
Which raises the question above again - how LSP is preserved? What would
happen in such case?
See response to #2 above, without a getter/setter returning a real
property, isset/unset accessors were necessary because
isset()/unset() cannot perform on a dynamic value. Consider this:
You seem to misunderstand what I wrote there. I am proposing that
isset() would a) always have default implementation if get() is defined
and b) work exactly like PHP isset() in that the way that if get()
returns null (or does not exist if write-only properties are introduced)
then it returns false, otherwise it returns true.
The fact that current isset() operator does not work on T variables is
irrelevant, since I'm talking about level below that - how that operator
is implemented. The implementation should be augmented so that for
properties with accessors it would work exactly the same as for
properties without ones.
direction of accessors shadowing properties, I could see the default
implementation of isset/unset actually be more like unset() { return
unset($this-bar); } and isset() { return isset($this-bar); }
If this is pseudocode, meaning call get accessor if exists and return
true if return value is not null, otherwise return false then it's fine
for isset. For unset, you'd still want to use set accessor or fail if
set accessor is not defined.
Oh crap, you're referring to the idea that during compilation a class
definition may exist below the point of current compilation, right?
I had not considered this case and you're right,
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
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 the properties, however, aren't of that nature.
The use case is that you are declaring that interface a must allow a
property $xyz to be readable and *not* writable.
Why would you require for the implementor to *not* be able to do
something? Interfaces were never used to make class *not* be able to do
something. Are you sure it's good thing to introduce this? I think it's
not. I think interfaces should only define X should work but not Y
should not work.
Class b does not satisfy the requirement because you are missing the
fact that public $xyz { get; } forbids setting of $xyz, only reading
it.
See above, I think it's not the right use of interfaces. Also, error
message produced has nothing in common with this logic.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 still methods and it only makes sense that
they behave like other methods do. Not doing that - as you are perfectly
aware - adds a lot of complications and makes the engine inconsistent -
now you have methods that engine treats one way and methods that the
engine teats in completely different way, and in every place you deal
with methods you need to have special cases.
To be clear, they would be regular methods, they would just not exist
in the HashTable *functions of the class. In every other way they
are methods of the class.
Don't sound like a good idea. Imagine a debugger/profiler that works
with PHP. Now instead of having one hashtable to deal with it has two
since current function may or may not be in different hashtable. Imagine
extension or other tool or just engine part that deals with functions -
now everywhere you have to make provisions for the fact that functions
now live in two places instead of one. I don't think design-wise it is a
good idea.
See the problem?
I am *NOT* saiyng you should apply isset operator as it to it. I am
saying that code that is implementing the default isset should work
*exactly* as the isset operator would work on regular property. Of
course it can not be the same operator - it should be changed/extended -
but it should keep working the same way. E.g. not return not set when
property is set to 0.
I don't know the other contexts that need to be tested. There are
already over 80 tests written for this (.phpt) that all pass, please
let me know what other tests need to be written and I'd be happy to
write them.
I think the following cases should be covered:
- $foo-bar++/-- (postfix and prefix) - with actual value being number,
string, empty, not existing.
- $foo-bar[$index] = $x (with value being array, object with
ArrayAccess, string, integer - the last should produce proper error and
no leaks)
- $foo-bar[] = $x with the same as above
- $foo-bar-baz = $x with $bar being object or empty or non-object
value (proper error and no leaks)
- $foo-bar{$x} = foo (string offsets), also checks that non-string
vars work fine
- $foo-bar = $bar-baz, etc. with modifying both sides and checking
everything works (including modifying via accessors)
- property loop detection needs to be tested (i.e. $this-foo in getter
for $foo or $this-bar in $foo and $this-foo in $bar).
Maybe more if I'd think of anything.
I realize some of these may feel obvious but we're modifying very core
part - it's better to be safe than sorry.
It's preserved in the same exact way (and by the same exact code)
that any other function over-rides are handled. The accessor syntax,
LITERALLY, translates into functions and thus go through the ordinary
LSP preservation lines of code. It's the reason I chose to go that
route in the first place (to leverage the existing LSP checks)
The accessor syntax translates to functions but public $foo does not.
That's the issue. There's no existing check for overriding public $foo
with private accessor. There are checks that would work between two
accessors - but not between accessor and plain property.
With isset/unset accessors, they *can be* implemented appropriately,
with automatic isset/unset implementations, they cannot, for reasons
stated above:
php isset(a());
Fatal error: Can't use function return value in write context in php
shell code on line 1
You do not need to apply isset() as is to function call. You can have
isset method that is smart enough to do the right thing. You're writing
the engine patch, not the PHP code transformation tool, so you can do
more things here. If you need specific, I can look into the code,
probably later as I'll have to move on pretty soon :)
You've got that right... isset() cannot exist (and is not allowed) if
isset() should always be allowed - it just should return false if
something goes wrong. This is how it is used now - as safe operator
which will always work and return false if something is wrong. Making
isset() not allowed means that you need another operator saying am I
allowed to call isset() here or will my code fail?. No need for that as
isset() is exactly such kind of operator for read access. No such thing
for write access btw which is quite bad since nothing now guarantees
simple $foo-bar = 1; wouldn't blow up and there's no way to check for
that. Which makes impossible to write robust code. This alone makes me
very uneasy about the whole read-only idea.
Yes, these cases were not considered. The static accessors portion
of this project took up an inordinate amount of time as compared to
the rest.
Maybe we should limit accessors to dynamic ones for now or split it out
to additional spec/1.1
Re: [PHP-DEV] Closures and type hinting
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 are languages which provide static type systems capable of doing such things, but PHP isn't one of them and I don't think it should be. PHP has no static type control, and IMHO doing type safety validation at runtime does not seem to be a good proposition for PHP. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] generators php tools
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 every function call goes through there. But generator does not use these - it uses execute_ex instead. So can generator be debugged/profiled? What happens if I say step out inside generator - would that work? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeZone Serialize/Unserialize
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: https://github.com/php/php-src/blob/PHP-5.4/ext/date/tests/DateTimeZone_serialize.phpt Is the test correct or do we want to be able to serialize/unserialize DateTimeZone? If the test is correct, why do we not want to be able to serialize/unserialize DateTimeZone objects? We want it to be serializable. This test probably should have been XFAIL test instead, but in general it's kind of hard to test for code that doesn't work, so I guess it was instead made to test the current state of the code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion
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, which is locale sensitive (and therefore converts e.g. in hr_HR or de_DE to 1,1). The proposed fix is to introduce a new API convert_to_cstring() in the Zend Engine to allow converting types to C-locale strings. I'm not sure adding new engine API for this specific use case is a good idea. If it's just for query parameters with specific type, can't it just use printf with needed settings there? PHP generic settings may be not good there in any case, as it is probably also influenced by precision, which is not a good idea for database - if I set precision to 1, do I really want all my DB data be rounded to 1 digit? This kind of fix is very likely needed in other places, where floats are converted using convert_to_string(). I haven’t found time to try If you specifically set locale to hr_HR - i.e. say PHP, please know that my floats use , as a separator - why PHP should not do exactly what you asked it to do? What’s your take on the proposed fix of introducing convert_to_cstring() and using it where external protocols require a locale insensitive float conversion? I'm afraid figuring out in each case which conversion to use will create a mess, especially that the requirements is likely to be contradictory in different cases. I'd rather recommend avoiding using locales for that and instead use ICU number formatting functions when you need to format numbers. Locale kind of implies all your data behave the same, and it's obviously not the case here, and rarely the case anymore in systems involving so many components. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
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, a problem with putting code of this complexity in core would be that if it every had a defect - e.g. we forgot to account for some weird browser quirk that does not follow RFCs, or some strange encoding combination, or just a plain bug - it would be very hard for the users to mitigate without upgrading PHP - which is not always under their control. When using PHP code, they could just d/l new ZF class, but with core implementation it'd be much harder. So far I am not convinced we should really do it. But if somebody creates PECL extension and it proves popular, it may be merged into core once it does. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
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 code in Perl without ever using CPAN. Makes no sense, right? Why we should insist on this in PHP? solutions. Existing functions are widely misused, misconfigured or have builtin security issues yet are popularly advanced as escaping for XSS. Do you think your functions won't be misused, misconfigured and never would have bugs? Exactly the same would happen. Having yet another API doing the same as old API is not a solution. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
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 for input, does not mean we can't use the same for output, there is absolutely no need to reinvent the wheel just because we're using it in different place now. It is a mistake to think that because we started to use filtering on input data, now the word filtering means it should never applied to output and we have to invent whole new API to do the same. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
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 of filtering. Moreover, even existing filters do not match your description: FILTER_SANITIZE_ENCODED, FILTER_SANITIZE_MAGIC_QUOTES, FILTER_SANITIZE_SPECIAL_CHARS, FILTER_SANITIZE_FULL_SPECIAL_CHARS, FILTER_SANITIZE_STRING, FILTER_CALLBACK But in general, look at implementation of filters anywhere - like Apache filters or IIS filters - nowhere it is said that filter can only remove data. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
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 justified by anything but your very narrow use case, and try to present it as if this is the only meaning filtering has (despite numerous examples of using of filters in more generic sense) and that because of this we need to duplicate APIs we already have, just because you can use them in different context. To me, it makes no sense - you can apply data filtering anywhere. If for your specific purpose of explaining how to make better security architecture you choose to define filtering and escaping as narrow distinct concepts, this is fine. This does not mean that we can not use existing filter extension - with already implemented methods doing exactly what is needed to be done - because they are to be used in context which you call escaping. Actually, that's the basic definition of a filter (from a security context). Just because people implemented other things and called them filters does not make them filters in the context of this discussion. It is your definition of a filter, which is in no way basic or universal. The other point that you seem to be missing is that filtering is generic for an application. You would apply the same filters for content that came in from an HTTP post as content that came in from a JSON API call. The data is what's filtered for your application. Again, nowhere it is said that you can not apply different filters to different data or different context. Again, you narrow down definition of filtering, to which I see no purpose unless you seek to arrive at pre-determined conclusion that we need to duplicate APIs because it's called filter. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
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 json_encode() tomorrow. I can do it in userland code too. PHP does a LOT of things possible in userland code. The argument I made in the RFC boils down to simply giving programmers a helping hand. They are writing insecure code because PHP isn't fulfilling that need for one of the most serious security risks in PHP today. Surely that warrants action to serve programmers? We already have basic functions that do that, and we have extension that does that. If you need more, I'm not sure you should do it in C. If you do just the same under a different name, I don't think it should be done at all. encoding. That's 2 versus the list of flaws in htmlspecialchars() I blogged about (the link is in the RFC) and whatever might theoretically exist if PHP actually had Javascript and CSS options. I think the approach of creating third data filtering API (plain functions, filter, and now this) in PHP core is wrong. I do not see why the same functions can not be (in case of CSS) or already are not (in case of most others) implemented in existing functionality. If the whole question is that people don't know which one to use in which context, creating an entirely new core API does not sound like a good solution to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
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 why we should add third, more verbose way to call htmlspecialchars? Somehow this does not sound convincing to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
