Some responses inline...
So, since PHP lets you do bad things in the first place (like have
constructors and static methods in interfaces, and abstract ctors in
abstract classes), we follow that up with another bad of breaking general
LSP expectations of how things work?
Isn't this trying
Comments Inline
1) What we know and have been told is that PHP's signature
checking is governed by Liskov Substitution Principle. There are
many references to this in the list.
Except that signature checking is not needed for LSP to function. You
can write all of your code using duck typing
If I'm not mistaken, that is to be expected. That's because you're on
a 32 bit system, so the maximum possible int (PHP_INT_MAX) is
2147483647. Now, normally PHP could cast to a float to get the larger
number in, but you explicitly cast it to an integer, so it had to
truncate the value.
Try
Hello all,
I've had an idea that's been burning in my head for a while. Rather
than write an RFC or do any significant work on it, I thought I would
bounce this off of you all first.
Basically, I see a problem with implementing decorators in PHP. To
explain the problem, let's say that I have a
Ralph:
From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking from constructors all together.
(I don't care for this, but whatever). Additionally, since it's not
enforced, perhaps an E_DEPRECATED or
One thing to note. The good test for what's being talked about would be simple:
isset($foo['bar'][1]['baz']) is_array($foo['bar'][1])
You don't need to check each level. Only the one above the key you're
looking at.
I think it would be a good idea to raise a notice on string index
conversion
, 2011 at 5:48 AM, Richard Quadling rquadl...@gmail.com wrote:
On 23 November 2011 18:37, Anthony Ferrara ircmax...@gmail.com wrote:
Ralph:
From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking
Excellent thinking. One hitch... that goes fatal in 5.3 if $foo is a string.
Here's how to write the test so it works the same way under 5.3 and 5.4:
Correct. However, it's worth noting that it only goes fatal if $foo is a string.
So as long as you know that the root variable is an array, it
Comments Inline
On Mon, Nov 28, 2011 at 12:57 PM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
This seems reasonable, but there are some pretty big drawbacks as well:
* Type-hinting -- typically, a decorator should be able to be used
wherever the object it decorates is used. As
To be honest, I'm not a fan of the proposal as written since it can't
accept arbitrary expressions inside the parenthesis. Now, if you
could do any expression inside, then I would +1 for completeness. But
since that's not really possible with the current parser (or language
specification), I'm
to the validator class and is not polymorphic.
I guess my thought is that I would be fine with it as long as it can
accept reasonably arbitrary expressions...
On Fri, Dec 2, 2011 at 11:50 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2011-12-01, Anthony Ferrara ircmax...@gmail.com
Tom,
First off, very detailed post! However, there are a few things I'd
disagree with.
1. Salts for crypt() purposes need to be cryptographically secure
random numbers.
This is not true. The only requirement is that a salt be reasonably
unique (meaning that the chance of using the same one is
/12/21 Tom Worster f...@thefsb.org:
Hi Anthony,
Thank your for your reply. I inserted some comments below.
On 12/21/11 11:19 AM, Anthony Ferrara ircmax...@gmail.com wrote:
2. I was unable to do it.
I did it fine.
https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random
I
Stas,
it's not a solution for the problem it is presented to be - it does not make
your code more robust or fail less or saves you effort on development
I'm going to have to disagree with you there. Type hinting DOES save
me a LOT of effort in development. I can stop worrying about checking
Hey all,
I found a superfluous if statement while investigating another issue.
I submitted a bug to clean it up and attached a patch:
https://bugs.php.net/bug.php?id=60596
It's on line 56 of /ext/spl/spl_engine.c :
http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_engine.c#56
It's really simple,
of view...
On Wed, Dec 28, 2011 at 4:11 PM, Tom Worster f...@thefsb.org wrote:
Hi Anthony,
Thanks again for your time responding.
On 12/21/11 2:35 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Tom,
I think it nicely demonstrates a degree of sophistication that should
not be expected from
Hello all,
I've noticed that on windows.php.net that all the builds are x86. I
was wondering if there is any reason (technical or not) not to
distribute x64 builds as well there. It's quite annoying having to
constantly drop to a VM every time I need to test something that's 64
bit dependent...
argues that it is safe. Btw, it is not faster to run on
x64 either.
php-next will have x64 support tho'.
Cheers,
On Wed, Jan 18, 2012 at 12:46 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Hello all,
I've noticed that on windows.php.net that all the builds are x86. I
was wondering
Hey all,
I've found what I would call a bug (I submitted it as a feature
request, since that's probably more appropriate) with pow(). If any
one of the arguments is a float, it will cause the result to be a
float. On 32 bit systems this is fine, since all integers can be
exactly specified by
Hi all,
I've implemented a patch (attached to the bug, but in a gist as well
here https://gist.github.com/1641725 ) that implements a hash_pbkdf2()
function. The patch also slightly refactors hash_hmac() to split out
a little bit of common functionality (since pbkdf2 relies upon hmac).
If you're going to go that far, why not make a flyweight enum type?
(Basically what's described here: http://c2.com/cgi/wiki?FlyweightEnum
)...
Right now, it's a hack to get typing in place to let you pass an
integer where a class is defined (the public function foo(MyEnum
$enum) bit). If you
I've gone back and re-read a bunch of the old posts on Type Hinting,
and have come to the conclusion that it won't be done any time soon.
Not because it doesn't have merit, but because there are at least a
few fundamental difficulties that are non-trivial to figure out while
still keeping the
(__construct overloading by type) but
with Type Hinting already available for function parameters, this could be
done relatively easily I think.
Doing this would keep code isolated with smaller functions.
-Clint
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com
, Laruence larue...@php.net wrote:
On Sun, Feb 26, 2012 at 10:57 PM, Anthony Ferrara ircmax...@gmail.com wrote:
I've gone back and re-read a bunch of the old posts on Type Hinting,
and have come to the conclusion that it won't be done any time soon.
Not because it doesn't have merit, but because
in a consistent enough manner that it would work here.
On Sun, Feb 26, 2012 at 11:12 AM, Stefan Neufeind neufe...@php.net wrote:
On 02/26/2012 04:48 PM, Anthony Ferrara wrote:
I have to say, it doesn't get work, thinking this:
$mixed1 = new Interger(2);
$mixed2 = new Interge(3);
$guess_what_type_is
I fail to see how you would do it via a register function... Unless
you mean a call-chain of callbacks to try to cast with a from and
a to parameter:
spl_autocast_register(function($from, $to) {
if ($to == 'Integer') {
return new Integer((int) $from);
}
});
That could have
it sounds like you're -1ing to, is not actually what was proposed...
I'm starting to work on a patch for this as a proof of concept...
Anthony
On Mon, Feb 27, 2012 at 10:08 AM, Richard Lynch c...@l-i-e.com wrote:
On Sun, February 26, 2012 9:48 am, Anthony Ferrara wrote:
I have to say
Out of curiosity, why are you changing it to copy the object for the
result of the cast operation? cast_object should init the result
zval, so why go through the step of copying the starting object to it?
Wouldn't it be easier just to do:
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
, and zval_ptr_dtor it as well
(instead of efree, as that way if a reference is stored somewhere it
won't result in a double free, or a segfault for accessing freed
memory)?
Thanks,
Anthony
On Mon, Feb 27, 2012 at 11:39 AM, Xinchen Hui larue...@gmail.com wrote:
Sent from my iPad
在 2012-2-28，0:10，Anthony
no, it is: come back after you did your homework, and you can provide new
arguments to the discussion
To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search
Rich,
I appreciate the candid and honest nature of your reply, while
maintaining civility. This list needs more of that. Further replies
inline:
On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch c...@l-i-e.com wrote:
On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
I have to say
Ferenc,
Thanks for the comments!
On Mon, Feb 27, 2012 at 4:09 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
no, it is: come back after you did your homework, and you can provide
new
arguments to the discussion
(1) - Normal type casting rules apply
var_dump((int) $b); // int(100) - Cast was captured
$a = new Foo;
$b = new Bar;
$a-value = 2;
$b-value = 2;
var_dump(substr(test, $a)); // string(1) t
var_dump(substr(test, $b)); // string(1) te
Anthony
On Mon, Feb 27, 2012 at 3:24 PM, Anthony Ferrara ircmax
and RFC. That's why I made a POC patch, to investigate the
ramifications and prove it could be done before finalizing and
proposing exactly how it should work...
Thanks,
Anthony
On Tue, Feb 28, 2012 at 5:54 AM, jpauli jpa...@php.net wrote:
On Tue, Feb 28, 2012 at 6:05 AM, Anthony Ferrara ircmax
Can I make a suggestion? Instead of an rfc, can we collate the existing
discussion into an easier to digest format (historical as well). Summarize
the conversations and existing rfcs with the discussion around them
(including the pros/cons and problems). That way we have a point of
reference
it does, then ask. But don't
complain about things the feature doesn't even touch, it's
disrespectful and doesn't accomplish anything but to add noise to the
conversation.
Anthony
On Tue, Feb 28, 2012 at 4:37 PM, Richard Lynch c...@l-i-e.com wrote:
On Mon, February 27, 2012 11:05 pm, Anthony
Hey all,
I've created a draft version of the RFC for implementing __castTo()
and __assign():
https://wiki.php.net/rfc/object_cast_magic
It's still a draft, and has a lot more work to do, but I figured this
would be enough to start triggering some discussion (or at least a
little bit more
Stas,
Thanks for the comments!
Replies inline:
Thanks,
Anthony
On Wed, Feb 29, 2012 at 2:48 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Hey all,
I've created a draft version of the RFC for implementing __castTo()
and __assign():
https://wiki.php.net/rfc/object_cast_magic
I
Please do not implement int, float, etc as an alias to scalar. That's
going to cause nothing but trouble later on. It will instantly close
the door to any type of casting magic (due to BC concerns), be
completely non-obvious (I hinted for int, why is it a boolean?), and
cause nothing but
hint without the aliases,
it wouldn't be a problem at all to add them, since there would be no
BC break at all...
Anthony
On Thu, Mar 1, 2012 at 9:33 AM, Adam Jon Richardson adamj...@gmail.com wrote:
On Thu, Mar 1, 2012 at 8:55 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Please do
Here's one thing to consider. Right now casting/type-autoconversion
is inconsistent at best. Let me show you what I mean:
If I add 1 to a variable, the variable is converted based on the
standard http://us2.php.net/manual/en/language.types.type-juggling.php
type juggling rules, but the variable
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
the intent clear, and
there's not BC issues with class names.
David
On 02/03/12 14:48, Anthony Ferrara wrote:
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters
be confusing.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/2 Anthony Ferrara ircmax...@gmail.com
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let
Would it be worth while to discuss the possibility of LTS releases
(Long Term Support) with 5 or 7 year support (from time of initial
release)...?
5.3 is 2.5 years old now. Which means depending on the option that's
chosen here, it'll be completely out of support a mere 3.5 to 4.5
years after
I like that. That way there will always be 2 stable maintained
versions, and possibly a third (depending on timing) that's security
only...
Solves the problem quite nicely IMHO...
Anthony
On Fri, Mar 2, 2012 at 10:41 AM, Sebastian Bergmann sebast...@php.net wrote:
On 03/02/2012 07:34 AM,
). However, that's not how the current cast handler works, so
that's not what this does.
Any feedback?
Thanks,
Anthony
On Fri, Mar 2, 2012 at 3:15 PM, Adam Jon Richardson adamj...@gmail.com wrote:
On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few
Hey all,
I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to
Hello all,
I've drafted an RFC and functional-complete patch for disucssion
another alternative to add scalar object casting magic methods.
https://wiki.php.net/rfc/object_cast_to_types
Please review the RFC and attached patch, and start some discussion on
this proposal.
Thanks,
Anthony
--
Stas,
On Sat, Mar 3, 2012 at 9:27 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
https://wiki.php.net/rfc/object_cast_to_types
Some notes:
1. Use cases for this are unclear. Wrapping scalar types does not seem very
efficient as conversion is always one-directional - once you do any
Hey all,
I had messaged about these patches before, but with the 5.4 release
process happening I think it slipped through the cracks. I have 3
patches that are ready for inclusion...
https://bugs.php.net/bug.php?id=60813
Adding a new hash_pbkdf2() function to allow for a C level
implementation
In sum, I think the rule that if a mathematical operation involves a float,
the result should be a float ought to be kept.
Yes, it is a must.
Well, I'm not so sure about that.
If you look at the docs of pow(), it describes the return type as
base raised to the power of exp. If the result can
Can you make sure that only scalar or array casts can be done?
I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)
That's how it is implemented now. That'll generate a parse error...
--
PHP Internals - PHP Runtime Development Mailing List
To
/4 Anthony Ferrara ircmax...@gmail.com
Hey all,
I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any
at 10:27 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2012-03-02, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
I initially like the concept (arbitrary precision operations).
But please don't add another ini setting. Especially one where
*logic* can change depending on the setting. I don't want a case
where pow(2, 65)-1 will return different answers depending on the ini.
That's just asking for problems.
But please don't add another ini setting. Especially one where
*logic* can change depending on the setting. I don't want a case
where pow(2, 65)-1 will return different answers depending on the ini.
That's just asking for problems.
I edited the RFC while you were sending this for
My concern is the total lack of talk on-list about it. It's obviously
not perfect, but there has been little to no talk on-list about it.
That is an indication to me that it's not ready or that it won't get
in if put to a vote...
Thoughts?
Anthony
On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick
John,
Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote
consent in this case. I actually basically stopped participating when it
became apparent that people were determined to rush head first into creating
a doomed RFC without any process to ensure that historical
John,
On Tue, Mar 6, 2012 at 9:04 PM, John Crenshaw johncrens...@priacta.com wrote:
Disclaimer: The following is direct (maybe brutally so). I'm not trying to
hurt any feeling or attack, but I'm not pulling punches either. I don't have
the energy right now to polish this and make it all nice
Stas,
Thanks for the comments!
inline.
On Wed, Mar 7, 2012 at 2:31 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
https://wiki.php.net/rfc/parameter_type_casting_hints
Just took a look on it - the syntax proposed there is quite ugly and rather
confusing, I really wouldn't like to
Christian,
On Wed, Mar 7, 2012 at 3:22 AM, Christian Kaps
christian.k...@mohiva.com wrote:
Hi,
I'm with Stas here.
First let me say that I would like to see type hinting for scalars in PHP.
As a userland developer it would help me to write clean and more robust
code. But I think this
John,
Thanks a lot for the reply. Comments inline:
You've been spending a lot of time defending these proposals and trying to
prove wrong feedback that raises concerns. This is preventing you from
actually using the feedback to improve the proposals. You are losing out on
perhaps the
John,
Thanks...and aw crap. I hate feeling like I shut the door on something.
Not at all. I don't feel bad about this in the least. Yes, I would
have liked to have gotten it in, but I want a good solution before I
want mine. So I'm absolutely willing to withdraw this RFC, as it does
have
AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
solution for scalar type hints would be the unification of the scalar type
hints with the current implementation of zend_parse_parameters.
Yeah, that's basically what we were discussing. However, there's one
significant
Gustavo,
Not really, that's just a convention that if zpp fails functions return null
or false immediately (which one is used depends on the extension, current
weather, etc.). That's because there's a convention that builtin functions
don't raise exceptions. But nothings stops them from
Michael,
Quick question: how would this work with require_once?
Let's say that I have a class Foo defined in a file without a
namespace declaration.
What happens if I require_once with a namespace first (so Foo gets
imported into the namespace), and then require_once later without a
namespace?
Hey all,
As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting. First off, here's
the patch:
Directly apply-able without re2c:
https://gist.github.com/2004623
Removing generated files (requires re2c to compile):
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 ircmax...@gmail.com wrote:
Hey all,
As promised, I've created
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 ircmax...@gmail.com wrote:
Hey all,
As promised, I've created
(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,
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
Lazare,
On Fri, Mar 9, 2012 at 8:54 AM, Lazare Inepologlou linep...@gmail.com 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
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) { ... }
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 really
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
Arvids,
On Mon, Mar 12, 2012 at 4:39 AM, Arvids Godjuks
arvids.godj...@gmail.com 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
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 to
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 valid
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 List
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 sam.e.gi...@gmail.com wrote:
Hi Internals
function test()
{
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 convoluted.
Cheers,
Sam
On Mon, Apr 2, 2012 at 10:34 PM, Anthony
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).
.
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 ras...@mindplay.dk wrote:
2012/4/5 Anthony Ferrara ircmax...@gmail.com:
Why not just do:
function foo(callable $callback
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 exactly once,
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 to
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. There
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
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 the
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
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
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
From: Anthony Ferrara ircmax...@gmail.com
To: Clint M Priest cpri...@zerocue.com
Cc: internals
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
Pierre,
On Wed, May 2, 2012 at 5:43 AM, Pierre Joye pierre@gmail.com wrote:
hi,
On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs tyr...@gmail.com 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
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 empty() to
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
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
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?
I haven't
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
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 ircmax...@gmail.com wrote:
Pierre,
I am all for having it in hash as well. But yes
201 - 300 of 602 matches
Mail list logo
