Re: [PHP-DEV] Type hinting
On 2010-05-27, at 8:14 PM, Zeev Suraski wrote:
At 13:59 27/05/2010, Ilia Alshanetsky wrote:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
All of PHP is built on that kind of conversion. See Brian Moon's email for a
detailed instructions.
BTW - even if strict type checking was implemented, do you truly think people
won't simply cast their inputs to make PHP shutup about 42 not being a
valid int? Let me assure you, they would. You'd gain nothing - as a matter
of fact you'd lose out a bit since abc strings or arrays will happily cast
into (int), while with our proposed solution - they won't.
Is a 'scalar' typehint still being considered? It doesn't seem to suffer from
the conversion vs. typechecking argument.
As far as this discussion goes, I would want to add the following:
function f(array $a) {
}
f(1234);
f(new StdClass);
Currently both throw:
Catchable fatal error: Argument 1 passed to f() must be an array, integer
given
IMHO it would be inconsistent with the language to let an 'int' typehint behave
in any way different.
The way I see it, one end of the discussion proposes:
function f(int $i) {
}
as an alternative to:
function f($i) {
$i = (int)$i;
}
While the other end as an alternative to:
function f($i) {
if (!is_int($i)) trigger_error(..etc..);
}
The first mainly just saves a few characters, (or introduces a whole new type
conversion table), while the second provides
* a consistent way to communicate incorrectly typed arguments.
* strict argument passing, making it easier to spot mistakes earlier in the
development process.
While you can disagree the world needs strict typing in PHP, I find it hard to
believe the 'conversion syntax sugar' is really considered.
Evert
P.S.: The last thing I want is add more noise to the discussion. Consider
emailing me off-list if you want to respond to this.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Is a 'scalar' typehint still being considered? It doesn't seem to suffer from the conversion vs. typechecking argument. Currently, it's available in trunk: http://svn.php.net/viewvc?view=revisionrevision=299707 Ah that's great news, thanks! Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding serialize
Protected properties are serialized as:
0x00 + * + 0x00 + property name
The null characters don't show up in your console, but pipe the output
through for example 'hexdump -C' and you should see them..
Evert
On 19-Aug-09, at 1:37 AM, Chris Stockton wrote:
Apologies for the double post, but the output might help... long day.
Notice the strlen is different, as well as the truncation on
escapeshellarg.
--
string(43) O:13:testSerialize:1:{s:7:*_foo;a:0:{}}
string(45) O:13:testSerialize:1:{s:7:*_foo;a:0:{}}
bool(false)
string(45) 'O:13:testSerialize:1:{s:7:*_foo;a:0:{}}'
string(31) 'O:13:testSerialize:1:{s:7:'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.3.0 Released!
On 30-Jun-09, at 10:19 AM, Ilia Alshanetsky wrote: Chris, I've been using APC with PHP 5.3 on my dev box for sometime now and it works no worse then it did with 5.2. No worse! You're not really selling it :) Congrats all anyway, this is a release I'm quite excited about. Yay for closures! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP] PHP 5.3.0alpha2
On 4-Sep-08, at 12:06 AM, Andi Gutmans wrote: Btw, contrary to what many believe, 32bit PHP tends to perform better than 64bit PHP. So unless there's a really good reason why you want 64bit I wouldn't waste too much time on that. I have heard this before, but CPU hasn't really been our bottleneck on our webservers, rather than memory. Am I doing it wrong, or is that a 'really good reason' ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
On 13-Apr-09, at 4:06 PM, Stanislav Malyshev wrote:
Hi!
Thats because with short_open_tags on, you need to use:
?php echo('?xml ... ?'); ?
It's a pretty small use case (that's a problem only if you have xml
documents which has to have php code which has to be inlined) and as
you see, can be easily handled. I think that should not make whole
very useful syntax deprecated.
I think the parser should look ahead and check for something like :
/?(php|[\w])
(either ?php or ? + linebreaks/whitespace).
Evert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
I believe the end of your script part is the problem. Imagine you have some object (say, ActiveRecord style) that writes itself to the database when it's destroyed if the data has been modified. Now cache that object in a static variable somewhere for performance. You're also using PDO, so your database connection is a global or singleton instance of the PDO class. Then your script reaches the end. Does your object get destroyed and therefore saved to the database before or after the PDO object goes away? I don't actually know. I'm not saying that manual destructor order is the correct way to deal with that issue necessarily, but I think that's the sort of use case it's intended to address. If you want to treat a PHP script as a traditional application, you should be prepared to unset() and keep references of everything yourself. Relying on the garbage collector for your business logic to work is just bad design. I'd personally always explicitly do a -saveObject in similar situations as its predictable and quite frankly never found a use for a destructor other than debugging.. Sounds like a subject that doesn't belong on PHP-DEV in any event. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Help debugging overloaded objects
Ignore this message if it doesn't make sense.. wouldn't this essentially be the same as __toArray() ? Evert Marcus Boerger wrote: Hello Michael, ok current name and other options in one list: 1) get_debug_info() 2) get_debug_hash() 3) get_dump_vars() 4) get_dump_hash() does this list contain anythign you like? best regards marcus Tuesday, January 16, 2007, 8:32:41 AM, you wrote: Marcus Boerger wrote: Hello internals, the attached patch introduces a new handler to the engine that is supposed to help debugging overloaded objects. It allows to return a temporary hash rather then the object properties. This way an extension can show non properties in var_dump() and print_r(). It will be used in extensions like SimpleXML. To show how it will look like the changes for said extension are alsopresent. Last but not least the handler can be NULL in which case the old behavior is maintained. If noone objects I will commit this by the end of the week. Any comments? A strong +1 from me. Though, I don't like the name of the handler... Regards, -- Michael Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request
Edin Kadribasic wrote:
Dmitry Shirokov wrote:
Hey guys.
What are you thinking about adding this feature:
?php
function foo()
{
return array(1,2,3,4,5,6);
}
echo foo()[4]; // it that
// or may be (foo())[4] ?
// instead of
$var = foo();
echo $var[4];
+1 I would very much like this feature in PHP.
Edin
Me too, I know I don't have any voting rights here, but I'm running into
this one every day.
Evert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP bug search
The bug search doesn't seem to work correctly.. I was trying to find if there were bugs related to the ftp extension, but then i found out searching for 'ftp' wouldn't return anything.. So i wanted to be sure and try out 'PDO' and 'COM' as search queries, but nothing seemed to return anything.. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
