RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
Also, be aware that BCrypt only uses the first 72 characters of the password field. So if you use a hex encoded sha512 output, a good deal of entropy would be lost (almost half of it)... Good to know, do most hash algorithms have limitations on the # of chars as input? That would explain why (password || key) into a hash function has limitations. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
On Tue Jul 31 12:21 PM, Anthony Ferrara wrote:
Jonathan,
Again, implementing something in the core that's not verified and
can't be implemented well by the vast majority of developers out
there.
Alright so I found some people supporting my claims:
http://blog.mozilla.org/webappsec/2011/05/10/sha-512-w-per-user-salts-is-not
-enough/
http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/
It looks like Mozilla is using what you suggested, to be honest I don't
quite understand the difference between:
a) password_hash_rfc( hash_hmac('sha-512', 'password', '1024-bytes secret')
);
b) password_hash_rfc('password' . '1024-bytes secret' );
It seems to me that (b) would more computationally expensive to break since
you have more bytes in a slower algo.
Interestingly enough, there was a proposal for MD6 to be a keyed hash (with
pepper)
http://people.csail.mit.edu/rivest/pubs/RABCx08.pdf (3.5 A keyed hash
function)
There does seem to be some research on keyed hash functions here (4.2 MAC
construction):
http://research.microsoft.com/pubs/64588/hash_survey.pdf
But this use case has nothing to do with securing passwords
SHA1(k||M)
I guess my final point is a lot of code out there already do hash passwords
with a secret key, it would be nice to have that facility in PHP core.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
On Wed Jun 27 12:32 PM, Arvids Godjuks wrote: because at the moment i do not understand how salt stored in the hash itself makes hash more secure than an unsalted one. a) In terms of 'effort' to break many passwords, there's a benefit to the salt stored in the hash itself. It's not 'more secure' but 'better/recommended' since the attacker would need to create a 'rainbow table' for each password it's trying to crack Overall, the technique offers better protection. b) In terms of 'effort' to break a single password, there's **no** benefit to the salt stored in the hash itself. If you want a single password to be really secure, don't let the attacker know the salt and keep it long: // no benefit of short salt, ~ same effort required by the attacker $password = '234'; md5($password); $salt = '1'; $password = '234'; md5($salt . $password); c) The best of both worlds: long private salt (b) + different for every user (a) $saltInpassword = $password[0]; // could be random bytes, stored in password like crypt() does $salt = 'my-long-private-value-use-all-bytes'. $saltInPassword; $password = '234'; $hash = md5($salt . $password); This one requires more effort by the attacker since the long salt forces more 'bits/guesses' to pass into md5() // require even more effort, iterate for($i = 0; $i 1000; $i++) $hash = md5($i . $hash); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
https://wiki.php.net/rfc/password_hash
-- password_hash()
password_hash_rfc(string $password, int $algo, array $options = array())
My personal opinion is the api should be:
password_hash(string $password, string $secret = '', array $options =
array());
where $options['method'] = PASSWORD_METHOD_BCRYPT;
Some people mentioned that the method/algorithm in should be the api? What
was the problem if crypt() stores the actual method/algorithm in the hash?
Using this api, we let crypt() should a random salt value and we pick our
secret.
Say you have:
define('MY_HASHING_SECRET', 'hhtrg54~%$%4long');
$password = '1234';
password_hash_rfc($password . MY_HASHING_SECRET, PASSWORD_METHOD_BCRYPT);
password_hash($password, MY_HASHING_SECRET);
Note here that in both cases we let crypt() generate a random salt that is
different for every password and store in the password.
But our 'secret' that is appended to every password is not stored in a
database for example, it's in some ways similar to a private key.
-- password_make_salt()
I would remove the need for this function.
I think it's important the api emphasizes the importance of keeping a
'secret' + has the added value that every password hash is different with a
crypt() salt.
Thoughts?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
Say you have:
define('MY_HASHING_SECRET', 'hhtrg54~%$%4long'); $password =
'1234';
password_hash_rfc($password . MY_HASHING_SECRET,
PASSWORD_METHOD_BCRYPT); password_hash($password, MY_HASHING_SECRET);
Note here that in both cases we let crypt() generate a random salt that
is different for every password and store in the password.
But our 'secret' that is appended to every password is not stored in a
database for example, it's in some ways similar to a private key.
-- password_make_salt()
Another comment about this, the 'secret' in this case in somewhat similar
the 'purpose' of the salt:
http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
S = purpose || rv
P = password
What I'm proposing is:
S = rv (random value from crypt)
P = password || purpose
In the end, it's the same thing we're feeding into the hash (more data/bits)
Whatever api is used, I think it's important to allow appending this purpose
or secret that's not stored directly in the final crypt() hash.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
RFC: https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper Thanks, I missed it... I strongly disagree with this, the 'pepper' IMHO is a best practice for web applications. I prefer to live with the idea that an attacker may comprise some database(s) in the 'cloud' but not the physical machine where you can store the pepper either in a file, share memory etc... As far as missing research papers, it's hard to do research on the benefit of keeping something private. If/when databases do get hacked, it's rarely released to the public how it happened. When it comes to web applications, my opinion is odds are greater in SQL injection / data theft success then gaining physical access to the machine. #1 SQL Injection: https://www.owasp.org/index.php/Top_10_2010 Sure it's an added layer of security but it's hard to deny the 'pepper' can't help protect passwords against the #1 risk for php/web applications. A pepper in UNIX crypt() itself would be obviously useless, the user already has access to the physical machine (cat /etc/passwd). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron HYPERLINK
I strongly disagree with this, the 'pepper' IMHO is a best practice
for web applications.
Again, I have not seen this being said by any security or cryptography
expert.
Like I said IMHO, I'm not a security expect but I do think there needs to be
modern discussion around 'web password hashing'.
Ok. So I register an account before I get the database. Now the only thing
that I need to crack is the pepper (since I know the salt, hash and original
password for my sentinel account).
Fair enough ;)
It can still be a problem if the pepper is large + the crypt() salt
With all of that said, if you really want a secret in there, don't
hijack the hashing algorithm to do it. There are two somewhat decent
alternatives:
HMAC the password with the secret prior to passing it to
password_hash()/crypt(). HMAC is secure and is designed for this
exact purpose.
Not so great:
password_hash_rfc( hash_hmac('md5', 'password', '1024-bytes secret') ) //
hmac is short (~ 160bits)
I guess you mean:
hash_hmac('md5', password_hash_rfc('password'), '1024-bytes secret')
But then there's no way to know all those crypt() parameters, salt, cost,
etc...
Maybe a new api?
password_hash_hmac($password, $secret, $options = array());
Encrypt the resulting hash with a secure encryption function
(RIJNDAEL_128 + CBC) prior to inserting it in the database. That way,
each component uses standard algorithms as they were designed to be used.
That's fine, I feel this should be somewhat easier in php core (without the
need for openssl al.)
It also comes with a cost of decrypting the hashes / not so great
But I want to stress something else. Properly managing secrets is VERY
difficult. It's not even really possible in PHP, due to the way
copy-on-write works, and how variables are removed. To implement this
sort of a system correctly is not something even highly competent
developers can typically do. It really is that difficult to get right.
Sure managing keys properly can be hard, simple cases:
$secret = MY_KEY;
$secret = file_get_contents('/security/key.pem');
Again I'm making the assumption that the attacking *does not* have access to
the file system.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Add hash_pbkdf2 function
On Mon Jun 18 07:14 PM, Anthony Ferrara wrote:
https://wiki.php.net/rfc/hash_pbkdf2
I like this proposal, it could be useful to add a simpler api that has
defaults matching the NIST recommendation:
hash_password($password, $salt, $algo = 'sha1', $iterations = 1000);
if the salt doesn't have at least 16 characters (128 bits), throw error
internally this calls:
hash_pbkdf2('sha1', $password, $salt, 1000);
My point being that:
$hash = hash_password('1234', 'my'. $password[1] .
'super-long-salt-secret');
Gives good enough security 80% of use cases and is simpler then:
$hash = hash_pbkdf2('sha1', '1234', 'my'. $password[1] .
'super-long-salt-secret', 1000);
Developers will still use sha1 or md5 because they are so simple.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: SPLClassLoader RFC Thoughts And Improvements
On Fri Nov 11 12:13 AM, Stas Malyshev wrote:
- MODE_DEBUG: This one can work together with the other two,
allowing a validation of class/interface/trait presence in the file.
Basically,
it requires the file and then checks if the item exists in scope.
Not sure debug adds much here - if the class is not found, you'll be
notified by the engine anyway, so what's the added value?
Right there will be fatal by engine anyway Class does exist..
Our approach with autoloading has been the following:
spl_autoload_register('MV_Autoload');
function MV_Autoload($className)
{
try {
MV_Loader::classImport($className);
} catch(MV_ClassNotFound_Exception $e) {}
}
It seems very wrong to me to generate a fatal error on class_exists() al.
That's unless the spl_autoload_register() api changes and allows to deal with
errors - require(), Exception, ...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] who can vote
On Wed Nov 9 10:01 PM, guilhermebla...@gmail.com wrote:
Some would simply say he only did that because he got 3 proposals
rejected. Others would say he is pressuring A to be in PHP. But not.
I learned the hard way and multiple times to hear a big NO. But at the
same time, I earn my salary from a language that is lead by people
that do only what they want, not what the language really needs. PHP
is a mess, everyone knows it. You have the power to change that, to
make it right.
spl_autoload_register('SplAutoLoader');
class_exists('Foo'); // Fatal error
is_a('Foo', 'Bar', true); // Fatal error
is_subclass_of('Foo', 'Bar'); // Fatal error
How exactly is PSR-0 making the language better? It's inconsistent with what's
in core.
That said, I don't think there's anything wrong with bringing the className =
fileMapping convention of PSR-0 in core.
Small political note: I trust decision making in php to people who understand
the internals of the language (on a majority that's the core devs).
Other political note: PSR-0 seems to imply that your 'standard project' should
have a particular directory structure:
https://github.com/lapistano/fig-standards/tree/compatibilityTests/
Is this right, wrong, for the better good?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: jbondc
Bring improvements to serialize() and unserialize() -- a consistent serialize_text() which does change based on config + no more NULL bytes. Possible improvements to PDO and stream related enhancements. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] SplClassLoader
On Thu Nov 3 03:06 PM, Will Fitch wrote:
Wouldn't you consider spl_autoload_register an interoperability
solution? Only your defined autoloading function would then need to
know how your file system is structured, there'd be no need for
include_path declarations and you wouldn't have to explicitly declare
paths for each class.
The problem with spl_autoload_register() is it isn't clear what the
autoloading function is supposed to do if the class if not found.
So no I don't think spl_autoload_register() solves an interoperability
problem. SplClassLoader somewhat does a better job by forcing a common
implementation...
function FrameworkA_autoload($class) {
if( !isset($AmapToFile[$class]) )
throw new Exception('Class '. $class . ' not found!');
include_once($AmapToFile[$class]);
}
function FrameworkB_autoload($class) {
require_once($BmapToFile[$class]);
}
function FrameworkC_autoload($class) {
include_once($CmapToFile[$class]);
}
spl_autoload_register('FrameworkA_autoload');
spl_autoload_register('FrameworkB_autoload');
spl_autoload_register('FrameworkC_autoload');
So both 'FrameworkB_autoload', 'FrameworkC_autoload' are never called.
Btw, I would hope that any 'standard' would actually that try to talk about
other autoloaders and how they should behave.
https://gist.github.com/221634
See comments about include() or require()
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
On Sat Oct 22 04:38 AM, Nathan Nobbe wrote:
Hi folks,
With a 5.4 release right around the corner I'd like a moment of your
time to reconsider this issue [1].
Just curious why it died on the table if several folks saw value in
it, including Stephan who I gather is the primary architect of traits.
The dispute regarding the feature was the merit of a 'compile time'
check vs placing the burden on the developer to ensure all methods in
a trait are provided by the class in which it is used. In an earlier
conversation about traits Stefan said this:
Yes, Traits are meant to be compile-time only, they are not used to
introduce typing relationships.
Which makes me even more comfortable about the merit of another
compile time check. As I argued in the original thread, the feature
is merely an embellishment atop the already supported use of the
'abstract'
I think it's up to Stefan's experience wisdom.
To really cover all use cases, it might be worth looking into using a require{}
block as a way to list the requirements for the composing class (and get rid of
the abstract syntax).
e.g.
trait Bar {
require {
function foo();
private $_prop;
implements Iterator;
}
function moveNext() {
$this-foo();
$this-_prop = 'hello';
$this-next();
}
}
class Foo implements Iterator {
use Bar; //ok
function foo() {}
private $_prop;
function next() iterator methods
}
class FooFailure {
use Bar; // E_FATAL: composing requirements not met (implements Iterator,
function foo())
private $_prop;
}
Traits is already an advanced concept, a conservative approach would be to
remove the 'abstract' check and see how people end up using traits.
If there's enough use cases (not foo/bar examples) out there that need compile
time checks, add the proper syntax for it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] SplClassLoader
On Thu Nov 3 11:19 AM, Anthony Ferrara wrote: But that's besides the point. I just want to emphasize the point that performance should not be a criteria for justifying it going into the core... There also seems to be the perception among some php devs that autoloading is now the preferred way of loading PHP code. So adding require() or other explicit dependencies add the top of your scripts is no longer the appropriate way to do things. SplClassLoader solves an interoperability problem. Shouldn't it be promoted as such? So overall I agree with Anthony, performance shouldn't even be an argument. If you want to solve a code loading problem, autoloading everything is far from a silver bullet and in my opinion not a good solution. The main question seems to be: does interoperability belong in core? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
On Sat Oct 22 10:25 AM, Anthony Ferrara wrote:
Well, I have a few opinions on this that I think are worth sharing:
1. If this change is made, we no longer would have mixins, but would
have regular multiple-inheritance (With all the issues associated
with it). Note that I said mixins and not traits. That's because
since these were implemented with state (member properties), they are
not traits as implemented, but regular mixins. (Yet another gripe, but
that's slightly off topic).
I think you misunderstand the difference between traits and mixins:
http://code.google.com/p/es-lab/wiki/Traits
Scala has mixins, php has traits.
In short, the composition order does not matter with a trait (because there are
conflict resolution rules).
With a mixin, the conflict resolution rule is the order of declaration. class
foo mixwith bar1, bar2 {} // bar2 wins
Though traits were originally defined as 'stateless', it doesn't make them
'mixins' because they have state:
http://bergel.eu/download/papers/Berg07e-StatefulTraits.pdf
Javascript is probably the best example of 'mixins':
myobject.mixin(bar1,bar2, {otherMethod: function(){} })
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] is_a fix for 5.4 and HEAD
On Sun Oct 16 06:59 PM, Stas Malyshev wrote: It definitely makes PHP worse by propagating inconsistent APIs. I created a patch against 5.4: https://bugs.php.net/patch-display.php?bug_id=55475patch=is_a_5.4_alternati verevision=latest The patch changes the behavior to: is_a(ab, b) // false is_a(ab, b, true) // autoload ab, autoload b -- false is_subclass_of(ab, b) // false is_subclass_of(ab, b, true) // autoload ab, autoload b -- false Both class names can be autoloaded but not by default Thoughts? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: is_a() - again - a better fix
On Wed Sep 21 09:57 AM, Matthew Weier O'Phinney wrote: It then reverts is_a() back to the previous behavior, and clarifies the documentation. To respect the release RFC, we shouldn't introduce a new BC break (breaking behavior with something already released). That's just a ridiculous statement, the release rfc should have been respected in the first place. Can you explain to me where in the RFC it explain that if the new behavior is more correct then a minor release can break BC? This whole story smells like bad PR, this is a new *feature* that breaks BC and not a bug fix. Either way, I don't have a strong opinion on reverting the change or not, but it should be *acknowledged* today that this fix did not belong in 5.3.8. If that's not done, then I have no hope for the future releases from PHP.net I'll look at package maintainers or companies with a more rigorous release process, it's that simple. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.3.8 Released!
On Wed Aug 24 08:42 AM, Pierre Joye wrote: Hi Alan, the breakage is about is_a with a string as 1st argument, not is_a as a whole. So yes, it breaks is_a alone is used as validation. I've been digging more into this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_builtin_fun ctions.c?r1=307522r2=312904pathrev=312904 From what I understand, this patch is only place where is_a() all of sudden starts accepting a string. Btw the documentation has never been updated: http://php.net/manual/en/function.is-a.php It seems unintentional, the patch tries to fix a bug but introduces a new 'feature'. Should it be reverted? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] TameJS syntax for Async/Parallel execution in PHP
On Thu Aug 4 09:54 PM, Raymond Irving wrote:
Hello,
I came across this little library called TameJS (http://tamejs.org/)
and fell in love with the it's syntax. This had me thinking if it was
possible to add such features to a PHP CLI (or web app):
Thanks for sharing, never heard of tame. Love the await{} block
await {
mysql_query_async($sql, $args, defer($rs));
curl_post_async($url,$data, defer($response));
}
$rows = $rs-fetchAll();
What do you think?
I think it would be really interesting rd but likely a large undertaking to
get it to work within php
Also async processing makes a lot of sense of in the client since there's a
lot of idle processing power in the pc (dual core cpu etc..)
If many php processes are executing the same async code (server under load),
I'm not sure you'd get a net benefit.
My opinion, server-side caching is faster and more maintainable.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
On Fri Aug 19 03:48 AM, Kingsquare.nl - Robin Speekenbrink wrote: Also the proposed include it - read the data - convert on write if in previous format (possibly an ini setting?) would provide full BC and would allow a painless upgrade... wouldnt it? 100% against enabling it by default. - still a BC break since some apps in the wild assume serialize($foo) is ascii text (whether that's good or bad). - the default serialize() is readable, easy to debug, doesn't assume you can read binary. PHP is also about simplicity not performance. - igbinary_serialize_double() is not cross-platform so serializing/unserializing a 'float' won't always work http://www.dmh2000.com/cpp/dswap.shtml (2. use a 'union' type to overlay a byte array on top of the data) My preference would be to have: serialize_text()-- ascii text only (standard/var.c) but remove 'NULL' byte (working on a patch for this) serialize_binary() -- igbinary bundled into core... serialize() -- based on php.ini setting, serialize_text by default -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Weak References
On Wed Aug 3 05:16 PM, Lester Caine wrote:
Jan Dolecek wrote:
I was waiting for this for a while! I wrote a blog post how to get
best benefits from weak references:
http://blog.juzna.cz/2011/08/weak-references-in-php/
Perhaps this will help showing people what are they good for.
Or you can use various caching algorithms (LRU, MRU, ..) to reduce memory usage:
$this-cache = new ArrayLimit(2);
$this-cache-add(new LargeObject('A'));
$this-cache-add(new LargeObject('B'));
$this-cache-add(new LargeObject('C'));
$this-cache-count(); // 2
To solve a caching problem weak references aren't very helpful since there's
no way to know when or which objects will be garbage collected
(non-deterministic).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On Fri Jul 22 11:17 AM, Alex Howansky wrote:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
The expected behavior is an E_STRICT notice:
http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/property001.ph
pt?view=markuppathrev=306476
If the modifier is different/conflicting (public, protected, private)
E_FATAL
http://svn.php.net/viewvc?view=revisionrevision=306476
http://marc.info/?l=php-internalsm=129251322332367w=2
The theory is traits should not have conflicting state/properties.
Best practice, always choose trait property names carefully/~unique so that
you don't run into conflicts.
The short answer is it's not a bug but maybe an implementation issue...
should it be an E_WARNING instead of E_STRICT?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On Fri Jul 22 01:46 PM, Alex Howansky wrote:
Sure, but in this case, I created the conflict intentionally because I
*want* to override it, and I'm not allowed to like I am with methods.
Don't you think that's inconsistent?
Agree
The short answer is it's not a bug but maybe an implementation
issue... should it be an E_WARNING instead of E_STRICT?
At least. Consider the situation where I'm using classes/traits from
somebody else's library that I may not be intimately familiar with.
I'll have to know what every one of their properties is named so I can
plan my code accordingly -- else I'll silently start getting their
values in what I think are my variables.
Part of the problem is if you have something like:
trait foo
{
private $zoo = 'important_do_not_modify';
public function showZoo(){
echo $this-zoo;
}
public function doSomething(){
if($this-zoo !== 'important_do_not_modify') die('bad');
}
}
class baz
{
use foo;
private $zoo = 'modified';
}
$obj = new baz();
$obj-bar();
echo $obj-showZoo(); // modified
echo $obj-doSomething();
You can essentially 'break' the trait. So if you think of using someone
else's library/trait, it's not fun either when you break something without
knowing it.
But even then, I'm with you on allowing to change the default property value
in the composing class (I'm in favor of it).
What traits would likely need is:
trait foo
{
trait $zoo = 'important_do_not_modify';
public function doSomething(){
if(trait::$zoo !== 'important_do_not_modify') die('bad');
}
}
So that traits can keep their own private state (Ben Schmidt's idea)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] foreach() for strings
On Wed Jun 22 11:25 AM, Reindl Harald wrote: and php as primary web-language is missing UTF8 support in the core You have a valid point. Now onto foreach() for strings, any other opinions? Seems like the discussion is closed and most likely should move to a RFC with some consideration about character iteration could work. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] foreach() for strings
On Mon Jun 20 09:11 AM, Lee davis wrote:
Could we also use current(), next() and key() for iteration of strings?
$string = 'string';
while ($char = current($string))
{
echo key($string) // Would output the offset position I assume 0,1,2
etc??
echo $char // outputs each letter of string
next($string);
}
Hopefully it can be supported without sacrificing too much performance
Like others mentioned, it seems important to distinguish between binary/byte
and text iteration.
$string = new ByteIterator('string é');
foreach($string as $i = $byte)
...
$string = new TextIterator('string é');
foreach($string as $i = $char)
...
When most developers get a 'string' from a database, my hunch is they assume
they would be iterating over the 'characters' (utf8, iso.. encoding) and not
individual bytes.
So +1 to string iteration as long as there's byte iteration and some plan
for text iteration / by character (with icu or not).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] annotations again
On Tue May 10 11:07 AM, guilhermebla...@gmail.com wrote: I'm not putting traits support inclusion on risk. I'm a string +1 to it. All I want is that you stop giving stupid arguments to be against the patch instead of giving *real* relevant arguments. Complexity: http://en.wikipedia.org/wiki/Enterprise_JavaBean Annotations serve as a good way for application containers to become relevant disguised as developer productivity. I know that whatever I say, you'll continue to support annotations religiously. Calling everyone else arguments stupid is far from a discussion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 again
On Mon May 9 07:29 PM, guilhermebla...@gmail.com wrote:
Hi Andi,
Sorry, but I mentioned on other thread that RFC is outdated.
I just finished an update to it bringing to recent implementation. The
idea is to get the big picture here, I may have left from previous
RFC, but if I did that, please just point out and I can fix.
This implementation is *way* simpler.
Here is the direct link: https://wiki.php.net/rfc/annotations
As for positive feedback, it's a net improvement over the previous RFC and I
like the simplifications.
Is there really a need for:
Array ::= array( ArrayEntry {, ArrayEntry}* )
Do you have examples of where that's needed?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Function proposal: varset
On Wed Apr 20 04:41 PM, D. Dante Lorenso wrote:
My proposal was called filled since it was the opposite of empty
which already existed. I extended the function to return the first
non-empty value or null if all values evaluated as empty.
You could use the function like this:
$x = filled($_GET['x'], $obj-something, $default, 'default');
Like I said, though, I don't think this can be done in the language
because I think they ran out of OPCODES and would have to tear apart
the whole PHP engine to support such a feature.
That's not the reason, there's 127 / 256 opcodes.
So far filled, varset, coallesce, ifsetor or any operator would likely
have to manipulate opcodes.
http://php.net/~helly/ze2-ifsetor-20040901.diff.txt
From what I understand, zeev and andi are strongly opposed to adding a new
opcode. I'm sure they have their reasons.
Maybe there's another approach where ~ E_NONE could be passed to zend_error
ZEND_API void zend_error(int type, const char *format, ...) /* {{{ */
{
if(type E_NONE)
return;
}
Then modify to zend_vm_gen.php to pass E_NONE if within 'ifsetor'.
Either way, there's a solution for it, I think the debate is over how it's
implemented.
-- Worth reading
https://wiki.php.net/rfc/ifsetor#rejected_features
-- Why?
I think it simply boils down to this:
- PHP *developers* want a function for it.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Function proposal: varset
On Wed Apr 20 10:55 AM, Mark wrote:
function varset($arr, $key, $default = '') { return (isset($arr[$key])
? $arr[$key] : $default); }
where the call would be:
$var = varset($_GET, 'var');
I personally like both ways...
My proposal is to make this function a core php function in PHP 5.4.
The added benifit is obvious. People can, with this, use a way shorter
notation to validate if a given array element exists. Right now that
needs to be done with a ternary, filter_var or some other method
(there are quite a few ways to check for existence).
I tried to look in the PHP source to see if i could make a patch to
add this but i couldn't find the function that defines the isset
function (i wanted to base it on that). So a pointer to the right
location would be nice (along with docs that tell me what i all need
to do to implement a new php function).
https://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_parser.y?rev
ision=306938view=markup
Look for isset_variables:, then zend_do_isset_or_isempty
isset() lives in the parser and requires some advanced knowledge of the
opcodes (personally I'm not there yet)
So, what do you think of this?
I like the idea, it could also be called vardef() or var_default()
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Adding a more logical string slicing function to PHP
On Wed Mar 30 09:05 AM, Hannes Landeholm wrote:
var_dump(\substr(foo, 5, 6) == , (string) false, false == );
Welcome to PHP. To be honest this criticism pretty much falls in the
from person that comes from another language X and is annoyed that
every little detail isn't exactly the same-category. Just make your
own substr() function that uses the behavior you expect if you don't
like the native version. Although that's bad practice - the best
solution is to get used to it. And if you have an urge to write about
your experience with a new language I suggest you do it in a blog
instead of posting it in the internals mailing list...
I agree with what you're saying but I think you're being a little harsh,
experience with a new language should be something that matters to
internals.
Back to Dan, you're hitting type conversion so not sure I understand you
always have to deal with this FALSE case:
var_dump(substr('', -1) == '0'); // TRUE
var_dump(substr('', -1) === '0'); // FALSE
Equally to Dan, it doesn't seem like a great way to start the conversation
by saying the interface is inconsistent and confusing.
There's a perception issue here since you're already used to using language
X,Y,Z.
That said the patch seems to add value to php, why not add str_slice() if it
can solve consistency issues for some users? str_slice likely could be a
faster alternative to substr() in userland parsers.
Also I've seen plenty of bugs caused by type conversion substr() in
userland
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Extensions to traits
On Sun Feb 13 05:15 AM, André Rømcke wrote:
I have now made an RFC based on the most recent discussions:
http://wiki.php.net/rfc/traitsmodifications
I think it would sometimes be desirable to allow this, for instance
when a trait has been updated in a framework to adapt to what has
become common practice in classes that uses it in the wild.
( I assume you already get error if function signature is different
like in inheritance? )
So to allow both cases, what about letting people use the final
keyword on functions to signal functions that cannot be re declared
without alias. Or better, add a new keyword since final should mean
final.
I find the implementation in trunk convenient, traits aren't meant to replace
inheritance ~polymorphism.
The 'final' keyword currently means nothing to the class:
trait Foo {
final static function test() {
return 'Test';
}
}
class A {
use Foo;
static function test() {
return 'Test2';
}
}
echo A::test(); // returns 'Test2' in trunk
That might seem odd but it's not inheritance.
There is no error if the class method signature is different from a trait.
I'm comfortable with 'the class always wins', not really sure if should I be
thinking differently...
It makes a trait somewhat fragile but that's part of the design vs. grafts.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Extensions to traits
On Thu Feb 10 12:25 PM, Ben Schmidt wrote:
http://wiki.php.net/rfc/traitsmodifications
Some thoughts:
a) Class method conflict with trait
Class implementation always wins I feel is the right way to think about
traits.
But 'abstract' already has special meaning, so maybe a keyword like 'final'
could also do something special.
b) Support for 'non-breakable traits'
- Add trait-local scope
Really like the idea and how this could make traits less fragile.
e.g.
trait Foo {
trait $bar;
public $bar;
}
Could change the syntax to:
trait Foo {
var $bar = 'visibleByTrait'; // variable private to the trait --
zend_mangle_property_name('#Foo {NULL} bar')
public $bar = 'visibleByClass'; // variable public to the class it gets
composed in
}
class Test {
use Foo;
}
$t = new Test;
echo $t-bar; // 'visibleByClass'
Seems like it could allow traits to have their own independent state
(private properties), internally ~ zend_mangle_property_name('#' trait name
{NULL} prop name).
Small note: is there a plan to drop the T_VAR token?
Any objections, concerns, more thoughts on the concept?
c) Extend 'use' syntax
Didn't quite understand, will read again.
Have you thought about how this could affect the reflection api and
documentation?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Extensions to traits
On Sat Jan 8 06:33 AM, Ben Schmidt wrote: Creating a patch will help getting feedback about what you're proposing http://ca3.php.net/reST/php-src/README.MAILINGLIST_RULES I hope I haven't broken any of the mailing list rules, but my apologies if I have, and please point out specifically where I've gone wrong. No rules broken in my opinion but in general consider: http://www.faqs.org/rfcs/rfc1855.html Over 100 lines is considered long The proposal (473 lines of plain text) would be easier to read on the web with some markup. As far as a patch goes, I don't think that is appropriate at this stage. I don't want to spend a lot of time creating a patch only to have it rejected if this could be avoided by a little discussion. My time is too valuable to me to waste like that, and with something as controversial as this, there's a real danger of that happening. Np, since you mentioned hacking the source I thought you had done some tinkering. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Extensions to traits
On Sun Jan 2 07:16 AM, Ben Schmidt wrote: I would also like to propose some extensions to the functionality as currently described, which I think could potentially add tremendous power to the mechanism, with relatively little additional conceptual complexity and implementation effort. I've written it up as a bit of a proposal below. I'd love to hear what you think. - New ideas are always welcome - Don't write long e-mails to a mailing list, write an RFC http://wiki.php.net/rfc?do=register - Don't overuse the word 'simple' IMHO, if something is simple it should take 1-2 days to create a patch. That doesn't seem to be the case with what you're proposing. But feel free to prove me wrong :) Creating a patch will help getting feedback about what you're proposing http://ca3.php.net/reST/php-src/README.MAILINGLIST_RULES -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Traits and Properties
On Mon Dec 20 06:21 PM, Stefan Marr wrote:
= Handling of Properties/State =
This property handling was implemented in
[[http://svn.php.net/viewvc?view=revisionrevision=306476|SVN revision
306476]] and examples are given in the test cases.
+1
The E_STRICT warning seems to follow nicely the paper's view that a stateful
trait should be its own 'black-box':
http://scg.unibe.ch/archive/papers/Berg07eStatefulTraits.pdf
There are two remaining questions I have:
1) How do traits affect the reflection API?
2) Do we want to be able to declare trait requirements for properties and
methods? If so what syntax?
A note on the syntax proposed by Nathan:
trait require Foo
An option could be:
trait Foo {
require {
public $var;
function ratio();
}
function doFoo($v) {
$this-var = $v * $this-ratio();
}
}
trait Bar {
require interface Iterator;
}
The idea comes from:
http://code.google.com/p/es-lab/wiki/Traits
I found this trying to look for alternative keyword for 'require'.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Traits and Properties
On Sat Dec 18 10:29 AM, Stefan Marr wrote:
At least I do not find an argument for either way that completely
convinces me.
At the moment, the main reason is that 'public' can be considered to
be the default visibility modifier.
Based on the semantics of 'var' and dynamic properties.
Thus, private tends to imply that an additional constraint was
consciously applied to the property, which should be preserved.
Well, but as I said, thats kind of arbitrary and if you look at the
inheritance rules and try to reason from the view of clients with
respect to the external interface, then going with public as the
chosen modifier also starts to sound reasonable...
Does the order of the declaration matter?
trait THello1 {
public $foo;
}
trait THello2 {
private $foo;
}
trait THello3 {
protected $foo;
}
class TraitsTest {
use THello1;
use THello2; // E_NOTICE: TraitTest conflict, THello2(private $foo)
ignored, already declared THello1(public $foo)
use THello3; // E_NOTICE: TraitTest conflict, THello3(protected
$foo) ignored, already declared THello1(public $foo)
}
class TraitsTest2 {
use THello3;
use THello2; // E_NOTICE: ..
use THello1; // E_NOTICE: ..
}
It could be that the first property 'wins' and an E_NOTICE is raised about
the property conflict.
Result:
class TraitsTest {
public $foo;
}
class TraitsTest2 {
protected $foo;
}
It would seem to fit php, though I'd be happy with simply E_FATAL until
people start using traits
The same for:
trait THelloA {
public $foo = 'a';
}
trait THelloB {
public $foo = 'b';
}
class TraitsTest3 {
use THelloA;
use THelloB; // E_NOTICE: TraitTest3 conflict, THelloB(public $foo)
ignored, already declared THelloA(public $foo)
}
class TraitsTest4 {
use THelloB;
use THelloA; // E_NOTICE: TraitTest3 conflict, THelloA(public $foo)
ignored, already declared THelloB(public $foo)
}
class TraitsTest5 {
public $foo = 'c';
use THelloB; // E_NOTICE: TraitTest3 conflict, THelloB(public $foo)
ignored, already declared TraitsTest5(public $foo)
use THelloA; // E_NOTICE: TraitTest3 conflict, THelloA(public $foo)
ignored, already declared THelloB(public $foo)
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Traits and Properties
On Sat Dec 18 12:33 PM, Stefan Marr wrote: Hi Jonathan: On 18 Dec 2010, at 18:14, Jonathan Bond-Caron wrote: Does the order of the declaration matter? No, the order does not matter, and that is one of the key points of traits compared to mixins or Python's way of multiple inheritance. So, any kind of order-dependent solution would be inconsistent with the design of traits. though I'd be happy with simply E_FATAL until people start using traits What do you mean by the second part? (until people start using traits) Changing the design retrospectively does not seem to be the best option? Most likely not the best option, I think I'm saying I prefer E_FATAL But if users find it too restrictive / problematic, the auto-resolution merge to the most restrictive modifier could be added in a next release or an approach that's convenient to the code out there using traits properties. That seems better than the other way around. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Sat Dec 11 10:25 AM, Stefan Marr wrote:
http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
nt_interface
Are there any objections to implementing this?
It's not a bad idea, though I haven't found a strong need for it in the way
I plan to use traits.
It also turns a trait into something more complex 'copy paste' code with
requirements/dependencies.
-1 on using 'require' (T_REQUIRE token), an option could be 'within'
trait IteratorUser within Iterator {
function foo() {
$next = $this-next();
...
}
}
class MyIterator implements Iterator {
with IteratorUser;
}
So the 'with/within' tokens would apply to traits.
Overall I feel -1, more use cases around Trait expresses a requirement for
the composing class would help, it seems like useful theory... not
convinced it's worth the trouble.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Patch: Marking DateTime Instances Immutable
On Sun Dec 5 12:44 PM, Benjamin Eberlei wrote:
1. Just create a DateTimeValue object that is immutable, not
optimizing PHP to handle it with efficient garbage collection.
2. One step further, add a static class DateTimeValue like syntax
that creates an immutable class.
Any ideas?
Some ideas here:
http://www.javalobby.org/articles/immutable/index.jsp
A pattern I've been using is ~
interface Immutable {}
class DateTime_Immutable extends DateTime implements Immutable {
// throw exceptions if attempt to modify...
}
// Get immutable objects...
Objects::getImmutable('Datetime', '2009-01-09'); // returns
(Immutable) new DateTime_Immutable('2009-01-09')
Objects::getImmutable('Datetime', $param1, $param2, ...); // returns
(Immutable) new DateTime_Immutable($param1, $param2, ...)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Thu Dec 2 02:11 AM, Larry Garfield wrote:
See, here's the fundamental problem we're running into. There's three
different definitions of what a property is that we keep bouncing
between, each of which will dictate both syntax and semantics:
1) Properties are a smart masking layer over class members, like a
smarter __get/__set, designed to make it possible to swap out in place
of class members at will. In this case, both the syntax and semantics
of properties should mirror class members as close as possible.
2) Properties are a short-hand for getFoo()/setFoo() methods (which in
the general sense should *not* be understood to always map to class
members, as discussed), designed to make typing $o-getFoo() and $o-
setFoo() shorter/easier. In this case the syntax and semantics
should
make that clear and not confuse the user with class-member-like syntax.
Right, for example:
$tp = new TimePeriod;
$tp-hours = 2;
foreach($tp as $prop = $val)
Would this be an empty loop? That seems to be what the RFC proposes (2)
layer of syntactic sugar over a pair of methods.
If a property is to provide the (1) illusion of a variable (~class
member), IMHO it provides a clear benefit over the __get(), __set() methods.
In the spirit of (1):
class Audit_Entry {
public $info;
public $timeAdded { // illusion of a variable, removed 'public property'
to avoid confusion
get {
return $this-_timeAdded;
}
isset {
return isset($this-_timeAdded);
}
};
protected $_timeAdded; // Datetime
function __get($prop)
{
// virtual properties, these are not class members
}
}
In the spirit of (2), it seems like we would have two ways of doing the same
thing.
It would probably be a good idea to deprecate __get(), __set()... in favor
of the C# style
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
On Tue Nov 30 03:26 AM, Julien Pauli wrote:
I guess serialize mechanism cant use any char that can be part of a
PHP variable. And _ can. As property names respect binary
compatibility, the only char that can be used to mark private
properties is actually the NULL byte. Ping me if I'm wrong.
Right, what I was proposing didn't make sense. After digging through the
source, say we have:
class Foo {
public $a = 1;
protected $b = 2;
private $c = 3;
}
Currently this is:
O:3:Foo:3:{s:1:a;i:1;s:4:�*�b;i:2;s:6:�Foo�c;i:3;}
An alternative could be:
O:3:Foo:3:{s:1:a;i:1;*;s:4:b;i:2;_;s:6:c;i:3;}
Where *; is a marker for protected, _; is a marker for private
It would involve some trickery in ext/standard/var_unserializer.re :
*;{
/* prepend �*� to the next key so that we have zend_symtable_find(�*�b)
*/
}
_;{
/* prepend �Foo� to the next key so that we have
zend_symtable_find(�Foo�c) */
}
Just a thought if someone wants to refactor it / look into performance, I
believe that approach would support both:
O:3:Foo:3:{s:1:a;i:1;*;s:4:b;i:2;_;s:6:c;i:3;}
O:3:Foo:3:{s:1:a;i:1;s:4:�*�b;i:2;s:6:�Foo�c;i:3;}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Mon Nov 29 09:27 AM, Stas Malyshev wrote:
Hi!
Nice RFC, just an idea for an alternative syntax (added to the RFC
as
#2):
property Hours {
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; } // The variable $value
holds
the incoming value to be set
}
class TimePeriod
{
private $seconds;
public [Hours] $hours1;
public {use Hours;} $hours2;
}
If you change property to class or trait and get to __get
you need almost no new syntax :)
Right, it looks the same but the subtle difference is 'property Hours'
wouldn't be registered as a class. It's just container code for get(), set()
methods that would get 'compiled' into opcodes in the class TimePeriod (the
property exists vs. searching for it in runtime). So you can think of it as
a special 'trait' that only applies to properties.
The idea behind this syntax is you can move the 'property' definition out of
the class so that you can test and re-use it somewhere else (like traits).
That might not be problem if you can define properties in traits (needs to
be explained in the RFC):
trait TimeUnits {
public property Seconds
{
get { return $this-seconds; }
set { $this-seconds = $value; }// The variable $value holds the
incoming value to be set
}
public property Minutes
{
get { return $this-seconds / 60; }
set { $this-seconds = $value * 60; }
}
public property Hours
{
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; }// The variable $value holds
the incoming value to be set
}
}
class MyTime {
uses TimeUnits;
protected $_seconds;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
On Thu Nov 25 12:47 PM, Andi Gutmans wrote: I know there have been some high-end apps that have benefited from some custom serializers, etc... (typically platform dependent). I wonder if people here think improvements in these areas would move the needle for the majority of mainstream apps or not. Like people have mentioned, improving (un)serialize speed would be a huge benefit, especially for caching data sets or large objects. From experience, it would seem valuable to have: 1) serialize_text($var) The existing serialize() minus the NULL bytes on private properties. It has been a source problems for developers serializing an object with private properties and storing it in a database (the string may get cutoff). I'm not sure why there's a NULL byte in 'zend_mangle_property_name', instead the char _ could be used to mark a private property in the serialized text. The unserialize could be BC compatible accepting both NULL and _ around a private property. 2) serialize_binary($var) An efficient and compact serialization using techniques from igbinary. A potential problem with igbinary I've noticed is it packs a double as a 64 bit integer. That could be a problem if you serialize on a platform that has an IEEE 754 binary representation and unserialize on a non-IEEE platform but I don't know if php compiles on architectures that are non-IEEE. It could also be interesting to pack integers as varints: http://code.google.com/apis/protocolbuffers/docs/encoding.html#varints http://protobuf-c.googlecode.com/svn/trunk/src/google/protobuf-c/protobuf-c. c That's most likely slower though then what igbinary does with integers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On Thu Nov 18 08:34 AM, guilhermebla...@gmail.com wrote: Hi Larry, For existent project examples and usage, here are 2 links of the upcoming versions of Doctrine 2 and Symfony 2: http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic- mapping/en#introduction-to-docblock-annotations http://docs.symfony-reloaded.org/guides/validator.html Please understand that Roman, Benjamin, Jonathan and I wrote this Annotation parser for Doctrine, which was reused by Bernhard on Symfony. So I have clean understanding of the issue we have on hands and every single point that it is required to address. That's why I wrote the RFC. I'm really confused about the issue, no objections have been made for a docblock parser for annotations. That can easily live as PECL extension, Doctrine ORM mapping can done in XML, YAML, docblock annotations,... symphony validation in XML, YAML, docblock annotations, ...? Why is it such a persistent *issue* to have language level annotations? Because people want their decorative data around class properties? Java developers who want their hibernate? For uses cases in java (annotations as hints to the compiler): http://video.google.com/videoplay?docid=-1531727105949862857# Does this even apply to php? Hints to the parser? Optimizations? I'll say it again, I'm not against annotations but copying java and its mistakes is not the way to go. Remember that vendors (oracle, bea,...) love annotations to sell their tools, in orm hibernate won. Please improve the RFC to address php-specific problems Now, I'm going to go back and listen to that song sugar, sugar by the archies -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PDO_DBLIB Native PHP Type binding
On Fri Nov 5 12:57 AM, Stanley Sufficool wrote: And why is PHP client library using latin1 for data that just isn't latin1? That's just asking for problems... Theoretically I could ask for UTF8, but then I don't want to have to run utf8_decode/utf8_encode on all query strings, returned data, etc when the other drivers do not return unicode to PHP. Have a look at: https://open-mv.googlecode.com/svn/trunk/classes/database/drivers/ I've solved most of these problems though not with PDO* drivers. I think you'll get the consistency you need for 2 interchangeable and have PHP/PDO applications run the same on Win32 and Linux only minus the PDO/PDO_DBLIB part. In my opinion, PDO already does too much abstraction magic, it would be great if PDO2? could expose somehow: static inline void fetch_value() so that in userland you could deal with custom data types and override how the data type bindings happen. That would be some much needed flexibility to actually create a database abstraction layer vs the pdo data-access layer. My only answer to that is to change your code to not ask for 'latin1' in the first place, when the data isn't latin1. Change the PHP client charset to what it ought to be, and get the data you wanted, not some lossy down-sampled useless conversion of the data you wanted. I cannot comment on SQL Server behaviour with respect to the servers code page [sic], whatever that is, except to say that MySQL lets you define your charset on a table by table basis, and, I think, in recent versions, even on a field by field basis. OpenSource ftw, perhaps? :- ) MSSQL allows per table and per column code pages in recent versions. As far as OpenSource DBMS', I support what my clients run, not what I want them to run. If I had my choice, I would be running PostgreSQL. Per column code pages / collation is actually part of SQL92 (postgresql doesn't support it, mysql, mssql,.. does) In windows, the SQL native driver will properly convert everything to UTF-8. In unix, FreeTDS should do the conversion correctly, have you run into problems? Is this related to the PDO driver? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] On how a little knowledge is completely useless.
On Fri Sep 17 03:13 PM, Ralph Schindler wrote: Inline response: On 9/17/10 1:57 PM, Jonathan Bond-Caron wrote: On Fri Sep 17 01:06 PM, Guilherme Blanco wrote: Another good example is to map your persistence data into your Entities. Doctrine 2 implements this and I think that way you can compare easily with the PHP code alternative. I'd like to ask you to compate the same Entity mapped through Annotations emulator and using raw PHP code: CmsUser using Annotations: http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests / M odels/CMS/CmsUser.php CmsUser using PHP code: http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests / O RM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php You're basically bundling (M: Model, data configuration, C: Control, business logic / code) into a single class while the MVC pattern is all about separating M,V and C. Jonathan, I think you are misinterpreting this code. There is no Controller (Front controller, or parameter mapping from $_POST or $_GET) nor View responsibilities (echo) here. These are all Model concerns: I'm not talking about web mvc and mapping urls to controllers. There's another pattern where you have a controller (php class) and a data model (sql schema, .xsd, ...) Problem statement: How do I map class properties to a given data model (sql schema, .xsd, ...)? Some believe (strong opinions) that using annotations to do this is not a good example, though abundant usage in java. It would better serve the discussion if good and bad was left out and if annotations were presented and promoted in a more neutral way. If we take a more fun example, how is a swiss army knife useful? - It can be used to open cans of food. - It can be used to cut hair. - It can be used to shave in the morning. ... I have full faith in the ability of core developers to make their own opinions on how annotations can be useful to the php community at large. There are more things to be considered then technical arguments. The bigger emerging problem is the complete lack of formal process to propose changes to php's syntax: a) How to write a proposal to be accepted for review b) How and by who the proposal will be reviewed c) Who makes the final decision (e.g. executive committee) to approve or reject a proposal. Going back to annotations, the discussions seems to be bouncing from (a) to (c) while it seems like we are still at (a). I've been following internals only for the past couple of years and I don't know enough the history but it seems like it would be time to write a document that defines a formal process to propose syntax changes (Zend/zend_language_parser.y, ...?) I'm more than willing to start writing a draft, e.g. a much simplified version of: http://jcp.org/en/procedures/jcp2 Is this worth a try? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] On how a little knowledge is completely useless.
On Fri Sep 17 01:06 PM, Guilherme Blanco wrote: Another good example is to map your persistence data into your Entities. Doctrine 2 implements this and I think that way you can compare easily with the PHP code alternative. I'd like to ask you to compate the same Entity mapped through Annotations emulator and using raw PHP code: CmsUser using Annotations: http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ M odels/CMS/CmsUser.php CmsUser using PHP code: http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ O RM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php You're basically bundling (M: Model, data configuration, C: Control, business logic / code) into a single class while the MVC pattern is all about separating M,V and C. What's wrong with a simple configuration file? Caching the parsed config in shared memory? One important flaw rarely mentioned with annotations config: your code now depends on framework X to read the annotations instead of a simple configuration file (.xml, .ini., ...) Sorry if I might sound harsh but configuration through annotations is terrible. You'll find many .net or java developers that agree, I'd say it's 50-50 if not more 70-30. Does this discussion still belong in internals? We could argue about this for months, java astronauts don't even agree how annotations are useful: http://www.javaworld.com/community/node/2613 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PHP Annotations RFC + Patch
-1 for the proposed Annotations concept and associated syntax +1 for adding APIs to parse doc blocks, minor note: should not be not called getAnnotations On Thu Sep 16 01:01 PM, Lars Schultz wrote: +1 for adding APIs to parse doc blocks -1 for introducing a new Annotations concept and associated syntax -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PHP Annotations RFC + Patch
On Thu Sep 16 02:44 PM, Stas Malyshev wrote: WTF is Annotations? We didn't define it yet. Should PHP support http://en.wikipedia.org/wiki/.NET_metadata http://blogs.msdn.com/b/efdesign/archive/2010/03/30/data-annotations-in-the-entity-framework-and-code-first.aspx .NET calls this attributes but Sun invented the annotations concept in 2002: http://www.google.com/patents/about?id=TXZ4EBAJ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
On Wed Sep 15 12:17 PM, Guilherme Blanco wrote: I think meta programming is not and would never be part of comment. As previously said, docblock means documentation, without any meaning to parser, entirely human readable and totally removable without affecting overall execution. I have to agree here, there's lots of php tools that 'strip comments'. If you strip comments, you'd be effectively removing 'annotations' which changes how that code would run in a given framework or tool. It kind of defeats the purpose. But my opinion as an end user and framework developer: the rfc really needs to elaborate on the use cases *specific to php* java has some here: http://jcp.org/en/jsr/detail?id=250 Does php need to be become this complicated? I worry about how php can grow complicated to a point where you won't be able to use it without using tool or framework X. I'll use .NET, thank you very much. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
On Tue Sep 14 01:25 PM, Nate Abele wrote:
Sorry, but I don't see how this is even remotely close to being
appropriate for PHP. Maybe I'm missing something. :-)
I agree, the use cases are just not there
Though maybe some form of annotations could be useful in php as a
pluggable type:
http://bartoszmilewski.wordpress.com/2009/01/18/java-pluggable-types/
But this isn't an annotation as just plain metadata, the parser could do
something with the annotation.
i.e.
class Phone {
@ReadOnly
public $id;
@PhoneNumber
public $number;
}
class PhoneNumber implements TypeAnnotation {
static function getTypeValue($val)
{
return preg_replace('~[^0-9]~', '', $val);
}
}
Instead of ~
class Phone {
protected $_number;
function __get($prop) {
if($prop === 'number')
return $this-_number;
}
function __set($prop, $val) {
if($prop === 'number')
$this-_number = preg_replace('~[^0-9]~', '', $val);
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] inheritance check too strict?
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
No it's wrong.
A Child is a Parent so we must be able to pass a Parent to the method
equals() defined on Child.
The declaration of the parent functions must always be valid in the
children.
Maybe my OO theory is wrong but I was under the impression that the only way to
enforce a signature is using an abstract class or interface?
php allows it:
PHP 5.2.13 with Suhosin-Patch 0.9.7 (cli) (built: Aug 14 2010 16:39:00)
PHP 5.3.99-dev (cli) (built: Aug 20 2010 07:45:44)
?php
class P { function dot(Child $o) { echo .; } }
class Child extends P { function dot(P $o) { echo .; } }
$t = new Child;
$t-dot( new P );
$t-dot( new Child );
class P2 { function dot (P2 $o) { echo .; } }
class Child2 extends P2 { function dot(Child $o) { echo .; } }
$t = new Child;
$t-dot( new P );
$t-dot( new Child );
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] inheritance check too strict?
On Fri Aug 20 08:24 AM, Nathan Rixham wrote:
Jonathan Bond-Caron wrote:
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
No it's wrong.
A Child is a Parent so we must be able to pass a Parent to the
method
equals() defined on Child.
The declaration of the parent functions must always be valid in the
children.
Maybe my OO theory is wrong but I was under the impression that the
only way to enforce a signature is using an abstract class or
interface?
php allows it:
PHP 5.2.13 with Suhosin-Patch 0.9.7 (cli) (built: Aug 14 2010
16:39:00)
PHP 5.3.99-dev (cli) (built: Aug 20 2010 07:45:44)
?php
class P { function dot(Child $o) { echo .; } } class Child
extends
P { function dot(P $o) { echo .; } }
$t = new Child;
$t-dot( new P );
$t-dot( new Child );
class P2 { function dot (P2 $o) { echo .; } } class Child2
extends P2 { function dot(Child $o) { echo .; } }
$t = new Child;
$t-dot( new P );
$t-dot( new Child );
?
perhaps you mean..
$t = new Child2;
$t-dot( new P2 );
$t-dot( new Child2 );
Oops, thanks :)
Maybe Stas can comment but I can't reproduce the E_STRICT warning
Is this php HEAD?
class ObjParent {
function set($param2 = '') {}
}
class ObjChild extends ObjParent {
function set(){ echo .; }
}
$o = new ObjChild;
$o-set(); // runtime E_STRICT warning?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] inheritance check too strict?
On Fri Aug 20 09:10 AM, Jonathan Bond-Caron wrote:
Maybe Stas can comment but I can't reproduce the E_STRICT warning Is
this php HEAD?
class ObjParent {
function set($param2 = '') {}
}
class ObjChild extends ObjParent {
function set(){ echo .; }
}
My mistake,
Strict Standards: Declaration of ObjChild::set() should be compatible with that
of ObjParent::set()
I'll let the strict vs loose php battle this one out :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
On Tue Aug 10 07:42 PM, Josh Davis wrote: Derick's point was about consistency. The approach described in his mail is consistent with current syntax and mechanism(s). Current typehints do not apply any kind of conversion, so treating scalar hints the same way is consistent with the current mechanism. It's only consistent in the function declarations but *completely* inconsistent with how the rest of the language works. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Zend Extension - zend_compile_file - interoperability?
I've starting playing around with the zend engine,
is there any hope / plans for better interoperability with how
zend_compile_file() should be extended?
The goal being to reduce the amount of X is not compatible with Y.
It would be possible to separate extensions in two categories and provide
hooks (without breaking BC):
# Bytecode loaders / optimizers / dumpers (zend optimizer, ioncube loader,
vld, etc.)
HOOKS: zend_compile_file, zend_compile_string, zend_execute
# Bytecode cache (apc, xcache, etc.)
HOOKS: zend_opc_get, zend_opc_put
Internally (Zend/zend.c, ext/phar/phar.c, ext/spl/php_spl.c, etc..) use
zend_opc_compile_file() ~
zend_op_array * opc _compile_file(zend_file_handle *file_handle, int
lifetime, int type TSRMLS_DC)
{
zend_op_array *retval=NULL;
if( zend_opc_get(file_handle-filename, retval) )
return retval;
retval = zend_compile_file(file_handle, type);
zend_opc_put(file_handle-filename, lifetime, retval);
return retval;
}
zend_opc_get() and zend_opc_put() would just be stub functions that do
nothing, op code caches would change these methods
If there's positive feedback, I can turn this into a RFC and put more work
into it
RE: [PHP-DEV] Remove sqlite2 from trunk
On Wed Jun 16 07:04 AM, Ilia Alshanetsky wrote: drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. I'm all for starting to use sqlite3 but I found two issues with the migration to the new api: a) sqlite_busy_timeout is not available in sqlite3.c This is important for an application to return a failure right away instead of wait for locks to be release. The patch looks simple since it's a wrapper for SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms); b) No persistent connections Any reason why it wasn't migrated from sqlite.c? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting
On Thu May 27 11:22 AM, David Soria Parra wrote:
On 2010-05-27, Zeev Suraski z...@zend.com wrote:
+1 from me for this. I think two solutions is not the right way and we
+should
try to make the type system consistent for the user. Therefore +1 for
auto-converting.
I still feel the debate of the right way is still open, say I have the
following class:
class Tax {
/**
* Apply a tax rate or {...@link getRatesApply() tax rates} to a given
amount and get the total tax.
*
* @param string|float$amount
* @param string|float|array $rates Tax rate or an array of tax
rates
* @param int $precision Rounding precision
*
* @return string
*/
static function apply($amount, $rates, $precision = 2) {}
}
Strict typing would allow:
static function apply($amount, $rates, int $precision = 2) {}
Type hinting would allow:
static function apply(string $amount, $rates, int $precision = 2) {}
This is far from consistent to the user, the syntax is identical to *strict
typing* in many (if not all) dynamic programming languages.
I would much prefer to see a 'type hint' where magical conversion happens
as:
static function apply((string) $amount, $rates, (int) $precision = 2) {}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Traits
On Mon Apr 12 05:16 AM, Stefan Marr wrote:
On 12 Apr 2010, at 10:39, Lukas Kahwe Smith wrote:
On 12.04.2010, at 10:34, Derick Rethans wrote:
Hi!
But just as a quick response, without aliasing, there would be no way
to use a conflicting method from a trait.
On first sight, that is not a really good thing.
Hi Stefan, is it possible to have renaming and aliasing?
Some context, say we have:
trait Something {
function renameIssue() {
$method = 'call';
$this-$method();
call_user_func(array($this, $method));
}
function call () {
echo a;
}
}
class Foo {
use Something {
function call() as call2();
}
}
With renaming:
$f = new Foo;
$f-call2();// a
$f-renameIssue(); // call() method does not exist
With aliasing:
$f = new Foo;
$f-call(); // a
$f-call2();// a
$f-renameIssue(); // a
While aliasing prevents the error, the syntax could re-use the 'clone'
keyword:
class Foo {
use Something {
function call() clone call2();
}
}
So we'd have both behaviors:
class Foo {
use Something {
function call() as call2();
function call() clone call3();
}
}
We have call(), call2(), call3()
class Foo {
use Something {
function call() as call2();
}
}
We have call2()
Other than that, the traits proposal still feels incomplete compared to
grafts since from Stefan's research: the lack of state means that virtually
all traits are incomplete
It's still a great step if the current proposal (methods only) gets
committed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] horizontal reuse: traits vs. grafts
On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
Ahoi,
Thought it would be better to open up a new thread and also using the
term horizontal reuse in the subject so that we make it clearer that
there are actually two approaches. Here is the URL for Stefan's
proposal:
http://wiki.php.net/rfc/horizontalreuse
One thing I feel is missing from the RFC is how is_a() and instanceof are
affected with traits or grafts.
From:
http://github.com/gron/php-src/blob/PHP_5_3-traits/Zend/tests/traits/languag
e009.phpt
class Foo {
use C, A, B {
B::foo instead A, C;
}
}
$f = new Foo;
echo is_a($f, 'A'); ?
echo is_a($f, 'B'); ?
It's seem to me that a defining a 'trait' should be advertised strictly as
an 'advanced multiple inheritance technique' to reuse pieces of code and it
shouldn't be considered as an object (grafts proposal).
I don't like the B::foo instead A, C stuff though, so I agree with Lukas
and find that Grafts are more intuitive / easy to learn.
Personally, this syntax makes me happy but would keep the 'use' or 'with'
keyword:
http://wiki.php.net/rfc/nonbreakabletraits
trait A {
protected function foo() {
echo 'a';
}
}
trait D {
public function foo() { echo d; }
function bar() { echo d; }
}
class Foo {
use A;
use D {
function bar();
}
}
$f = new Foo;
echo is_a($f, 'A'); // true
echo is_a($f, 'D'); // false, since we've done an explicit
selection/brackets: use D {}
This is mainly userland feedback
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] horizontal reuse: traits vs. grafts
On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
The third sentence is not so clear to me, but if I guess it its also
just a typo as it makes more sense to me when replacing renaming to
result in renaming. But maybe you could tweak that paragraph to be a
bit clearer. For example its still not totally clear to me why
aliasing doesn't imply inclusion, I guess its definitely more
flexible.
It was really unclear to me too, this example cleared it up:
http://github.com/gron/php-src/blob/PHP_5_3-traits/Zend/tests/traits/bugs/al
ias-semantics.phpt
The current trait implementation does not 'rename' the previous method but
creates an 'alias'.
class Talker {
use A, B {
B::smallTalk instead A;
A::bigTalk instead B;
B::smallTalk as talk;
}
}
I think in this case, it would output 'A'.
Personally I would prefer to see:
class Talker {
use A {
public function bigTalk();
}
use B {
public function smallTalk();
public function smallTalk() as talk(); // this 'renames' the function /
not an alias
}
}
Other example:
class Talker {
use A;
use B {
public function smallTalk() as talk();
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On Wed Oct 14 04:07 PM, Lukas Kahwe Smith wrote:
On 14.10.2009, at 22:03, Stanislav Malyshev wrote:
Hi!
So lets warm this up again.
HEAD is for development .. so lets get this into HEAD so that it
will be part of the next bigger PHP release for sure!
Well, the code is sitting here
http://github.com/gron/php-src/tree/PHP_6-traits
and waits to be merged. :)
I thought before merging code it would be useful to have some
discussion on if the code is actually doing what we want. If it's
based on http://wiki.php.net/rfc/horizontalreuse then for example I
can see some potential issues for bytecode caching related to
renaming
and changing visibility.
Also, it is not clear that we want grafts there at all, some aspects
of them seem to get too hairy, esp. $this issue or statics.
i think Stefan is fully aware of that probably there will be a
discussion first ..
but i think we all agree that this feature is very high on the list of
what people want and therefore i wanted to get this discussion going,
so that after its concluded traits can be commited to HEAD.
Has it been discussed to add a portion of the patch to HEAD?
Reading up on scala, I really like what they've done with traits (as a
developer):
http://www.scala-lang.org/node/117
I've updated the RFC with an example:
http://wiki.php.net/rfc/traits#scala_synthax_and_practical_example
Hopefully, people can agree on a simple patch that ignores conflict
resolution / aliasing solution and just adds:
trait User_Comments {}
class App_Document with User_Comments {}
// Or the original syntax
class App_Email {
use User_Comments;
}
The details of conflict resolution, if the use cases are strong enough can
come later.
Grafts well... the re-use is interesting but I worry about how php is going
to evolve is you start offering that much flexibility.
Just my thoughts, great work though.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Flexible type hinting
On Thu Jul 2 08:53 AM, Paul Biggar wrote: On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetskyi...@ilia.ws wrote: On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: I think you might not have read what I suggested (it is different than the one I emailed to you privately). What you want is fully supported. If you must be passed an int, use the +int hint. I'd rather use -int, then +int and make people who want loose typing do the extra bit, because native typing should be strict. I think everyone wants their favourite to be default. I was eager to have the typing that's currently in the manual be the default, since that's what people are used to seeing. I suggested that strong type checks use +int exactly because that's different to what's in the manual, so there would be no confusion. I'm really looking to get people to agree to the principle that we would like to be able to hint every signature without large changes to the manual, since we've been looking at it for years. From userland, I'm a big fan of this proposal / agree to the principle although I'm not convinced that function($quantity) function(int $quantity) function(+int $quantity) function(-int $quantity) looks appropriate... Userland Note: The -int semantics confuses me, I realize it would cast null's etc... but is it really a requirement? Can it be dropped? function($quantity) function(int $quantity) paul's (S) casting function(int! $quantity) STRICT type --- seems appropriate for php, follows CSS/web style '!important' To me, strict as default doesn't seem appropriate in php. But if it does, this syntax could be interesting: function($quantity) function(int $quantity) STRICT type function(~int $quantity) paul's (S) casting Btw, really interesting discussions -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Stream chunk size
On Mon Mar 2 11:10 PM, Andi Gutmans wrote: I don't see a fundamental issue why it could not be arbitrary. The only challenge which may be an issue is that this code clearly allocates the buffer on the stack for what are probably performance reasons. If you allow arbitrary chunk size and use alloca() (do_alloca()) for stack allocation you might kill the stack. I suggest you do some performance tests and if you need to keep it on the stack then create some arbitrary limit like 8K and use stack below that and use heap above that (code will be uglier). Thanks for the tips, it's on a todo list -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Stream chunk size
Hi everyone, I have a question about streams and the maximum chunk size of
8192.
Ive read README.STREAMS and found these slides by Wez:
http://netevil.org/blog/2008/07/slides-php-streams
While trying to write an Amazon S3 stream wrapper and I ran into an issue
with large files:
$fp = fopen('s3://mvtest/large.html', 'r'); // 30 mb
// This is OK
fseek($fp, 10);
echo fread($fp, 100) . \n; // 100 bytes
echo fread($fp, 100) . \n; // 100 bytes
// This is OK (according to documentation, max 8192 bytes)
echo fread($fp, 65536) . \n; // 8192 bytes
My issue is I would like to request larger chunks, something like:
stream_set_chunk_size($fp, 65536);
echo fread($fp, 65536) . \n; // 65536 bytes
echo fread($fp, 10) . \n; // 65536 bytes
echo fread($fp, 15) . \n; // 15 bytes
Then copying to a file and avoiding memory issues:
$wfp = fopen(/tmp/large.html);
stream_copy_to_stream($fp, $wfp); // read 65536 byte chunks, write default
8192 byte chunks
stream_set_chunk_size($wfp, 65536);
stream_copy_to_stream($fp, $wfp); // read write 65536 byte chunks
copy('s3://mvtest/large.html', '/tmp/large.html'); // read write default
8192 byte chunks
Going through the PHP 5.2 source, it looks like theres support for it but
at some places the 8192 chunk is hardcoded:
#define CHUNK_SIZE 8192
PHPAPI size_t _php_stream_copy_to_stream(php_stream *src, php_stream *dest,
size_t maxlen STREAMS_DC TSRMLS_DC)
{
char buf[CHUNK_SIZE]; ß Is there any reason the php_stream
*src-chunk_size isnt used?
stream_set_chunk_size($fp, 65536); // Would mean src-chunk_size = 65536;
Id like to try to write a patch for it, anything that I should know about
streams and why the limit is there?
RE: [PHP-DEV] Upgrading to internal DateTime
On Sat Dec 6 12:09 AM, Lester Caine wrote:
Derick Rethans wrote:
( Slipping a date through DateTime and returning it DATE_W3C seems
to
be adding the correct daylight saving details so far and allowing
ADOdb date to work )
This is not the correct thing to do, as you will lose timezone
information. The W3C format only stores UTC offsets (in the form of
+00:00). However, that same UTC offset can be used in different
+areas
with different DST changes. Best thing is to store in Unix
timestamps.
Timezones are a pain :)
OK - I think I understand what is 'missing' now!
The only thing ever stored in the database *IS* Unix timestamps. Doing
anything other than that is unmanageable, yet some frameworks use
'server based' times in their systems, simply because they do not
bother with daylight saving and only 'serve' one timezone!
Not sure I understood this, especially unmanageable. The important part is
to be consistent.
Unix timestamps are useful because they in UTC.
But there is nothing wrong with storing only ISO dates in a database.
Consider these examples:
// Datetime parsed as GMT
date_default_timezone_set('GMT');
$d = new Datetime('2008-06-05 00:00:00');
echo $d-format('U e c'); // 1212624000 'GMT'
// Timestamp parsed as GMT
date_default_timezone_set('America/Montreal');
$d = new Datetime('@1212624000');
echo $d-format('U e c'); // 1212624000 'America/Montreal' --
shouldn't this be UTC?
// Datetime parsed as GMT
date_default_timezone_set('America/Montreal');
$d = new Datetime('2008-06-05 00:00:00', new DatetimeZone('GMT'));
echo $d-format('U e c'); // 1212624000 'UTC' -- not GMT?
// Datetime parsed as 'America/Montreal'
$d = new Datetime('2008-06-05 00:00:00', new
DatetimeZone('America/Montreal'));
echo $d-format('U e c'); // 1212638400 'America/Montreal'
** can any php dev answer the -- questions?
Personally, I prefer storing all dates in a database in a given timezone
(i.e. 'America/Montreal')
It's convenient and easy to read. The big drawback is it needs to clearly
documented that all dates in the database are in this timezone and must be
converted when a) parsing user datetime b) displaying user datetime
i.e.
// From user input to database
$dbDate = new Custom_Datetime($_POST['userDate'], new
DatetimeZone($_POST['userTz']));
$dbDate-setTimeZone('America/Montreal'); // for storing to database
// From database to user
$userDate = new Custom_Datetime($dbDate, new
DatetimeZone('America/Montreal'));
$userDate-setTimeZone($userTz); // to display date in user's timezone
Unix timestamps are simpler since you know they are always in UTC.
Just thought I'd raise that there's nothing wrong with storing all dates as
ISO in a given timezone. It takes a little more work but if your consistent,
it can managed.
If I'm wrong, please let me know :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] quick polls for 5.3
On Wed Nov 12 02:14 PM, Lukas Kahwe Smith wrote: 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC I) enable ext/hash by default +1 II) remove ext/mhash 0 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ +1 3) resource constants (choose one) c 4) keep ext/phar enabled by default in 5.3? +1 5) keep ext/sqlite3 enabled by default in 5.3? 0 6) enable mysqlnd by default in 5.3? (answer both) -1 both: would favor mysql by including client in default installation 7) should Output buffering rewrite MFH? this one comes with some 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so 0 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP mixin RFC
Hi Everyone, I've started a new RFC about PHP and mixins: http://wiki.php.net/rfc/mixin Stefan has done some really interesting research with traits though I'm concerned about how intuitive it is. Good summary of how mixins and traits deal with conflict here: http://marc.info/?l=php-internals http://marc.info/?l=php-internalsm=120337784031746w=2 m=120337784031746w=2 Note: the rfc proposes to *not to* override any already defined methods.
RE: [PHP-DEV] [RFC] [PATCH] Rounding in PHP
On Thu Aug 28 01:47 PM, Christian Seiler wrote: Hi again, A few weeks ago I wrote quite a long posting to internals@ that tried to clarify the situation on the round() function in PHP. I was asked to write it up as an RFC in the wiki, which I have done: http://wiki.php.net/rfc/rounding Since there has been no reaction so far to my proposal (besides the help from Hannes and Pierre for the Win32 build dependencies, thanks for that btw.), I'd like to know why? Am I talking gibberish and my proposal is hard to understand? Or have I simply chosen a topic that many do not consider worthwhile investing that amount of energy into? Or is it something else? For the record, I was very excited to see your proposal and the work you've done. I'm not a PHP dev so I can't comment on the patch, maybe there might be a performance concern? I don't know either the history of the 'rounding fuzz', but there's definitely space for improvement... The problem naturally isn't with floats but that the round() function is very misleading. My opinion is the rounding precision should be removed or fixed since it doesn't work as expected. i.e. javascript, there's no precision: Math.round() Nevertheless, what could be discussed separately is the introduction of a new type that automatically uses an arbitrary precision library internally, since writing $a * $b is much more natural than e.g. bcmul($a, $b). This, however, goes far beyond the scope of this proposal. I'm all for this... maybe something like this: // within some 'numeric' precision $a = (numeric)2; $b = (numeric)0.5; $mult = $a * $b; echo $mult;// 1 (numeric) echo (2.5 == $a + $b); // true echo (2.5 === $a + $b); // false echo ((numeric)2.5 === $a + $b); // true -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] TracingPHP
On Mon Aug 25 06:28 PM, steve wrote: Has anyone had success compiling PHP with LLVM? I haven't tried it, here is a good summary: http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf In short, it is 'slower' but that seems to be without any caching of the bytecode Bytecode is not opcode: http://www.santosj.name/general/computers/byte-code-vs-op-code/ Right now, the most effective strategy to optimize php is executing opcodes using an opcode cache such as APC (facebook others use this). That's from my research, maybe someone can correct me here. Isn't using something like Zend Guard (converts code into opcode) then caching the opcodes essentially JIT? Even if opcode is not binary, it's still a fast intermediate form that gets translated into machine binary, isn't that JIT? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Short syntax for array literals [...]
It's a big +1 for me and this sums it up PHP is about building on the knowledge and experience of the typical target user. This target user changes slowly as we all get older and the industry we are in changes and we need to recognize that and adapt the language appropriately. What is appropriate is of course a really hard call which is what this is all about. My first concern about the [] debate is no one is really asking what the users want? Where did the [] requirement or proposal come from? There's no doubt in my mind that a [] synthax is something most users would want. The similar array declaration to javascript also further reinforces the use of PHP for web based programming. Finally, having a public voting system would definitely help gain more insight as to what users want. -- 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] magic quotes finale
+1 here A summary: PHP6 MUST not allow setting magic quotes PHP6 MUST trigger a fatal error when attempting to set magic quotes (php.ini or set_magic_quotes_runtime()) PHP6 MUST allow getting magic quotes info (always false) PHP5.3 MUST allow setting magic quotes PHP5.3 MUST trigger an E_DEPRECATED warning when setting magic quotes (php.ini or set_magic_quotes_runtime()) PHP5.3 MUST allow getting magic quotes info -Original Message- From: Philip Olson [mailto:[EMAIL PROTECTED] Sent: May 20, 2008 3:56 PM To: PHP internals Subject: [PHP-DEV] magic quotes finale Hello everyone- PHP 5.3 is approaching fast, so let's conclude our dealings with magical quotes... this should be the last time. Please have a look at the following RFC and discuss it within this thread. Magic Quotes in PHP 5.3 and beyond - http://wiki.php.net/rfc/magicquotes It recommends changes to both 5_3 and 6_0 branches, namely, removing E_DEPRECATED from the get_ magical quote functions. Silence means you're okay with the RFC being implemented. Regards, Philip -- 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] Float comparison
Thanks for all the feedback, My questions and the title of this thread should probably be rephrased, I understand now that changing the float comparison would be a fatal flaw in the language and apologies for ever mentioning it. Before I ask any other questions, I would like to understand how float-string conversion works: php -dprecision=100 -r 'echo 0.3,\n;' 0.299988897769753748434595763683319091796875 php -dprecision=8 -r 'echo 0.3,\n;' 0.3 php -dprecision=8 -r 'echo 0.3*0.075,\n;' 0.0225 I have checked out PHP from CVS and I'm looking at zend_operators.c : convert_to_double(zval *op) Is this the right place? This question stems from a scenario I see often, some programmers using PHP to do accounting and the result is often well, let's say things are not what they would expect (not all PHP programmers have a CS degree). Bcmath does solve the problem, but maybe there's room for improving how PHP could natively compare and manipulate decimals with limited precision (i.e. currency, taxes etc..). The fact that frameworks need workarounds (i.e. Zend_Locale_Math) is an indicator that it's an important use case for the community... If someone could point me to the float-string code, I'd really appreciate j -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: May 4, 2008 7:06 AM To: Todd Ruth Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Float comparison Hello Todd, please read that article to get at least a minimum understanding of what float values are. Speaking of comparisons and floating point values you might want to consider using fixed point values. That is you decide how many digits you want for your fractions. Another option is to use two ints to present numbers (numerator/denominator). The third solution is to always round (but then the float rules apply again to some extend). The forth solution is to do BCD arithmetics which might be a bit slower even. Maybe you should have a look into PHP's bcmath extension. Anyway, just to get this straight. The comparison operators work indeed perfectly for float values. They just don't lead to the results you might expect. And that is in fact a result from their design. And that design is used in all modern CPUs. The ways out are mentioned above and interstingly some high end processors even support one or the other in silicon. marcus Friday, May 2, 2008, 7:36:33 PM, you wrote: I'm afraid you'll find Pierre's response representative. The php devs seem to consider the fact that a theoretically perfect == doesn't exist to mean that the improvements that would cover 99.9% of user issues with float == shouldn't be made. It could be worse, however. At least the cast to string works as one would expect. Just imagine if those who oppose improving == had their logic extended to the cast to string. Php might to the following: ?php $x=.3+.4+.5; print $x\n; ? might output 1.19996447286321199499070644378662109375 If someone filed a bug report, they could refer you to that paper and tell you there's no bug because you're trying to get a string from float and you never know what you might get. So we can at least be glad that casts to string work as the average person would expect. We can hope that someday the fact that the cast to string works as expected will inspire them believe that making == work as expected wouldn't be a bad thing. Seriously though, the biggest issue I see with improving == is the implication for other features. For example, what should the following code do? $a[.3+.4+.5] = hello; print isset($a[1.2]) Should floats be allowed as array indices? I would say no because I'd rather floats be converted to strings before being used as array indices. That would make the above code work as the average person would expect. Unfortunately, that would be a huge BC break. However, perhaps the perfect shouldn't be the enemy of the good and we shouldn't let the inability to fix floats as array indices be a reason not to improve ==. - Todd On Fri, 2008-05-02 at 19:04 +0200, Pierre Joye wrote: On Fri, May 2, 2008 at 6:52 PM, Jonathan Bond-Caron [EMAIL PROTECTED] wrote: Hi, I'm new to the PHP internals list and I'm posting an issue I'm sure has been mentioned before -- float comparison I'd like to know if there are reasons not to change the default behavior when comparing floats. i.e. This would seem logical to me: $test = 19.6*100; if((float)(string)$test == (double)1960) echo GOOD BEHAVIOR; // Implicitely convert the float to string then float (en_US locale) if($test == (double)1960) echo THIS SHOULD PASS by casting (float)(string)$test internally...; else echo NOT GOOD BEHAVIOR
RE: [PHP-DEV] Float comparison
Thanks, I made some tests after looking at
http://lxr.php.net/source/php-src/main/spprintf.c#712
At first glance, I am utterly confused,
ini_set('precision', 100);
setlocale(LC_ALL, 'fr_FR.UTF-8');
echo 0.3; //
0,299988897769753748434595763683319091796875
echo \n;
echo (string)0.3; // 0.3
// expected: 0,3
echo \n;
echo (float)(string)0.3;//
0,299988897769753748434595763683319091796875
// expected: 0,3
echo \n;
echo sprintf('%G', 0.3);// 0,3
// expected: 0,3
echo \n;
I'll dig more into the code... just thought I would share this (PHP 5.2.3)
-Original Message-
From: Stefan Walk [mailto:[EMAIL PROTECTED]
Sent: May 4, 2008 1:31 PM
To: Jonathan Bond-Caron
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Float comparison
If someone could point me to the float-string code, I'd really appreciate
http://lxr.php.net/source/ZendEngine2/zend_operators.c#1075
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Float comparison
Hi, I'm new to the PHP internals list and I'm posting an issue I'm sure has been mentioned before -- float comparison I'd like to know if there are reasons not to change the default behavior when comparing floats. i.e. This would seem logical to me: $test = 19.6*100; if((float)(string)$test == (double)1960) echo GOOD BEHAVIOR; // Implicitely convert the float to string then float (en_US locale) if($test == (double)1960) echo THIS SHOULD PASS by casting (float)(string)$test internally...; else echo NOT GOOD BEHAVIOR; // Exact comparison would still fail if($test !== (double)1960) echo GOOD BEHAVIOR; Any reason why $test == (double)1960 should fail? I realized we are comparing two floats, but couldn't php internally convert to string then float - for the non strict (===) case Thanks
RE: [PHP-DEV] Float comparison
Thanks Pierre, I realize it's not a bug and I've read some bogus reports :) But since (float)(string)$test == (double)1960 is 'correct' My question is: can php do the conversion internally? It would seem *very* convenient for users, If not changing the float behavior, I'm advocating for a (numeric) type that does this magic conversion. (numeric) == (float)(string) in en_US locale / convert to string with a . seperator Let's say it's hard to promote PHP as enterprise ready without dealing so well with numbers. I don't know the float-to-string internals but it seems to do 'right' thing. We get '1960', then converting back to a float, all accuracy bits are 0, so (numeric)$test == (double)1960 I would guess adding a new type is a big amount work? -Original Message- From: Pierre Joye [mailto:[EMAIL PROTECTED] Sent: May 2, 2008 1:05 PM To: Jonathan Bond-Caron Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Float comparison On Fri, May 2, 2008 at 6:52 PM, Jonathan Bond-Caron [EMAIL PROTECTED] wrote: Hi, I'm new to the PHP internals list and I'm posting an issue I'm sure has been mentioned before -- float comparison I'd like to know if there are reasons not to change the default behavior when comparing floats. i.e. This would seem logical to me: $test = 19.6*100; if((float)(string)$test == (double)1960) echo GOOD BEHAVIOR; // Implicitely convert the float to string then float (en_US locale) if($test == (double)1960) echo THIS SHOULD PASS by casting (float)(string)$test internally...; else echo NOT GOOD BEHAVIOR; // Exact comparison would still fail if($test !== (double)1960) echo GOOD BEHAVIOR; Any reason why $test == (double)1960 should fail? I realized we are comparing two floats, but couldn't php internally convert to string then float - for the non strict (===) case From our bug report: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. We use this text as automatic reply for bugs about floating points (aka bogus). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
