I like the concept in principle. But implementing it is non trivial.
First, you need a base-conversion function that will allow you to convert
between arbitrary bases (base_convert() won't work, because it only works
on fixed bases, and on numbers < INT_MAX)... Here's a utility class that
does jus
Nikita,
On Mon, Jul 16, 2012 at 5:30 AM, Nikita Popov wrote:
> On Mon, Jul 16, 2012 at 8:04 AM, Galen Wright-Watson
> wrote:
> > What about an approach like PDO, where the password functions would
> > generate errors by default, but could be configured to throw exceptions?
> > The ugliest aspec
Ferenc,
On Mon, Jul 16, 2012 at 8:25 AM, Ferenc Kovacs wrote:
> Hi,
>
> The recent
> http://www.mail-archive.com/internals@lists.php.net/msg59301.html
> discussion
> made me wonder why did we decide not supporting the final keywords for
> properties as it would provide an easy way for read-only
Daniel,
On Sun, Jul 15, 2012 at 8:20 PM, Daniel Convissor <
dani...@analysisandsolutions.com> wrote:
> Hi Anthony:
>
> > But I agree with your larger point. The only problem with it is that it
> > would take an engine wide shift to do.
>
> How does using exceptions in this new extension require a
Alex,
On Sun, Jul 15, 2012 at 7:19 PM, Alex Aulbach wrote:
> Ok. I think, I go too much off topic. Sorry.
>
> But I want to repeat
> - we never know in which context the program will run. And good
> security means, thait it shouldn't care, in which context it runs.
>
Could you explain what you m
Check out the conversation around it.
Specifically: http://marc.info/?t=13308247243&r=1&w=2
But also: http://marc.info/?t=13302683324&r=1&w=2
So basically it just stopped. But that doesn't mean that it can't
be resurrected or continued...
Anthony
On Sun, Jul 15, 2012 at 11:48 AM, Bra
Gustavo,
Why is the last key special? Why not a function to get the first or the
> penultimate key?
>
How would such a function look?
> Of course, there is one aspect where the first and last keys are special
> -- if you have some algorithm where you pop or shift the array
> successively. But i
Stas,
> I like this idea. array_first_key would be nice too
>
> I am probably missing something, but what those would allow to do that
> rewind/end+key() doesn't do?
>
The big thing that it does that end()+key() doesn't do is really what it
doesn't do (update the internal pointer).
end() modifie
Hey all,
I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.
So, I was curious if we could start a conversation around what 6.0 would
look like if we didn't go the unicode route. What wou
Alex,
First off, thanks for such a thorough reply!!! Comments are inline.
1. The resulting string should have a version information. For example
> the first char. the example hash will look like
> "1$2y$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi",
> instead of "$2y$07$usesomesillys
Stas,
> https://wiki.php.net/rfc/password_hash
>
> Looks good. The only question I have is for password_make_salt() - do we
> need the user to specify length? I think length is defined by the
> algorithm in the most cases. Maybe convert it to password_make_salt(int
> $salt_type = PASSWORD_SALT_BC
Pierre,
> I've added a pair of new functions to the RFC and implementation:
> >
> > password_needs_rehash($hash, $algo, array $options = array())
>
> Not totally convinced about that one.
I'm not either. That's why I added the discussion point around it. I can
see it going either way.
> I woul
Stas,
> For non-interchangeable types it is already strict by definition. I
> > don't see a problem with type hints that make life easier on both the
> > caller (by generating better error messages) and the callee (by having
> > to write less boilerplate type verification code).
>
> It doesn't mak
Hello all,
At present, there's now way to type hint over a generic structure that it
iteratable using foreach(). You can accept arrays using the array hint, and
objects using traversable, but you cannot hint both. This yields code that
wants to accept that to look like this:
function foo($a) {
Hello all,
Since the discussion has died down around the concept, I have updated the
RFC and moved it into Proposed (under discussion) status.
I have updated the RFC to include a section on discussion points containing
points that I know were raised but I felt were not closed (there was some
deba
Johannes,
One thing to keep in mind when doing this is to think about consistency.
>
I think that's a huge point not to be taken lightly. For that reason, I
think that this API should not be used for any of the array_* functions.
Meaning that array_sum(), etc should all take arrays only.
Then, o
t;
> On Mon, Jul 2, 2012 at 5:49 PM, Anthony Ferrara wrote:
>
>> Sara,
>>
>> On Mon, Jul 2, 2012 at 8:24 PM, Sara Golemon wrote:
>> > I'd like to see hash_init() support this mode as well (for
>> completeness).
>> > Perhaps something like the fo
ly in user-land, I'm not
convinced it's needed. Then again, it's easy to implement and shouldn't
pose a maintenance headache, so I'm not sure if it shouldn't be there
either...
What do you think?
Anthony
On Tue, Jul 3, 2012 at 5:24 PM, Anthony Ferrara wrote:
> Rich
Hey all,
I've run into an issue with run-tests.php with the junit format. The XML
that it generates can be invalid because of invalid UTF-8 characters and
invalid XML characters. This means that trying to parse it using something
like Jenkins gives a huge stack-trace because of invalid XML. I've b
Richard,
> There is also the case of an app that simple shouldn't run with the
> single default, but could pick and choose suitable algorithm from a
> list of defaults, while still honoring whatever is in the .ini file
> instead of going rogue with some other algorithm.
I disagree there. I think
Christian,
> Hi Anthony,
> I tried sending this to intern...@php.net but it seems it didn't get
through...
Replying on list.
>> know you didn't like PASSWORD_MOST_SECURE. So what about keeping
>> PASSWORD_DEFAULT as a moving target, documented, and just making the
>> second parameter (algo) to p
Pierre,
> It is still the case.
>
> I for one would like to kill all the legacy features or too specific
> features which are really unusable by any common developers.
>
> Other developers may disagree but it makes very hard to maintain APC.
Perhaps that indicates it's time to pull the core of AP
Pierre,
>> I know you didn't like PASSWORD_MOST_SECURE. So what about keeping
>> PASSWORD_DEFAULT as a moving target, documented, and just making the
>> second parameter (algo) to password_hash required? That way users
>> could choose between PASSWORD_BCRYPT and PASSWORD_DEFAULT.
>>
>> That way, ov
Pierre,
Getting back to the PASSWORD_DEFAULT discussion...
I know you didn't like PASSWORD_MOST_SECURE. So what about keeping
PASSWORD_DEFAULT as a moving target, documented, and just making the
second parameter (algo) to password_hash required? That way users
could choose between PASSWORD_BCRYPT
Pierre,
> Simply by not allowing to change it. If one does not like it, it can
> pass the option value as he wishes.
>
> An ini setting for that sounds wrong to me.
Alright. I've pulled the ini option from the fork, and have updated
the RFC to the same...
Anthony
--
PHP Internals - PHP Runtime
Sara,
On Mon, Jul 2, 2012 at 8:24 PM, Sara Golemon wrote:
> I'd like to see hash_init() support this mode as well (for completeness).
> Perhaps something like the following:
>
> $ctx = hash_init("sha512", HASH_PBKDF2, $salt, array('length' => 32,
> 'iterations' => 5000));
>
> The new fourth para
Chris,
> To be honest, a note next to PASSWORD_DEFAULT would be good too.
Ok, I'll add that in shortly.
>>> The API of password_make_salt() seems restrictive. What if other
>>> options are needed in future?
>>
>>
>> Can you give any examples of what options would be needed in the
>> future, or
Chris,
> Can you update the RFC (aka future documentation) and make this obvious
> to an end user?
I just made an update (in the behavior sections). Let me know if
additional clarification is needed.
> I think PASSWORD_BCRYPT should be an ordinal value, which the new
> library maps to "2y" when
Paul
On Mon, Jul 2, 2012 at 12:38 PM, Paul Dragoonis wrote:
> I see no coding examples, just a function declaration.
I've updated the RFC adding 2 examples.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello all,
I've opened voting for the hash_pbkdf2 RFC adding hash_pbkdf2() to master:
https://wiki.php.net/rfc/hash_pbkdf2#vote
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pierre,
> Quick reminder, it will be -1 from here if it targets 5.4, for all the
> reasons I have been repeatedly explaining.
I've updated the RFC to indicate such (that it's only targeting master (5.5)).
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
o the vote, please do so!
https://wiki.php.net/rfc/hash_pbkdf2
Anthony
On Thu, Jun 21, 2012 at 7:41 AM, Anthony Ferrara wrote:
> Pierre,
>
>>>> I would update the RFC with the current available algorithms or
>>>> recommended to be used (depending on the usage o
Additionally, it appears that SHA256/512 are way overallocating the buffer.
For SHA512:
int needed = (sizeof(sha512_salt_prefix) - 1
+ sizeof(sha512_rounds_prefix) + 9 + 1
+ salt_in_len + 1 + 86 + 1);
output = emalloc(needed);
salt[salt_in_len] = '\
Johannes,
> I haven't looked at your patch. But if it has to call another
> PHP_FuNCTION then it's not good. crypt implementation should be
> accessible via C.
I've refactored crypt() slightly to expose a PHP_API crypt_execute()
function that does just about everything except the argument parsing
Pierre,
> No, it is exactly one example out of many where changing values are a
> real pain to deal with over the years. We should not have one.
While I completely see your point (and don't disagree with it in
isolation), I also see the counter point of making it easy for people
to use. Knowing a
Johannes,
> Some comments on the "error behavior" part:
>
> E_WARNING - When CRYPT is not included in core (was disabled
> compile-time, or is listed in disabled_functions declaration)
>
> Disabling a different function should have no effect. This is not
> intuitive. If crypt is a dependency
Arvids,
On Wed, Jun 27, 2012 at 12:32 PM, Arvids Godjuks
wrote:
> On that note I have only one request - please point me to the good article
> that describes how this thing works (I would prefer one that at least tries
> to explain in simple words) because at the moment i do not understand how
>
Arvids,
On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks
wrote:
> Hello.
>
> I personally think that using PASSWORD_DEFAULT for algorythm by default is a
> bad idea. This should be defined by user in the code. Even worse if it is
> defined by .ini setting - deploy to a remote server and realize th
Alexander,
> BTW, what version of PHP introduced the === comparison operator?
> I guess this should become the minimum version for phpass since this is
> highly desirable to use.
>
> http://www.php.net/manual/en/language.operators.comparison.php does not
> say anything about that.
>
That's been i
Pierre,
> Back then MD5 alone was all nice and shiny. So no, it is not possible
> to be forward compatible.
By forward compatible, if you mean able to support any new algo, I
think this is forward compatible. The options array allows for new
implementations to implement whatever options they need
Pierre,
>> As I understand, hashes computed with the old default method could still be
>> checked without any modification as the hash itself stores information about
>> the method.
>
> That's only about one relatively simple use case where only PHP would
> be involved or crypt-like implemenation.
Alex,
> Thank you for the chance to comment, and sorry that I did not do so yet.
> I am busy with lots of other stuff. I'd appreciate it if you don't
> hurry to implement this stuff too much, and I likely will comment on it
> (that is, on the actual proposed API and implementation). Please keep
Simon,
> * Will the value of the constant PASSWORD_DEFAULT remain unchanged forever?
> Otherwise this lib, in my opinion, can cause big problems when trying to
> port an existing system to a newer PHP-version.
No. That's why it's a separate constant. As newer, stronger hashing
options become avai
Hello All,
I've taken the conversation of the previous simplified password
hashing API, and generated a patch and draft RFC for it. The patch
isn't ready yet (needs review, cleanup and testing), but it's a start.
https://wiki.php.net/rfc/password_hash
Please have a look and comment away!
Thanks
;t care
for the amount of PHP function calls it makes
(zend_call_method_with_n_params). But that may be ok, given the
What do you think so far?
Anthony
On Wed, Jun 20, 2012 at 6:05 AM, Anthony Ferrara wrote:
> Angel,
>
>> I don't think the code is the most appropiate one, but
Jun 21, 2012 at 10:19 PM, Anthony Ferrara wrote:
> As it turns out, the testing of this is far more difficult than I
> originally suspected. Not because it fails, but because emulated
> queries were behaving badly to begin with, so a number of tests were
> testing bad behavior. For exampl
As it turns out, the testing of this is far more difficult than I
originally suspected. Not because it fails, but because emulated
queries were behaving badly to begin with, so a number of tests were
testing bad behavior. For example, bug 44327:
https://github.com/ircmaxell/php-src/blob/master/ext
Pierre,
>>> I would update the RFC with the current available algorithms or
>>> recommended to be used (depending on the usage or goal).
>>
>> When you say "currently available algorithms", are you talking about
>> the hash library as a whole? Or recommended for use with PBKDF2? Or
>> other iterat
Jonathan,
> 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);
Checkout the other thread about adding a simple password API.
As far as implementing that as well
Pierre,
On Jun 20, 2012 8:27 AM, "Pierre Joye" wrote:
>
> hi Anthony!
>
> On Wed, Jun 20, 2012 at 12:12 PM, Anthony Ferrara
wrote:
>
> >> I would update the RFC with the current available algorithms or
> >> recommended to be used (depending on the usag
Pierre,
> Very nice work! Thanks :)
Thanks!
> I would update the RFC with the current available algorithms or
> recommended to be used (depending on the usage or goal).
When you say "currently available algorithms", are you talking about
the hash library as a whole? Or recommended for use with
Angel,
> I don't think the code is the most appropiate one, but I suppose that's
> not a final proposal.
Correct, it was just to fill out the interface a bit so that people
could play with it and see how the interface worked...
> The interfaces look good to me.
> I'd maybe set the default $algo
Hello all,
Since there wasn't that much traffic on the draft version of the RFC,
I've moved it into Proposed.
https://wiki.php.net/rfc/hash_pbkdf2
What are your thoughts?
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
Enrico
> I like your idea to offer a wrapper of crypt() with a better API
> (actually I used this approach in the ZF2 project:
> https://github.com/zendframework/zf2/blob/master/library/Zend/Crypt/Password/Bcrypt.php).
Yeah, crypt() is really nice, and offers a lot of good things out of
the box.
Hello all,
I'd like to request commit karma for php-src trunk. Among the things
I'd like to commit include https://github.com/php/php-src/pull/108
Let me know if there's anything else that I need to do or provide.
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
Pierre,
> There is sadly only state-of-art-right-now password hashing methods.
> We have to keep that in mind :)
That's why the crypt() return format was designed. All of the options
that are needed to validate the hash (algorithm, cost parameter, salt,
etc) are fit right into the outputted strin
Herman,
> This userland library already solves all the issues you outlined with
> bcrypt: http://www.openwall.com/phpass/
That library is not without its issues. For example, if you ask for a
portable hash, it gives you a custom algorithm instead of bcrypt.
That's because the library is php4 comp
> Am 15.06.2012 19:31, schrieb Anthony Ferrara:
>
>> Ulf,
>>>>>
>>>>> It needs an RFC because it needs to document whether or not the other
>>>>> DB drivers should also be changed.
>>>>
>>>>
>>>>
>&
Ulf,
>>> It needs an RFC because it needs to document whether or not the other
>>> DB drivers should also be changed.
>>
>>
>> It's a PDO driver-specific change. So to me it's fairly straight
>> forward to see that no other drivers need changing... It doesn't even
>> hit the mysql API level...
>>
>
Chris,
>>> Does this need to be an RFC (should I draft one)? Or can it just be
>>> pulled as-is?
>
>
> It needs an RFC because it needs to document whether or not the other
> DB drivers should also be changed.
It's a PDO driver-specific change. So to me it's fairly straight
forward to see that no
Hello all,
I raised this topic on list over a year ago (
http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was
determined that it wasn't time yet to disable prepared statement
emulation for MySQL yet. However, Rasmus did mention that it was a
possibility for 5.4 (
http://marc.info/?l=p
Peter,
> I would say it really depends upon the project. The salt can not only
> protect against rainbow tables and password hash collisions, if it is
> unknown to an attacker then it essentially acts to further strengthen
> the hash by vastly expanding the keyspace.
That's not true. There are tw
Thomas,
> This:
>
> http://barebonescms.com/documentation/csprng/
>
> Takes a different approach. Generate one or more stored root seeds and then
> use those seeds to generate as much data as is needed without risking loss
> of entropy. It also accepts extra entropy sources as input - even weak
Peter,
> Whether or not a CSPRNG is needed depends on what you're doing, your
> needed level of security. Perhaps add a parameter to control this, so
> it would be possible to make use of this function even if you need the
> maximum level of security? If it's not available, the function should
> f
Daniel,
> However, I'd like to throw in scrypt as well. Thoughts?
Yes, that's something to include for sure. I've actually been working
on the side on an implementation of scrypt to sit next to my pbkdf2
proposal as hash_scrypt (as the native function, so that it can be
used natively (without the
Simon,
> I personally would rename the 2nd parameter to $data as this function is not
> only meant for creating secure hashes from passwords.
Well, I understand your sentiment. But PBKDF stands for Password Based
Key Derivation Function. Even the spec calls that parameter password:
PBKDF2 (P, S
Hello all,
I've written up a quick draft version of an RFC for pull request 105 (
https://github.com/php/php-src/pull/105 ), to add hash_pbkdf2() to the
core implementation. Please give it a look and provide some feedback,
so that this can move into discussion as a more defined proposal.
https://
I've submitted a Pull Request for this feature. I'll whip up an RFC
for it tonight and propose it.
https://github.com/php/php-src/pull/105
Thanks,
Anthony
On Tue, Jun 12, 2012 at 10:38 AM, Anthony Ferrara wrote:
> Pierre,
>
>> I am all for having it in hash as well. But
Pierre,
> I am all for having it in hash as well. But yes, it requires more work
> that may need additional RFC (changing the API to allow more options
> need discussions).
What options are needed? The API refactoring that I have done has all
been to static functions, and extracting methods from
Derick,
>> I noticed that yesterday a patch was committed to trunk to add PBKDF2
>> support to the OpenSSL extension. I also noted that in the commit
>> message, the author indicated that he would have rather added it to
>> the hash extension, but wasn't able to.
>
> Why wasn't he been able to?
Hello all,
I noticed that yesterday a patch was committed to trunk to add PBKDF2
support to the OpenSSL extension. I also noted that in the commit
message, the author indicated that he would have rather added it to
the hash extension, but wasn't able to.
I had added a patch back in January for t
Nikita,
> I don't know whether that behavior is of any use, so I'll gladly
> change the behavior to throwing an exception if that's more desirable.
You can't throw an exception from rewind, since it's called before
foreach(). So it wouldn't be iterable then.
I think the noop on rewind is valid
Pierre,
>> AFAIK 2 of the people voting "both" (myself included) already said they
>> are OK with "empty only".
>
> If the other one can raise his voice, then we are good.
I had meant to reply to the list, but I had replied to Stas directly.
I would be happy to change my vote from isset() and emp
Pierre,
On Wed, May 2, 2012 at 5:43 AM, Pierre Joye wrote:
> hi,
>
> On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs wrote:
>
>> $foo=null;
>> var_dump(isset($foo)); //prints bool(false)
>
> No offset meant, but it is totally expected and well known, and as far
> as I remember documented too. Ass
I know it doesn't really fit this problem in general, but I figured I
would point it out. Lighttpd introduced a brilliant concept by
letting the server serve that file directly. Basically, instead of
using readfile, you would just send a header: X-SendFile: $filename...
It's available for Apache
define a writer for that
property, which may be undesirable... Then again, what are the use
cases for an enforced read-only (or write only for that matter)...?
> RFC looks good though, much better than initial proposals - I like it! :-)
Very much agree there...
Anthony
> - Rasmus
>
>&g
Clint,
Additionally, one more comment related to the read-only and
write-only. I noticed that you're using E_ERROR for improper access.
Obviously you don't want this to be a warning, as the execution
shouldn't continue because that would be undefined. However, what
about setting it to E_RECOVERA
Clint,
Very nice job overall! Looking quite good.
> Alternatively we could throw an error to a call on isset and/or unset
> against a property which didn't define an implementation.
I don't care for that concept much. All it's doing is trading one set
of boilerplate for another. I'd prefer
Kris,
> As discussed on other threads, PHPP files that are called directly from the
> webserver are handled by the SAPI handler and thus don't need any special
> identification.
Except that they do. Right now, SAPI handlers just invoke PHP. So
there would need to be some way of communicating th
Kris,
> You do realize you just proved my point, right? I said that, because only a
> small few people were actually participating in this thread, it would be
> completely disingenuous for one side or the other to claim to represent the
> majority opinion. The fact that you stepped in does not c
Kris,
> It's worth noting that there are already two other similar RFCs that have
> been proposed and other people have expressed interest in this idea. Most
> of the opposition on this thread has come from 2 people, one of whom has
> been mostly posting hyperbolic claims and scare tactics. Ther
Stas,
> Because the engine doesn't run code when parsing class definitions so
> defaults should be constants (otherwise would also create a lot of
> trouble for bytecode caching as object are not cacheable).
Just throwing this out there, but that code wouldn't be run on parse.
It would be "queued
Nicolas
>> $closure = function () use ($this->getFooBar() as $foo) {
>> $foo->stuff();
>> }
>
> But this can already be written as :
>
> $closure = function () {
> $foo = $this->getFooBar();
> $foo->stuff();
> }
Except that's not equivilant. getFooBar() in the first example is
called
The only real use that I can see would be that it allows:
public function getCallback() {
return function() use ($this as $that) {
$that->doSomething();
}
}
However, I think that would be confusing, since $that would only have
public access...
I'm not against the idea, I just don
Lester,
Even with PDO and older versions of MySQL, you could inject into
prepared statements quite easily (assuming charset settings):
$var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
$pdo = new PDO('mysql:...');
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?')
ion
case. It's not possible that code flow will magically jump around.
Sure, you could emulate it with goto (
http://codepad.viper-7.com/i3Dhv4 ). But that's explicitly jumping
around.
Anthony
On Fri, Apr 6, 2012 at 9:31 AM, Rasmus Schultz wrote:
> 2012/4/5 Anthony Ferrara :
>>
Rasmus,
What would that give you that a continuation passing paradigm
wouldn't? Why not tell the code what to call before you call it,
rather than bubbling up the stack (which then forces a fork of the
stack, as you need to partially unwind it, but keep track of what you
unwound for the resume).
plementing a yield function, has
> this ever been discussed before? My apologies if this is the case I've not
> seen it since I've been following this list.
>
> I know there is the SPL Iterator, but just as in the example you provided
> implementations *can* be verbose and
Sam,
I'm not saying it's a good idea, but this would allow for pythonic
style generators. http://wiki.python.org/moin/Generators
Just pointing out one potential use-case...
Anthony
On Mon, Apr 2, 2012 at 4:35 PM, Samuel Giles wrote:
> Hi Internals
>
> function test()
>> {
>> echo "Begin Test
> But Pierre, you understand that by the time you ini_set() it in the code
> it can only ever affect parse_str() calls.
Well, wouldn't INI_ALL would allow .htaccess files to override that
statement, and hence open the vulnerability?
Anthony
--
PHP Internals - PHP Runtime Development Mailing Lis
Lazare,
> The patch of Anthony, clearly states that this is accepted:
>
> function foo ( int $bar = null ) { }
>
> And this is what I called an int|null.
Yup, it does. Because that's the current behavior with array and
object casting. If you default it to null in the declaration, null is
a vali
Arvids,
> Yea, that part looks confusing.
> What I wanted to say is that I would like to get E_RECOVERABLE_ERROR and I
> was voicing my opinion on that earlier in the threads. But I could live with
> E_WARNING and E_NOTICE if community decides it to be less strict - I will
> clean up my code not t
Arvids,
On Mon, Mar 12, 2012 at 4:39 AM, Arvids Godjuks
wrote:
> I should point out that returning false on param parsing failure on the
> language level is one thing (not to mention it's not ok to do that in the
> first place by my taste), but forcing that behavior on the user-land level
> is ki
Ok, so it looks like we've had some decent conversation, but it has
started to tail off a bit. I'd normally draft an RFC at this point,
but it seems there's still some contention on how exactly the
implementation should work.
Personally, if we're going to go for any form of strict checking
(meani
John,
> The reason you have to validate the input type in this case is because even
> though it is a reference, we don't ACTALLY know that it isn't supposed to
> contain an input (even though that would be against all sane rules most of
> the time).
Well, we don't know, but I'd argue do we rea
Lazare,
>> This won't make it easy passing a variable as reference.
>
> Type casting combined with passing by reference is problematic in many ways.
No it's not. The core functionality does it quite fine, and it uses
typed parameters...
> Just an example:
>
> fuction foo( string & $buffer) { ..
Lazare,
On Fri, Mar 9, 2012 at 8:54 AM, Lazare Inepologlou wrote:
> Yes, like that, only better. Since automatic type casting is central in PHP,
> as this is evident after all this discussion, I believe that it should be
> better supported. There are two thinks that I would like to see here:
>
>
John,
> And yet, __toBool probably sits right next to __toArray in terms of the level
> of usefulness (maybe even beats it.) isset() can always be used to determine
> whether something was ACTUALLY set to a non-null value, and to some extent
> there is already a semantic problem anyway since th
> (Now, it would be nice to have another RFC about custom object casting to
> int, float and bool...)
You mean like https://wiki.php.net/rfc/object_cast_to_types which is
still in draft?
Note that __toBool would be problematic, since it would be called if
the object was used in an if statement, w
Actually, it turns out the segfault and auto-reference bugs were
easier than I thought to fix. I've updated both gists with the new
code, and it looks to be running quite well...
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara wrote:
> Hey all,
>
> As promised, I've cre
401 - 500 of 616 matches
Mail list logo
