Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
On Fri, Mar 9, 2012 at 3:58 AM, Ilia Alshanetsky wrote: > Anthony, > > My concern with this type of patch is that what you are proposing are > not really hints, they are forced casts. As such they modify the data > potentially leading to data loss. This patch specifically tries to overcome this problem of the previous version. It will not accept input which will lead to a data loss on cast. The only exception is passing "123abc" to an int hint, which will cast to 123 and throw a notice. This is also my only point of critique: I'd prefer to be stricter here and go all the way to a recoverable fatal error. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Anthony Ferrara wrote:
So, what do you think?
I am a big fan of this style. Accepting e.g. "1abc" as int(1) with a
notice seems like a better solution than anything else. A full error
would be too much towards strict typing (I wouldn't mind personally, but
others do have a strong opinion on this, as we've seen).
The only thing I'm not so crazy about is foob('abc') -> bool(true). I
can live with it, but I don't particularly like it as far as the typing
goes.
Ilia Alshanetsky wrote:
> My concern with this type of patch is that what you are proposing are
> not really hints, they are forced casts. As such they modify the data
> potentially leading to data loss.
I disagree with Ilia on this, as the casts are only made if they can be
converted properly, and give E_RECOVERABLE_ERROR instead. Anything
that's going to have significant data loss is covered by that.
Bottom line: I'd personally use this, while I certainly would not use
the previous style (with `(int) $foo` e.g.).
--
Ryan McCue
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
On Fri, Mar 9, 2012 at 10:58 AM, Ilia Alshanetsky wrote: > Anthony, > > My concern with this type of patch is that what you are proposing are > not really hints, they are forced casts. As such they modify the data > potentially leading to data loss. > But at least it's consistent with "array" and class name qualifiers that php already has, regardless of what you want to call it, be it hints, casts, typing, etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
From: Adam Jon Richardson [mailto:adamj...@gmail.com]
> I don't think it's fair to say that casting is too forgiving OR
> that current sentiment is settling around behavior similar to the
> internal zend_parse_parameters. This is a complex issue, and there
> are many core developers who have been focusing on other things
> besides this discussion. Their silence likely does not demonstrate
> sentiment of approval for anything at this point. This particular
> subject has much history on the PHP mailing list, and the opinions
> are far ranging. More importantly, this general subject has much
> history in all of the programming languages that are dynamically
> typed.
Sorry, you misunderstood. What I meant was *not* that core developers had
bought into this (whether that will happen is unknown.) I meant that the
discussion in this thread among the most active participants appeared to shift
hard this direction as soon as it was proposed (can't remember who by.) Taken
in the context of everything else it was a good foundation that solved a number
of problems all at once.
> Let's look at the examples you gave:
>
> (function(int){})('1'); // no error, function gets (int)1
> (function(int){})('123xyz'); // E_NOTICE, function gets (int)123
> (function(int){})('xyz'); // E_WARNING, function gets (int)0
>
> I'm wondering where you would be getting the values '123xyz' and 'xyz' from
> at runtime...
It doesn't so much matter where it comes from or why. The spec has to define
how such inputs are handled (the behavior can't be undefined). E_NOTICE and
E_WARNING matches a behavior that we know has already been considered
acceptable in the core (I.E. this is the behavior of substr()).
> Joe Armstrong, creator of the dynamically typed Erlang language,
> advocates performing checks on the datatypes at the points in the
> application that receive input, but not within the internal functions.
> It's an interesting view, and he seems to have had success building
> robust, stable software using this approach.
I tend to agree, but this sort of argument hasn't held much sway in the past on
the typing issue in PHP so in terms of designing a viable RFC that can pass a
vote I don't see that it matters much what we think here.
> Now, I'm not saying that this should be PHP's approach. I recently
> presented the idea of having a scalar type (with aliases) because
> this could identify problems the first time a PHP file is parsed
> rather than at runtime. However, I do bring up Joe Armstrong's
> approach to temper the belief that casting or something less is
> "too forgiving."
At least for me, script inputs are far less important than other stuff; for
example, generating good errors after a refactoring mistake. Allowing
everything to pass through without errors solves the documentation issue, but
basically nothing else.
> I very much enjoyed seeing someone as skilled as Anthony crank out
> a quick proof-of-concept (I'd still be sifting through Zend's
> internals trying to get out of my Objective-C mode of thinking.)
Yes, huge thanks for Anthony's contributions here.
> I just hope that we look at all options (including doing nothing),
> consider the research already done on dynamic type systems, and look
> to examples in other programming languages that can give us insights
> into what works well and what doesn't.
>
> Adam
Agreed. I've been advocating the collection and organization of information
from prior discussions for a while. If there is good stuff to learn from
discussions in similar languages we should look over that too. The primary
barrier I see here is time. Looking over all this will take a lot of work.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Anthony,
My concern with this type of patch is that what you are proposing are
not really hints, they are forced casts. As such they modify the data
potentially leading to data loss.
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara wrote:
> 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):
> https://gist.github.com/2004650
>
>
> It's a POC, but it mostly works. There is one known issue: passing a
> class implementing __toString to a string hinted function will raise a
> segmentation fault. There's also an issue of not separating the
> argument on cast yielding to reference whether indicated or not, but
> that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
> the cases where it would cast)... I'll work on cleaning it up, but I
> wanted to show the concept before investing too much work...
>
> So, basically, there are 4 new parameters:
>
> bool
> int
> float
> string
>
> The casting vs error rules are identical to zend_parse_parameters. So:
>
> function fooi(int $i) { var_dump($i); }
>
> fooi(1); // int(1)
> fooi(1.5); // int(1)
> fooi("1"); // int(1)
> fooi("1abc"); // int(1) + notice about non-well-formed numeric
> fooi("foo"); // E_RECOVERABLE_ERROR
> fooi(true); // int(1)
> fooi(array()); // E_RECOVERABLE_ERROR
> fooi($obj); // E_RECOVERABLE_ERROR
>
> function foob(bool $b) { var_dump($b); }
>
> foob(1); // bool(true)
> foob(1.5); // bool(true)
> foob("1"); // bool(true)
> foob("abc"); // bool(true)
> foob(true); // bool(true)
> foob(array()); // E_RECOVERABLE_ERROR
> foob($obj); // E_RECOVERABLE_ERROR
>
> function foos(string $s) { var_dump($s);
> foos(1); // string("1")
> foos(1.5); // string("1.5")
> foos("1"); // string("1")
> foos(true); // string("1")
> foos(array()); // E_RECOVERABLE_ERROR
> foos(new StdClass); // E_RECOVERABLE_ERROR
> foos($objImpl__toStringORcast_object); // string(result)
>
> Float works like int, so I won't list it out here...
>
>
>
> So, what do you think?
>
> Thanks,
>
> Anthony
>
> --
> 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
[PHP-DEV] Re: [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
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 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):
> https://gist.github.com/2004650
>
>
> It's a POC, but it mostly works. There is one known issue: passing a
> class implementing __toString to a string hinted function will raise a
> segmentation fault. There's also an issue of not separating the
> argument on cast yielding to reference whether indicated or not, but
> that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
> the cases where it would cast)... I'll work on cleaning it up, but I
> wanted to show the concept before investing too much work...
>
> So, basically, there are 4 new parameters:
>
> bool
> int
> float
> string
>
> The casting vs error rules are identical to zend_parse_parameters. So:
>
> function fooi(int $i) { var_dump($i); }
>
> fooi(1); // int(1)
> fooi(1.5); // int(1)
> fooi("1"); // int(1)
> fooi("1abc"); // int(1) + notice about non-well-formed numeric
> fooi("foo"); // E_RECOVERABLE_ERROR
> fooi(true); // int(1)
> fooi(array()); // E_RECOVERABLE_ERROR
> fooi($obj); // E_RECOVERABLE_ERROR
>
> function foob(bool $b) { var_dump($b); }
>
> foob(1); // bool(true)
> foob(1.5); // bool(true)
> foob("1"); // bool(true)
> foob("abc"); // bool(true)
> foob(true); // bool(true)
> foob(array()); // E_RECOVERABLE_ERROR
> foob($obj); // E_RECOVERABLE_ERROR
>
> function foos(string $s) { var_dump($s);
> foos(1); // string("1")
> foos(1.5); // string("1.5")
> foos("1"); // string("1")
> foos(true); // string("1")
> foos(array()); // E_RECOVERABLE_ERROR
> foos(new StdClass); // E_RECOVERABLE_ERROR
> foos($objImpl__toStringORcast_object); // string(result)
>
> Float works like int, so I won't list it out here...
>
>
>
> So, what do you think?
>
> Thanks,
>
> Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
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 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):
> https://gist.github.com/2004650
>
>
> It's a POC, but it mostly works. There is one known issue: passing a
> class implementing __toString to a string hinted function will raise a
> segmentation fault. There's also an issue of not separating the
> argument on cast yielding to reference whether indicated or not, but
> that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
> the cases where it would cast)... I'll work on cleaning it up, but I
> wanted to show the concept before investing too much work...
>
> So, basically, there are 4 new parameters:
>
> bool
> int
> float
> string
>
> The casting vs error rules are identical to zend_parse_parameters. So:
>
> function fooi(int $i) { var_dump($i); }
>
> fooi(1); // int(1)
> fooi(1.5); // int(1)
> fooi("1"); // int(1)
> fooi("1abc"); // int(1) + notice about non-well-formed numeric
> fooi("foo"); // E_RECOVERABLE_ERROR
> fooi(true); // int(1)
> fooi(array()); // E_RECOVERABLE_ERROR
> fooi($obj); // E_RECOVERABLE_ERROR
>
> function foob(bool $b) { var_dump($b); }
>
> foob(1); // bool(true)
> foob(1.5); // bool(true)
> foob("1"); // bool(true)
> foob("abc"); // bool(true)
> foob(true); // bool(true)
> foob(array()); // E_RECOVERABLE_ERROR
> foob($obj); // E_RECOVERABLE_ERROR
>
> function foos(string $s) { var_dump($s);
> foos(1); // string("1")
> foos(1.5); // string("1.5")
> foos("1"); // string("1")
> foos(true); // string("1")
> foos(array()); // E_RECOVERABLE_ERROR
> foos(new StdClass); // E_RECOVERABLE_ERROR
> foos($objImpl__toStringORcast_object); // string(result)
>
> Float works like int, so I won't list it out here...
>
>
>
> So, what do you think?
>
> Thanks,
>
> Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
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):
https://gist.github.com/2004650
It's a POC, but it mostly works. There is one known issue: passing a
class implementing __toString to a string hinted function will raise a
segmentation fault. There's also an issue of not separating the
argument on cast yielding to reference whether indicated or not, but
that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
the cases where it would cast)... I'll work on cleaning it up, but I
wanted to show the concept before investing too much work...
So, basically, there are 4 new parameters:
bool
int
float
string
The casting vs error rules are identical to zend_parse_parameters. So:
function fooi(int $i) { var_dump($i); }
fooi(1); // int(1)
fooi(1.5); // int(1)
fooi("1"); // int(1)
fooi("1abc"); // int(1) + notice about non-well-formed numeric
fooi("foo"); // E_RECOVERABLE_ERROR
fooi(true); // int(1)
fooi(array()); // E_RECOVERABLE_ERROR
fooi($obj); // E_RECOVERABLE_ERROR
function foob(bool $b) { var_dump($b); }
foob(1); // bool(true)
foob(1.5); // bool(true)
foob("1"); // bool(true)
foob("abc"); // bool(true)
foob(true); // bool(true)
foob(array()); // E_RECOVERABLE_ERROR
foob($obj); // E_RECOVERABLE_ERROR
function foos(string $s) { var_dump($s);
foos(1); // string("1")
foos(1.5); // string("1.5")
foos("1"); // string("1")
foos(true); // string("1")
foos(array()); // E_RECOVERABLE_ERROR
foos(new StdClass); // E_RECOVERABLE_ERROR
foos($objImpl__toStringORcast_object); // string(result)
Float works like int, so I won't list it out here...
So, what do you think?
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
On Thu, Mar 8, 2012 at 6:08 PM, John Crenshaw wrote:
>
> > Well, if your type hints gets more forgiving, than it's the same that was
> > proposed by this function a((int) $arg) {} And in this case hints have no
> > meaning at all - it's just other syntax to do the conversion that now
> looks
> > like this function a($arg) { $arg = (int)$arg; }
> >
>
> That's black and white thinking. Casting is obviously too forgiving (a
> cast literally accepts ANYTHING), and there were specific problems
> identified with that syntax that have absolutely nothing to do with whether
> you can juggle parameter types.
>
> Current sentiment seems to be settling around behavior similar to the
> internal zend_parse_parameters, which is to say:
> (function(int){})('1'); // no error
> (function(int){})('123xyz'); // E_NOTICE, function gets (int)1
> (function(int){})('xyz'); // E_WARNING, function gets (int)0
>
I don't think it's fair to say that casting is too forgiving OR that
current sentiment is settling around behavior similar to the internal
zend_parse_parameters. This is a complex issue, and there are many core
developers who have been focusing on other things besides this discussion.
Their silence likely does not demonstrate sentiment of approval for
anything at this point. This particular subject has much history on the PHP
mailing list, and the opinions are far ranging. More importantly, this
general subject has much history in all of the programming languages that
are dynamically typed.
One can find similar discussions regarding Ruby, Python, and general
discussions of type:
http://www.codecommit.com/blog/ruby/adding-type-checking-to-ruby
http://stackoverflow.com/questions/734368/type-checking-of-arguments-python
http://journal.stuffwithstuff.com/2010/08/31/type-checking-a-dynamic-language/
And, while there are some dynamically typed languages that allow optional
types, they don't provide much help here, either:
- Clojure allows type hints, but they're just for performance reasons.
http://clojure.org/java_interop
- Dart has optional types, but in Dart, everything is an object AND it's
types are unsound (i.e., let you get away with lots):
http://www.dartlang.org/articles/why-dart-types/
My point is that there are many beliefs about how to handle optional type
checks on function arguments in dynamic, weakly typed languages, and
there's not much precedent. That's not to say that nothing should be added
to PHP's capabilities. However, one constant question that emerges when
considering types in dynamic languages is what does it really buy you? The
value has to be significant, especially considering the lack of a compiler
that can ensure the correctness of a type before runtime. As Stas pointed
out in the thread for the Enun RFC (noting the importance of a compiler):
One note here: Java is a statically typed compiled language. PHP is not. So
> many arguments regarding type safety, etc. which are completely valid in
> regards to Java have no validity in regard to PHP. I understand that some
> people want to import some bits from strictly typed languages, imagining
> that this will provide them with benefits that statically typed languages
> have, namely compile-time safety checks, etc. This does not work as well in
> dynamic languages. Note for example that neither Ruby nor Python have
> enums, though you can do similar things there.
Let's look at the examples you gave:
(function(int){})('1'); // no error
(function(int){})('123xyz'); // E_NOTICE, function gets (int)1
(function(int){})('xyz'); // E_WARNING, function gets (int)0
I'm wondering where you would be getting the values '123xyz' and 'xyz' from
at runtime that you're passing off to a function expecting ints? If these
come from GPC's, then wouldn't an app pick up the issue BEFORE getting to
the point that they're being used as arguments through proper input
validation. And, if these come from a MySQL database, then wouldn't they
have been stored in a field that only stores some type of int (otherwise
one wouldn't be passing them to a function expecting ints.) And, if it
comes from a file, wouldn't the input be validated there, too, before
calling this function? Now, I'm not saying there are no examples, but they
would appear to be very limited in applications.
Joe Armstrong, creator of the dynamically typed Erlang language, advocates
performing checks on the datatypes at the points in the application that
receive input, but not within the internal functions. It's an interesting
view, and he seems to have had success building robust, stable software
using this approach. Now, I'm not saying that this should be PHP's
approach. I recently presented the idea of having a scalar type (with
aliases) because this could identify problems the first time a PHP file is
parsed rather than at runtime. However, I do bring up Joe Armstrong's
approach to temper the belief that casting or something less is "too
forgiving."
I am interested in adding some type of ability to PHP t
Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0
On 03/08/2012 05:05 PM, Adam Harvey wrote: Agreed. I'm happy to mark them as XFAIL if that's what's expected. Mike? Adam If the 5.4 behavior is deemed correct for 5.4+, then the expected output should be updated for 5.4+ tests - they should not be XFAIL. The UPGRADING file, migration doc, and any specific doc should be updated with comments about the change. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0
On 9 March 2012 00:11, Remi Collet wrote: > Le 08/03/2012 09:03, Michael Wallner a écrit : >> Sorry for the delay, but I already explained the issue in >> the bug report: https://bugs.php.net/bug.php?id=61291 > > Thanks, for the explanation. I'm still concerned about the idea that the output of a hash function would change from one minor release to another, frankly, whether the old output was right or wrong. That seems like the sort of thing users would rely on being very, very stable. > But mhash_001.phpt and mhash_003.phpt should not fail > (if we want a great PHP with 0 test failed). > > As this tests seems to be old ones from old mhash extension, > they probably should be tagged as "expected failed" with a message such > as "Compatibility break with php < 5.4.0" Agreed. I'm happy to mark them as XFAIL if that's what's expected. Mike? Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
> Well, if your type hints gets more forgiving, than it's the same that was
> proposed by this function a((int) $arg) {} And in this case hints have no
> meaning at all - it's just other syntax to do the conversion that now looks
> like this function a($arg) { $arg = (int)$arg; }
>
That's black and white thinking. Casting is obviously too forgiving (a cast
literally accepts ANYTHING), and there were specific problems identified with
that syntax that have absolutely nothing to do with whether you can juggle
parameter types.
Current sentiment seems to be settling around behavior similar to the internal
zend_parse_parameters, which is to say:
(function(int){})('1'); // no error
(function(int){})('123xyz'); // E_NOTICE, function gets (int)1
(function(int){})('xyz'); // E_WARNING, function gets (int)0
Someone (you?) made a good case for questioning these warning levels, but the
basic concept of what to accept and what to warn about is good, and already in
use (which makes it far easier to accept).
> And please give an answer to this question: If we make hints forgiving (like
> type casting), then what we have to do with current array type hints - it
> gives error on anything but arrays? Change it back so it does a conversion
> to array? Sorry, but it will make a mess in my code, because I already use
> hints for arrays and objects and changing their behavior is just out of the
> question.
>
Array behaves as it always has (E_RECOVERABLE_ERROR if you don't pass an
array). Scalar types don't implicitly convert ("juggle") to arrays, so there's
no issue there. There's no reason to attempt to support any implicit conversion
from array to string either. E_RECOVERABLE_ERROR would be perfectly appropriate
here (or you could argue to raise E_WARNING, which is technically what
zend_parse_parameters does).
> I do not remember devs explicitly saying that something like I proposed will
> not be accepted. They said there will be no strict type hinting or strict
> variable typing. And they do not want to add another syntax for type juggling
> functionality. So, if only i'm not mistaken, my idea is somewhere in between
> and doesn't look weird or extraordinary. It just adds ability to make
> arguments
> of the function/method be more picky about what they can receive.
>
Look back at the discussion and arguments. The string input thing comes up over
and over again. Resisting this point simply caused frustration and ultimately
turned into a consistent battle cry of "we're never going to add strict typing
because it breaks the language and virally affects all the code up the chain".
The input parameters became a poster child case, but conceptually if you make
this too strict it virally forces everything up the stack to behave strictly as
well (hence the frequent arguments, "it will break the language", and "it would
no longer be PHP".)
You can disagree, that's totally fine, but *this* discussion assumes that a
successful proposal must take the opposite route, and fully embrace string
inputs and limited type juggling.
> Maybe i'm mistaken, but I have a distinct impression that many of the posters
> will use type hints all over the place if and when they will be added and base
> their ideas on that. Don't get me wrong, but the auto-casting type hints are
> really needed only when you really write all the code with type hints in every
> function/method you define and you don't want to do manual conversions all the
> time.
I'd use it liberally, especially in models, but not universally by a long shot.
Type hints aren't designed to make life easier for the caller (though they
should avoid making it harder). Type hints are connected to the algorithm of
the function itself; they offer a logical guarantee to the function that the
types of the parameters are consistent with the nature of the algorithm. For
example, an add() function needs to be able to trust that parameters will be
numeric, substr needs to be able to trust that parameters will be a string + an
integral value, and so on.
If the logic requires this simple assurance, I'll use a hint. If not, I won't.
> Maybe this is that case when people tend to get min-max and do not consider
> the
> average use? My average use of currently available type hints is low in WEB
> environment and only in internal stuff where user input doesn't make in
> unchecked.
> And I had quite a good use of them in a console daemon where there is no user
> input at all (only working with database).
>
The current hints consist only of arrays and classes. These *can't* be user
inputs (well, arrays can, but really, that's so rare for someone to actually
use.) Checked or unchecked is basically irrelevant, because these parameters
could never have originated as user data anyway. Strings, integers, numbers,
values used in boolean checks, these all can and will originate as user data,
which is the concern raised over and over in the past. This is a fair argument.
O
Re: [PHP-DEV] [RFC] Specify namespace to include file into.
On Thu, 08 Mar 2012 17:51:34 +0100, Michael Morris wrote I also don't understand your template argument. Why would you need to namespace templates? Typically they are included from inside a function (and therefore don't change/access the global namespace). You forget that variable scope and namespace scope have absolutely nothing to do with each other. At all. If I have a template that needs to call a function from within my project's namespace it must either use the fully qualified name of the function or it must declare the namespace it is part of on the first line. Sorry, I confused things here for a moment. This in fact seems to be a valid use case. But you're only saving a line, and you can't rely on the fallback to globals because it would create an ambiguity. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Specify namespace to include file into.
2012/3/8 Sebastian Bergmann : > Am 08.03.2012 17:05, schrieb Michael Morris: >> Thoughts? > > Sounds pointless/useless to me. > > -- > Sebastian Bergmann Co-Founder and Principal Consultant > http://sebastian-bergmann.de/ http://thePHP.cc/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Hi, I understand why you want to have this feature ... Let me just put a view questions in here: * what if the included file contains direct code or a bunch of functions? * what about *_once file-includes inside this files? * what if the included file provides an auto-class-loader? If you just have class-files and not direct code there are still some opened questions ... The idea makes sense to me, but currently there are too much opened questions for me to take a closer look at it. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Specify namespace to include file into.
2012/3/8 Sebastian Bergmann : > Am 08.03.2012 17:05, schrieb Michael Morris: >> Thoughts? > > Sounds pointless/useless to me. > > -- > Sebastian Bergmann Co-Founder and Principal Consultant > http://sebastian-bergmann.de/ http://thePHP.cc/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Hi, I understand the point why you wanna use that ... but I think personally it does not seem to be implementable, if you'd ask me. There are too many things we would have to change or specify a behavior for ... * what if the included file contains direct code or a bunch of functions? * what about *_once file-includes inside this files? * what if the included file provides an auto-class-loader? If you just have class-files and not direct code there are still some opened questions ... The idea makes sense to me, but currently there are too much opened questions for me to take a closer look at it. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Specify namespace to include file into.
On Thu, Mar 8, 2012 at 5:30 PM, Sebastian Bergmann wrote: > Am 08.03.2012 17:05, schrieb Michael Morris: >> Thoughts? > > Sounds pointless/useless to me. Could you answer more than one liner to RFCs? Even if you totally disagree with the idea(s) behind it. Thanks. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0
2012/3/8 Remi Collet > > But mhash_001.phpt and mhash_003.phpt should not fail > (if we want a great PHP with 0 test failed). > Hi, all That's what I would like to have ... It would be perfect if new versions were not brought out if some tests still fail. I read some posts in the past before I decided to join this mailing-list where people were laughing about bugfix-releases like 5.3.7 ... Anyways: I want a great PHP with 0 failing tests - not because the amount should be 0 but because no bugs are known/testable. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Specify namespace to include file into.
Am 08.03.2012 17:05, schrieb Michael Morris: > Thoughts? Sounds pointless/useless to me. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Specify namespace to include file into.
At first glance, this is technically impossible, with regards to our
current resolution rules:
http://php.net/manual/en/language.namespaces.rules.php
Assuming you have an un-namespaced:
class Db {
public function __construct() {
$this->conn = new PDO(..);
}
}
and you require this as:
require ./path/to/Db.php, 'Some\SubDb';
How does PDO get resolved? Automatically as \PDO or as \Some\SubDb\PDO?
Isn't it just easier to change the code? ;)
-ralph
On 3/8/12 10:05 AM, Michael Morris wrote:
https://wiki.php.net/rfc/changes_to_include_and_require
Since the reaction to the first of the two suggestions was largely
negative I've withdrawn it for now to focus on the second of the two
changes. In all honestly, these two suggestions should have had
independent RFC's from the start.
Of the two suggestions this one has the more profound implications to
the language even if it is simpler to implement. Thoughts?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Specify namespace to include file into.
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? Should it require twice? Which then could break things (if there was procedural or initialization code in there)... If not, then you won't have Foo in the root namespace, and lead to other errors. Anthony On Thu, Mar 8, 2012 at 11:05 AM, Michael Morris wrote: > https://wiki.php.net/rfc/changes_to_include_and_require > > Since the reaction to the first of the two suggestions was largely > negative I've withdrawn it for now to focus on the second of the two > changes. In all honestly, these two suggestions should have had > independent RFC's from the start. > > Of the two suggestions this one has the more profound implications to > the language even if it is simpler to implement. Thoughts? > > -- > 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] [RFC] Specify namespace to include file into.
On Thu, 08 Mar 2012 17:05:19 +0100, Michael Morris wrote: https://wiki.php.net/rfc/changes_to_include_and_require Since the reaction to the first of the two suggestions was largely negative I've withdrawn it for now to focus on the second of the two changes. In all honestly, these two suggestions should have had independent RFC's from the start. Of the two suggestions this one has the more profound implications to the language even if it is simpler to implement. Thoughts? How exactly would this be useful? The purpose of namespaces is to avoid collision of symbols. Are you saying they did not solve this problem and you have to rename already namespaced files? I also don't understand your template argument. Why would you need to namespace templates? Typically they are included from inside a function (and therefore don't change/access the global namespace). I only see some usefulness as a transitional measure, which would save from namespacing 'legacy' libraries. But PHP 5.5 seems a bit late to introduce such measure. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0
Le 08/03/2012 09:03, Michael Wallner a écrit :
> On Mon, 05 Mar 2012 17:52:52 +0100, Remi Collet wrote:
>
>>
>> Using a simple C program (linked against libmash)
>>
>> Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39
>>
>> So the result from php <= 5.3.10 seems the right one.
>
> Sorry for the delay, but I already explained the issue in
> the bug report: https://bugs.php.net/bug.php?id=61291
Thanks, for the explanation.
I raised this issue, because of 2 failing tests.
Another test (because Interoperability seems important)
$ perl -e 'use Digest::Tiger;my $hexhash =
Digest::Tiger::hexhash("");print $hexhash."\n";'
3293AC630C13F0245F92BBB1766E16167A4E58492DDE73F3
$ php -r 'echo hash("tiger192,3", "")."\n";'
3293ac630c13f0245f92bbb1766e16167a4e58492dde73f3
So, this seems ok.
But mhash_001.phpt and mhash_003.phpt should not fail
(if we want a great PHP with 0 test failed).
As this tests seems to be old ones from old mhash extension,
they probably should be tagged as "expected failed" with a message such
as "Compatibility break with php < 5.4.0"
Best regards.
>
> Thanks anyway,
> Mike
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Specify namespace to include file into.
https://wiki.php.net/rfc/changes_to_include_and_require Since the reaction to the first of the two suggestions was largely negative I've withdrawn it for now to focus on the second of the two changes. In all honestly, these two suggestions should have had independent RFC's from the start. Of the two suggestions this one has the more profound implications to the language even if it is simpler to implement. Thoughts? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
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 falling back or > suppressing the warning/notice (and some do, esp. if they support distinct > sets of arguments). > > Some extensions (and constructors even in extensions that use false for > error) actually force an exception if zpp fails (usually via > zend_replace_error_handling). Quite fair... > But of course this is not an option in user code because: > 1) you can't change the error handling before parsing the parameters and > 2) inside the function you can't tell whether some argument parsing error > occurred. Which is the point. > So E_RECOVERABLE_ERROR in the cases where zpp would return FAILURE seems in > fact the only viable option, even with the disadvantages it has > (centralization and lack of flexibility). So, at that point, then it sounds like we have a spec. Functionality of zpp, with an E_RECOVERABLE_ERROR where zpp would fail. Including any warnings or notices that zpp would have raised anyway (since `"1abc" would work when passed to an int, it should still work, notice intact). > Still, the fact that 100% consistency is not possible is not a strong > argument against at least *some* consistency and in favor of inventing new > rules. Sure. Makes sense. I'll work on a proof-of-concept this weekend. That is if nobody else wants to take it (or beats me to it) :-D. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
2012/3/8 John Crenshaw :
> From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
>> That's why I described the rules when type juggling comes into play.
>> If you send a string number, it is converted from string to number by the
>> type hint. If you send a string of characters and pass it to a int type
>> hinted function - sorry, but it's you who shout yourself with a shotgun, not
>> someone else.
>
> If you are determined to have it this way and cannot yield, then you are off
> topic. This thread was built around the explicit premise that any scalar type
> hint MUST be more forgiving than that, and if we take that away there's quite
> literally nothing more to talk about. Regardless of how anyone feels about
> it, the core devs will never accept what you are insisting on above. (If you
> want proof, look at the prior debates on this issue.) This discussion has no
> purpose unless it can actually accomplish something meaningful, so it started
> by accepting this as a fundamental requirement. Allowing strings to be
> implicitly converted to lower types when possible, regardless of whether the
> reason offends your sense of how code should have been written, is a vital
> compromise in the process of improving the typing in PHP.
>
> John Crenshaw
> Priacta, Inc.
Well, if your type hints gets more forgiving, than it's the same that
was proposed by this
function a((int) $arg) {}
And in this case hints have no meaning at all - it's just other syntax
to do the conversion that now looks like this
function a($arg) { $arg = (int)$arg; }
And please give an answer to this question: If we make hints forgiving
(like type casting), then what we have to do with current array type
hints - it gives error on anything but arrays? Change it back so it
does a conversion to array? Sorry, but it will make a mess in my code,
because I already use hints for arrays and objects and changing their
behavior is just out of the question.
I do not remember devs explicitly saying that something like I
proposed will not be accepted. They said there will be no strict type
hinting or strict variable typing. And they do not want to add another
syntax for type juggling functionality. So, if only i'm not mistaken,
my idea is somewhere in between and doesn't look weird or
extraordinary. It just adds ability to make arguments of the
function/method be more picky about what they can receive.
Maybe i'm mistaken, but I have a distinct impression that many of the
posters will use type hints all over the place if and when they will
be added and base their ideas on that. Don't get me wrong, but the
auto-casting type hints are really needed only when you really write
all the code with type hints in every function/method you define and
you don't want to do manual conversions all the time.
Maybe this is that case when people tend to get min-max and do not
consider the average use? My average use of currently available type
hints is low in WEB environment and only in internal stuff where user
input doesn't make in unchecked. And I had quite a good use of them in
a console daemon where there is no user input at all (only working
with database).
As to breaking some BC when making keywords such as "string", "int",
"float" - that's what the major releases are for. When you introduce
ANY keyword there is a possibility that someone is using it and it
will break his application. It's a risk, yes. But now days refactoring
instruments are very good and changing class name thought out the
project is no big deal really - just make sure people are informed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
On Thu, 08 Mar 2012 13:38:32 +0100, Anthony Ferrara wrote: 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 issue that I personally have to doing that. in ZPP, if you have a parameter that expects an array, and pass it an int, a warning is raised. But then the main body of the function is skipped (the function isn't executed) and the control is passed back to the calling code. 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 falling back or suppressing the warning/notice (and some do, esp. if they support distinct sets of arguments). Some extensions (and constructors even in extensions that use false for error) actually force an exception if zpp fails (usually via zend_replace_error_handling). But of course this is not an option in user code because: 1) you can't change the error handling before parsing the parameters and 2) inside the function you can't tell whether some argument parsing error occurred. So E_RECOVERABLE_ERROR in the cases where zpp would return FAILURE seems in fact the only viable option, even with the disadvantages it has (centralization and lack of flexibility). Still, the fact that 100% consistency is not possible is not a strong argument against at least *some* consistency and in favor of inventing new rules. [...] -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
> 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 issue that I personally have to doing that. in ZPP, if
you have a parameter that expects an array, and pass it an int, a
warning is raised. But then the main body of the function is skipped
(the function isn't executed) and the control is passed back to the
calling code.
To me, that's not right at all. That basically forces all code to use
boolean return error checking. Even if you wanted to use exceptions,
you'd still need to wrap the calling code in an if() statement to see
if a parameter errored. To me, that makes a *direct* port of zpp a
no-go for userland code. Sure, it would be consistent, but it would
also lead to some very hard-to-read code if you wanted to make it
robust:
try {
if (!foo($bar)) {
return false;
}
} catch (FooException $e) {
// We want to ignore it, because we're maintaining the abstraction
and can fix it
bar();
return false;
}
return true;
All that code, just to make a robust function call. Not good in my book.
> the built in php functions are "enforcing" the function signature via
> parsing the parameters through this call.
> so for example the above mentioned substr signature is substr ( string
> $string , int $start [, int $length ] )
> substr("foobar", "123"); // works like a charm
> substr("foobar", 1.5); // works, no warning/notice, although we lose
> precision here,
> substr("foobar", "123 asd"); // Notice: A non well formed numeric value
> encountered
> substr("foo", "bar"); // Warning: substr() expects parameter 2 to be long,
> string given
>
> so if we would implement the scalar typehints in a way to map the signature
> types to the zpp call, then that would mean that the scalar hints are
> consistent across the built-in functions, the documentation, and the
> dynamic nature of the language(as one could argue that the current/future
> implementation of zend_parse_parameters is in line with the dynamic
> casting/type juggling nature of php.
What I do like, is the rules for error or no error. How it determines
if a zval can be passed to a hint of integer. And I also like that it
casts if those rules pass...
However, I think the errors that it throws are far too kind, and can
be quite confusing and lead to difficult to defend code (meaning that
you need 10 or 15 lines of code to defensively call a piece of code).
Instead, I'd much prefer the error level be raised to
E_RECOVERABLE_ERROR, or throw an exception on those typing errors. At
least in user type hints, and preferably in ZPP as well. If the
function is not going to be executed, it should raise a much more
substantial error... Otherwise *that* is going to be more confusing
than anything else IMHO...
> just my 2cents
Thanks for the reply!
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com] > That's why I described the rules when type juggling comes into play. > If you send a string number, it is converted from string to number by the > type hint. If you send a string of characters and pass it to a int type > hinted function - sorry, but it's you who shout yourself with a shotgun, not > someone else. If you are determined to have it this way and cannot yield, then you are off topic. This thread was built around the explicit premise that any scalar type hint MUST be more forgiving than that, and if we take that away there's quite literally nothing more to talk about. Regardless of how anyone feels about it, the core devs will never accept what you are insisting on above. (If you want proof, look at the prior debates on this issue.) This discussion has no purpose unless it can actually accomplish something meaningful, so it started by accepting this as a fundamental requirement. Allowing strings to be implicitly converted to lower types when possible, regardless of whether the reason offends your sense of how code should have been written, is a vital compromise in the process of improving the typing in PHP. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] any blogs?
On Thu, Mar 8, 2012 at 12:22 PM, adit adit wrote: > Let's try to stick only to the internals blogs, ok? If any other php core > devs have some blogs.. > I found also Sara Golemon's blog but is discontinued for some years > now. > > if by internals you only mean "blogs that are talking about the php guts and stuff", then maybe you would be interested in the following blogs: http://derickrethans.nl/ http://www.colder.ch/ http://ilia.ws/ http://schlueters.de/blog/ http://sebastian-bergmann.de/ http://toys.lerdorf.com/ http://blog.experimentalworks.net/ http://php100.wordpress.com/ http://nikic.github.com/ and a few non-english: http://laruence.com/ http://julien-pauli.developpez.com/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] any blogs?
Let's try to stick only to the internals blogs, ok? If any other php core devs have some blogs.. I found also Sara Golemon's blog but is discontinued for some years now. On Thu, Mar 8, 2012 at 1:09 PM, Peter Beverloo wrote: > There is a Planet PHP which aggregates many blogs articles written by > contributors: > http://planet-php.net/ > > Peter > > > On Thu, Mar 8, 2012 at 09:58, adit adit wrote: > >> Hi, >> >> Can you tell me which one of you guys has any blogs on which i can read >> about the php internals? >> I've already subscribed to laruence's , problem is google translate is >> pretty bad at translating chinese >> >> Thanks, >> > >
Re: [PHP-DEV] any blogs?
There is a Planet PHP which aggregates many blogs articles written by contributors: http://planet-php.net/ Peter On Thu, Mar 8, 2012 at 09:58, adit adit wrote: > Hi, > > Can you tell me which one of you guys has any blogs on which i can read > about the php internals? > I've already subscribed to laruence's , problem is google translate is > pretty bad at translating chinese > > Thanks, >
Re: [PHP-DEV] Scalar Type Hinting
2012/3/8 John Crenshaw :
> From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
>
>> > I like that. What should we do if this appears? As it's now - just
>> > throw an "Catchable fatal error" and let the script blow-up? I would
>> > go this far.
>>
>> I think "Catchable fatal error should" be fine and users are familiar with
>> such mechanic because it already exists. Consistency, man, consistency :)
>
> Yeah, I was a huge advocate of this too until recently. I've changed my mind
> though, ironically enough to ensure better consistency.
>
> PHP since 5.3 gives an E_WARNING if you pass poorly-converting scalar data to
> an internal function (For example, substr('foo', 'bar');) This changed my
> mind about the level of error to raise here. I think there's still a good
> argument for E_CATCHABLE_FATAL if you pass something retarded (like a
> resource, or possibly even an array), but I think we should strive as far as
> possible to be consistent with the behavior of scalars passed to internal
> functions. This would allow us to repaint the entire proposal as bringing to
> the language level the same level of scalar typing available internally,
> using the same syntax as the docs (which sounds much more reasonable and less
> politically charged than "Please add scalar typing...again".)
>
> See Ferenc's reply about 30 seconds ago for more details on this...
Well, it may be that way too, but I have to point out that language
level functions are built in and you can't add or remove a type hint
for them. It expects integer and does it's best to make it an integer,
even if it gives some weird result. And backwards compability is an
issue here - _the_ _main_ _issue_. At the language level you have to
maintain that BC and sure if you make zend_parse_params reject strings
where an in should be without any warning - you sure have a rage storm
on the internet that will crush you to peaces.
Adding optional type hinting isn't bound to that BC, because we have
no scalar type hints at all. In 5.3 they added E_NOTICE and E_WARNING
to zend_parse_params. Are you sure they would not change the E_WARNING
to E_ERROR in say PHP 6? Or bump E_NOTICE to E_WARNING? What if
type-juggling rules change? If that will happen - you will have your
type hint behavior change between versions and I think that's not
really a good idea.
So from one point of view it's a nice idea to tie that to
zend_param_parse, but from the other side that does not look like a
good idea. Internals of the engine tend to change more often than the
external syntax and behavior.
>
>> > Type hints are meant to
>> > filter input from external sources
>>
>> Correction, it should read like this:
>> Type hints are _not_ meant to filter input from external sources
>
> That's not really the point though. The issues with external sources
> providing strings comes into play regardless of whether people validated
> their inputs. For example, if (is_numeric($priority) && $priority >= 0 &&
> $priority <= 3) will pass and still leaves you with a string, and that string
> currently works just fine everywhere as if it were an integer. What's more,
> the folks that will be voting on this have made it clear in the past that
> failure to account for type juggling in any such proposal is a deal breaker.
> For many users these inputs can and will trickle down through the code and
> eventually cause frustrating failures if not handled intelligently. You don't
> have to love it, but basically if you want a typing proposal to have any
> chance I think you'll have to support it.
>
> John Crenshaw
> Priacta, Inc.
That's why I described the rules when type juggling comes into play.
If you send a string number, it is converted from string to number by
the type hint. If you send a string of characters and pass it to a int
type hinted function - sorry, but it's you who shout yourself with a
shotgun, not someone else.
I have to repeat it again - type hinting is not for converting and
filtering data. It is not meant to be used in code witch deals with
user input.
You will never write a code like this in 5.3 or 5.4
$v) {
// Do something
}
}
processArray($_POST['some_var']);
?>
Should I tell you why? I think you know. Same goes for hinting
integer, string, float, bool or any other type. To convert data we
have conversion operators and functions like settype. Hints only
should take into account that a validated param can be a number in
string representation and change the type accordingly. But if passed
something different than a number - fail.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] any blogs?
Hi, Yea! I really need that too. One thing I can provide is my own blog, but it's more stuff about bugs in systems, ideas I come around and implementation-possibilities. Nothing really internal. http://www.simonsimcity.net/ Other interesting blogs (all in german): http://www.phpgangsta.de/ http://www.kingcrunch.de/ Here one in english - about web-security, specially with php: http://www.idontplaydarts.com/ They are all writing about some features and less-known things they gather here-and-there about php and web in general. Hope this won't get rated as spam :) I'm following all these blogs and I get some good ideas and hints there. Bye Simon 2012/3/8 adit adit > oh, forgot to mention, i'm subscribed to that one also, is really good & in > english. > Any others? > > On Thu, Mar 8, 2012 at 11:59 AM, Charlie Somerville < > char...@charliesomerville.com> wrote: > > > Nikita's is pretty interesting: http://nikic.github.com/ > > > > On Thursday, 8 March 2012 at 8:58 PM, adit adit wrote: > > > > Hi, > > > > Can you tell me which one of you guys has any blogs on which i can read > > about the php internals? > > I've already subscribed to laruence's , problem is google translate is > > pretty bad at translating chinese > > > > Thanks, > > > > > > >
Re: [PHP-DEV] Scalar Type Hinting
On Thu, Mar 08, 2012 at 11:06:56AM +0200, Arvids Godjuks wrote: > > Type hints are meant to > > filter input from external sources > > Correction, it should read like this: > Type hints are _not_ meant to filter input from external sources +1 What they will do is to catch where input from external sources has NOT been correctly filtered -- but that should be a rare event and indicative of a bug. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] any blogs?
oh, forgot to mention, i'm subscribed to that one also, is really good & in english. Any others? On Thu, Mar 8, 2012 at 11:59 AM, Charlie Somerville < char...@charliesomerville.com> wrote: > Nikita's is pretty interesting: http://nikic.github.com/ > > On Thursday, 8 March 2012 at 8:58 PM, adit adit wrote: > > Hi, > > Can you tell me which one of you guys has any blogs on which i can read > about the php internals? > I've already subscribed to laruence's , problem is google translate is > pretty bad at translating chinese > > Thanks, > > >
[PHP-DEV] any blogs?
Hi, Can you tell me which one of you guys has any blogs on which i can read about the php internals? I've already subscribed to laruence's , problem is google translate is pretty bad at translating chinese Thanks,
RE: [PHP-DEV] Scalar Type Hinting
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
> > I like that. What should we do if this appears? As it's now - just
> > throw an "Catchable fatal error" and let the script blow-up? I would
> > go this far.
>
> I think "Catchable fatal error should" be fine and users are familiar with
> such mechanic because it already exists. Consistency, man, consistency :)
Yeah, I was a huge advocate of this too until recently. I've changed my mind
though, ironically enough to ensure better consistency.
PHP since 5.3 gives an E_WARNING if you pass poorly-converting scalar data to
an internal function (For example, substr('foo', 'bar');) This changed my mind
about the level of error to raise here. I think there's still a good argument
for E_CATCHABLE_FATAL if you pass something retarded (like a resource, or
possibly even an array), but I think we should strive as far as possible to be
consistent with the behavior of scalars passed to internal functions. This
would allow us to repaint the entire proposal as bringing to the language level
the same level of scalar typing available internally, using the same syntax as
the docs (which sounds much more reasonable and less politically charged than
"Please add scalar typing...again".)
See Ferenc's reply about 30 seconds ago for more details on this...
> > Type hints are meant to
> > filter input from external sources
>
> Correction, it should read like this:
> Type hints are _not_ meant to filter input from external sources
That's not really the point though. The issues with external sources providing
strings comes into play regardless of whether people validated their inputs.
For example, if (is_numeric($priority) && $priority >= 0 && $priority <= 3)
will pass and still leaves you with a string, and that string currently works
just fine everywhere as if it were an integer. What's more, the folks that will
be voting on this have made it clear in the past that failure to account for
type juggling in any such proposal is a deal breaker. For many users these
inputs can and will trickle down through the code and eventually cause
frustrating failures if not handled intelligently. You don't have to love it,
but basically if you want a typing proposal to have any chance I think you'll
have to support it.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] Scalar Type Hinting
On Thu, Mar 8, 2012 at 10:03 AM, Arvids Godjuks wrote:
> Hi Simon!
>
> 2012/3/8 Simon Schick :
> > Hi Arvids,
> >
> > I pretty much like this idea as it's more strict. Let me say something
> > to the questions you pointed out here.
> >
> > 2012/3/7 Arvids Godjuks :
> >> I realize that with scalars it's not that straight forward, but
> >> complicating things by adding an auto-cast syntax and so on is just
> >> ridiculous. Hints should stay, well, hints. The only problem we have
> >> is complications of accepting numerical strings or numbers as strings.
> >> And what to do with "null".
> >
> > I'd like to handle it the same way as it's handled with the classes
> > right now. If null is not the default-value you'll get an error when
> > you pass null in there.
> > One thing I'd like opened here: If you define a default-value
> > different than null, should you be able to pass null as well and the
> > compiler will use the default-value?
> >
> >> function a(bool $bool) {}
> >> a(10); // Kill your self against the wall - write a(true);
> >> If you define bool - use the damn bool!
> >
> > I like that. What should we do if this appears? As it's now - just
> > throw an "Catchable fatal error" and let the script blow-up? I would
> > go this far.
>
> I think "Catchable fatal error should" be fine and users are familiar
> with such mechanic because it already exists. Consistency, man,
> consistency :)
>
>
> >> I consider interchangeable only three cases:
> >> 1. Numerical string.
> >> 2. Integers and floats as strings.
> >> 3. Integer and string 0 1 as bool.
> >>
> >> Any other cases should error out.
> >
> > Until now I thought about the weak variable-types as a order ...
> > string, float, integer, Boolean.
> > All Boolean values are compatible be an integer (0 or 1) and all
> > integer are compatible to a float and so on. Do you think it's good to
> > have it this way? This would mean that you could also get a Boolean
> > true as string "1" ... I personally don't like that ... but I don't
> > know where to draw the strict-line.
> > Now think about that backwards. Can a "1" be passed as a parameter
> > that expects Boolean? If yes, I'd keep it consistent in both ways.
> >
> > Bye
> > Simon
>
> That's a good tricky question, I like it.
> Well, I think the lower should work just fine.
> function a(bool $int) {};
> a("1");
>
>
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.
the built in php functions are "enforcing" the function signature via
parsing the parameters through this call.
so for example the above mentioned substr signature is substr ( string
$string , int $start [, int $length ] )
substr("foobar", "123"); // works like a charm
substr("foobar", 1.5); // works, no warning/notice, although we lose
precision here,
substr("foobar", "123 asd"); // Notice: A non well formed numeric value
encountered
substr("foo", "bar"); // Warning: substr() expects parameter 2 to be long,
string given
so if we would implement the scalar typehints in a way to map the signature
types to the zpp call, then that would mean that the scalar hints are
consistent across the built-in functions, the documentation, and the
dynamic nature of the language(as one could argue that the current/future
implementation of zend_parse_parameters is in line with the dynamic
casting/type juggling nature of php.
just my 2cents
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Scalar Type Hinting
> Type hints are meant to > filter input from external sources Correction, it should read like this: Type hints are _not_ meant to filter input from external sources -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Hi Simon!
2012/3/8 Simon Schick :
> Hi Arvids,
>
> I pretty much like this idea as it's more strict. Let me say something
> to the questions you pointed out here.
>
> 2012/3/7 Arvids Godjuks :
>> I realize that with scalars it's not that straight forward, but
>> complicating things by adding an auto-cast syntax and so on is just
>> ridiculous. Hints should stay, well, hints. The only problem we have
>> is complications of accepting numerical strings or numbers as strings.
>> And what to do with "null".
>
> I'd like to handle it the same way as it's handled with the classes
> right now. If null is not the default-value you'll get an error when
> you pass null in there.
> One thing I'd like opened here: If you define a default-value
> different than null, should you be able to pass null as well and the
> compiler will use the default-value?
>
>> function a(bool $bool) {}
>> a(10); // Kill your self against the wall - write a(true);
>> If you define bool - use the damn bool!
>
> I like that. What should we do if this appears? As it's now - just
> throw an "Catchable fatal error" and let the script blow-up? I would
> go this far.
I think "Catchable fatal error should" be fine and users are familiar
with such mechanic because it already exists. Consistency, man,
consistency :)
>> I consider interchangeable only three cases:
>> 1. Numerical string.
>> 2. Integers and floats as strings.
>> 3. Integer and string 0 1 as bool.
>>
>> Any other cases should error out.
>
> Until now I thought about the weak variable-types as a order ...
> string, float, integer, Boolean.
> All Boolean values are compatible be an integer (0 or 1) and all
> integer are compatible to a float and so on. Do you think it's good to
> have it this way? This would mean that you could also get a Boolean
> true as string "1" ... I personally don't like that ... but I don't
> know where to draw the strict-line.
> Now think about that backwards. Can a "1" be passed as a parameter
> that expects Boolean? If yes, I'd keep it consistent in both ways.
>
> Bye
> Simon
That's a good tricky question, I like it.
Well, I think the lower should work just fine.
function a(bool $int) {};
a("1");
Because it's conversion to bool is straight forward. What of the
integer values [-∞, -1] and [2, +∞]? Really tricky question. From one
point of view they are a valid boolean true in the expressions. But
the question here is not if it's a valid boolean, but the fact that we
want our function to be passed with valid data and be more strict that
usual on what is passed to the function/method. So I would like to see
valid boolean values for a hinted argument these:
true
false
1
0
"1"
"0"
Simple and clear.
2012/3/8 Simon Schick :
> Hi,
>
> Just a small addition to what I wrote about handling null ...
>
> function foo(array $d = array()) { var_dump($d); }
> foo(null); // This fails with the message: Argument 1 passed to foo()
> must be an array, null given
>
> As this code fails I'd not expect to change this behavior for the weak-types.
>
> function foo(int $d = 20) { var_dump($d); }
> foo(null); // This should then also fail. Don't care about what's the
> default-value.
>
> Bye
> Simon
>
Totally agree here.
I would even say that if you need a null as default value - that
can't be a type hinted argument, because it already has to accept two
different types of data and code inside has to handle that anyway. The
type hint is essentially useless in this situation. Adding something
like function a(null|string $a = null) kind'a silly and again is
adding unneeded complexity.
2012/3/8 Simon Schick :
> 2012/3/8 John Crenshaw :
>>
>> Conversion the other way is essential. Consider the following URL:
>>
>> http://example.com?foo=1
>>
>> In your PHP script $_GET['foo'] === '1' (a string).
>>
>> In fact, nearly every input to PHP is a string. This is why PHP was designed
>> with some seriously robust type juggling on scalars. Any typing proposal
>> that wants to actually pass a vote is going to have to allow appropriate
>> implicit conversions from string to other types.
>>
>> John Crenshaw
>> Priacta, Inc.
>
> Hi, John
>
> Ok .. the example with the get-parameter is quite good.
> You'll often have the case that you submit a string "0" or "1" and
> want to have it as boolean (f.e. if you have a dropdown with two
> options).
> Please keep in mind not to mix it up with checkboxes as unchecked
> checkboxes won't be sent back to your webserver :)
>
> Bye
> Simon
This is exactly the example for witch type hinting should not be used.
$_GET and $_POST data can be anything - string, number, array (lord,
how many scripts break into fatal errors when you just pass an array
instead of simple string). And passing data from these sources as
params to type hinted functions is a suicide. Type hints are meant to
filter input from external sources - that data should be passed
through filtering and validating layer - only after this you can work
with the data and passing it to typ
Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0
On Mon, 05 Mar 2012 17:52:52 +0100, Remi Collet wrote: > > Using a simple C program (linked against libmash) > > Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39 > > So the result from php <= 5.3.10 seems the right one. Sorry for the delay, but I already explained the issue in the bug report: https://bugs.php.net/bug.php?id=61291 Thanks anyway, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
