Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls
Hi, all At first, Thanks for all your work put in here, Marcio. It gave me a new hint for a possible code-failure. FYI: PhpStorm lately added an inspector for that. Glad to see that move after I heard that the RFC won't pass. https://youtrack.jetbrains.com/issue/WI-14692 Bye, Simon On Mon, Mar 16, 2015 at 6:04 PM, Marcio Almada marcio.w...@gmail.com wrote: Hi, I had no time to reply all emails since yesterday, but right now we are having a voting with 2 yes votes vs 16 no votes. I think we all agree that the RFC won't pass and I'm withdrawing the RFC for the following reasons: 1. The sooner we end the voting period the better for the PHP time line. Since there is no motives to think the voting will flip, the best attitude seems to be a withdraw. 2. We are having a lot of simultaneous voting right now and some voters care to read all the RFCs. The proposed RFC is long, requires testing etc. As it was already rejected, removing it from the list of RFCs in voting phase might be beneficial to the voting process as it reduces the RFC overload we are having because of the feature freeze. 3. Looking at the ML, there are many controversial points that were raised, a lot of them since yesterday. Weather they are debatable or not, all this controversy during voting phases is a bad thing (look at the scalar type hints drama we had). So it's better to just put this to end and move on. Thanks for the votes, I'll try to reply to the emails anyway whenever necessary :) PS: I don't intend to propose this RFC again in the future as I already have other more important RFCs planned for PHP 7.1 Thanks, Márcio
Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
On Tue, Nov 25, 2014 at 11:42 PM, Nikita Popov nikita@gmail.com wrote:
On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz dev@mabe.berlin wrote:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of unknown string values:
class MyFactory {
public static function factory($name) : AdapterInterface {
$class = 'MyNamespace\Adapter\' . $name;
return $class();
}
}
It seems that I did not explain this clearly enough; I apologize. The
variance has to do with the declared type in the function signature
when inheritance is involved, not the type of the value returned by
the function.
For instance, under any of the three options this code will work just
fine:
class Foo {}
class Goo extends Foo {}
class FooFactory {
function create(): Foo { return new Goo(); }
}
As long as the return value from FooFactory::create returns Foo or a
subtype of Foo (such as Goo), then it will work.
The variance that is under discussion in this thread is about the
declared return type in the signature:
class GooFactory extends FooFactory {
function create(): Goo {}
}
In this case, GooFactory::create() declares a return type of Goo,
which is a subtype of Foo [the return type of the inherited method
FooFactory::create()]. This is a covariant return type.
If we choose option 3, the only possible return type for
GooFactory::create is Foo.
Hopefully this clarifies the issue.
Yes it does - thank you for explanation - my mistake :/
Option 3 is a no go not from OOP perspective and from consistency pov as
we already allow this in type-hint:
class FooFactory {
function create(Foo $foo): Foo { return $foo; }
}
class GooFactory extends FooFactory {
function create(Goo $goo): Goo { return $goo; }
}
This is not correct. Parameter typehints in PHP are invariant, so you are
not allowed to change them during inheritance. However LSP violations
during inheritance of *non-abstract* methods currently uses a very low
error level (E_STRICT), so you probably didn't notice. If you try the same
thing with an interface method or an explicitly abstract method, you will
receive a fatal error:
interface I1 {
function foo(A $a);
}
class C1 implements I1 {
function foo(B $b) { ... }
}
This code snippet will result in a fatal error, because it violates type
invariance.
Nikita
Hi, all
As in case of compatibility, I would think about the following:
A return type should be the same, or an instance of a class, extending
the the required class. This way, you have all methods and properties
you would expect.
But as of the parameters, it should be (if we allow anything different
than the class/interface expected), a class or an interface the
parent-one extends or implements. I know, that this one sounds strange
and I can't come up with a practical way. Let me put that one into an
example:
See this example:
class Bar {}
class Foo extends Bar {}
class Goo extends Foo {}
interface ITester {
function create(Goo $foo) : Bar;
}
class BarTester implements ITester {
function create(Bar $foo) : Bar { return $foo; }
}
class FooTester extends BarTester {
function create(Foo $foo) : Foo { return $foo; }
}
class GooTester extends FooTester {
function create(Goo $goo) : Goo { return $goo; }
}
$testers = array( new BarTester(), new FooTester(), new GooTester() );
/** @var $testers ITesters[] */
foreach($testers as $tester) {
$res = $tester-create(new Goo());
/** @var $res Bar (or some instance extending it) */
}
If you have an instance of ITester, you expect it to accept an
instance of Goo. As FooTester is implemented, it will always accept
Goo as instance here - yea - even more. It also accepts Foo instances
as parameter.
But as I expect the create method to return an instance of Foo (and to
make usage of any method, Foo has), the method could also return an
instance of Goo, because it has all the functionality, Foo has, and
even more.
In this example it may sounds weird and confusing, but if you take
these two things apart, it makes actually sense - each for itself.
Is there something I didn't think about, or that would get it to crash?
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
Hi, Andrea I feel more like Sherif Ramadan. Even so I've quite often been in the same situation, I don't think it's a good solution to change something like that, just for the shorthand-operator. I think, the notice is really valuable when accessing the value and doing something with it - like myFunction($_GET['not_set']), but if you're just checking for the existence, I, too, think it is more annoying. My way was to suppress it by adding the silence-operator ;) I always used like: @$_GET['mykey'] ?: ”” I can't come up with a good mid-way right now, but I don't think it's a good way to change this ONLY for the short-hand operator. Bye, Simon On Sat, Sep 6, 2014 at 2:02 AM, Andrea Faulds a...@ajf.me wrote: Good evening, I’ve written an RFC and working patch which attempt to add this feature which has been often requested: https://wiki.php.net/rfc/isset_ternary Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improving the Getting involved section on the php.net website
Hi, Nikita That's right, but the link, Ferenc Kovacs provided, should be added to that list, and this list should be linked on the php.net website on the page Getting involved if you ask me. Bye, Simon On Fri, Jul 25, 2014 at 1:46 PM, Nikita Popov nikita@gmail.com wrote: On Fri, Jul 25, 2014 at 1:43 PM, Simon Schick simonsimc...@gmail.com wrote: Hi, all Inspired by the link http://www.phpinternalsbook.com/, provided by Ferenc Kovacs in the thread [PHP-DEV] About PHP NG document lacking argument, I wondered why we don't gather useful links for internal PHP documentation on the php.net website. At the time I asked for material to contribute to PHP a view months ago, I just found a few posts by Anthony ( http://blog.ircmaxell.com/search/label/PHP%20Source%20Code%20For%20PHP%20Developers%20Series ) and I really would have liked to get a link to something more. There's a collection of various internals resources here: https://wiki.php.net/internals/references Nikita
[PHP-DEV] Improving the Getting involved section on the php.net website
Hi, all Inspired by the link http://www.phpinternalsbook.com/, provided by Ferenc Kovacs in the thread [PHP-DEV] About PHP NG document lacking argument, I wondered why we don't gather useful links for internal PHP documentation on the php.net website. At the time I asked for material to contribute to PHP a view months ago, I just found a few posts by Anthony ( http://blog.ircmaxell.com/search/label/PHP%20Source%20Code%20For%20PHP%20Developers%20Series) and I really would have liked to get a link to something more. Why don't we add links or an internal documentation to the getting-involved-page on php.net http://php.net/get-involved.php? Here is the current text for if you want to contribute as a C developer, what I think is way too less information: Development of the PHP source Someone hoping to become involved in the maintenance and development of the source should be experienced in all of the areas mentioned above, as this creates a strong team; everyone knows how every other part of the project works. You will also need experience in C programming as PHP is written entirely in C. Bye, Simon
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
My main concern about the RFC the way it stands right now is that the current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST for data loss. This results in both consistency issues with casting as well as incompatibility with the dynamic nature of PHP scalars. I know the RFC author (Andrea) disagrees with me about it, but I think we need to find a way to put this into a much wider decision. Probably the most practical thing to do is to put it as a secondary question in the RFC, although those can be tricky. Zeev Hi, all I looked again at the RFC .. Can someone please update the description at the section Conversion Rules? This is quoted from the document: Conversion is allowed only if data-loss does not happen. There are a few exceptions (objects using __toString, strings containing leading numerics, etc). Here's a table of examples. But if you look at the table, strings containing leading numbers are not allowed. And just as a thought: What about objects where the __toString method returns a string like 42? Would that also be accepted as an argument, that just accepts integers? Sounds crazy, but as strings, only containing numbers, are accepted as integer, we have to take a decision here and write it down. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On Fri, Jul 18, 2014 at 7:02 AM, Theodore Brown theodor...@outlook.com wrote: Since I am very much in favour of scalar type hints, I've updated the patch to master and made some minor improvements, and I am re-opening the RFC with the intent to try and get it into PHP 5.7. First of all, this is my first reply on PHP Internals so I hope I am doing it right. :) Thank you very much Andrea for reviving this RFC - I'm really looking forward to using something like this in the next version of PHP to more easily define interfaces and catch unintended errors in my code. However, something I feel it is important to consider is not just how scalar type annotations fit into the history of PHP, but how they fit with the way type annotations are currently used and where the language is going in the future. A recurring comment I've heard in the discussion for this RFC is that strict type hints aren't the PHP way. However, current type hints for classes, arrays, and callables work exactly in this way - they do not allow nulls, no casting is performed, and an invalid type results in a fatal error. If scalar annotations are introduced, many PHP developers (myself included) would naturally expect them to behave in the same way. Another concern I have is in regard to the future. I'm looking forward to the possibility of specifying nullable types in a future version of PHP (see Levi Morrison's Declaring Nullable Types RFC: http://wiki.php.net/rfc/nullable_typehints). If the nullable types RFC is accepted, it would be highly disconcerting if scalar type annotations allowed null values regardless of whether a nullable marker is specified. I don't think that optional strict type annotations will take away from PHP's dynamic nature - they will instead be a valuable feature used in places where it is necessary to strictly validate a parameter's type - this is especially important to ensuring stability and accuracy in the large PHP applications it is my job to maintain. The RFC has already been updated to make boolean type annotations strict. Doesn't it make sense to treat the other scalar types in the same way? Perhaps a future RFC could propose a second (also optional) syntax to specify type annotations which perform casts. However, only having cast-based annotations for scalar types would be a mistake, IMHO. -- Theodore Brown A PHP developer interested in the language's future -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, all First of all, thanks for all your time, you put into this thread! I really am looking forward for a way, all can live with, because this topic has followed the PHP community since the release of PHP 5.1, since the introduction of type hinting for arrays (http://php.net/manual/en/language.oop5.typehinting.php). On an archive for this mailinglist I found threads that are going back to 2005 (http://marc.info/?l=php-internalsm=112397232722668w=2) - Here's a list of all messages found: http://marc.info/?l=php-internalss=type+hintingq=b I've been one of the most active contributors to a thread back in 2012 - not the one giving most productive feedback, but the one giving the most feedback ... (I later saw a statistic of who posted the most mails to the mailinglist within the months of discussion) What I see, we're again stuck with mainly three different opinions, as Paul Biggar pointed out in his post - and he tried to find a solution back then. I would suggest that anyone should read this mail - if you want, read the thread - I haven't had the time for now..: http://marc.info/?l=php-internalsm=124653792412529w=2 In every round we took this topic, there have been new RFCs added ... I don't know if there will be a solution, and my personal favorite is the way, proposed in this RFC here. No casting for the values, just more a validation - a lossy validation. The main reason for this proposal is, that mostly every input to your application will be a string. If it now is a file, a value from the database, the GET and POST parameters, a CURL response - nearly anything. I don't think it makes sense to first cast them before you can use them. I agree, that it feels wrong to have a method, accepting (string)123abc and casting it to (int)123 for internal usage, but it also feels wrong to not let the input (string)123 pass as a parameter to a method accepting integer. This would lead us to casting (f.e. substr(string, (int)$var) ), what again would be like accept anything ($var = abc). I also saw some complaining about that older code may will not work when introducing something here. As of what I think, this should be implemented as an extension to the language as it is now. Old code should be able to run as it is. You may will get a problem when your old code is using a library, that you want to update and the library is using the new syntax ;) Thanks for
Re: [PHP-DEV] [RFC] Named parameters
On Sat, Sep 7, 2013 at 5:29 AM, Matthew Leverton lever...@gmail.com wrote:
The big difference here is if I accept an options array, I understand
that the keys are important and would never break backward
compatibility by changing a parameter name. This isn't a case of if
you don't like it, then don't use it because every function I create
now has to respect the possibility of accepting named parameters,
whether I care about it or not. And I sure hope every function I call
is created by and maintained by somebody with those same
sensibilities.
My opinion is that this really isn't as cool as it sounds, especially
since we have short array syntax. Again, I don't really care if it's
accepted into PHP, but I think it will be more of a minor nuisance for
me than anything else.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi, all
Would it be an option, to change the way named functions are declared?
This way you would mark a function explicitly as having named
parameters.
This increases the learning-curve for PHP, but for me, it seems a
valid approach ...
An example that comes to my mind, is to call this a named function
... Feel free to add a better keyword.
This would then look something like this:
named function functionHavingNamedParamsEnabled($firstParam, $secondParam) {}
function functionHavingNamedParamsDisabled($firstParam, $secondParam) {}
functionHavingNamedParamsEnabled( secondParam = secondValue,
firstParam = firstValue);
// Will work ...
functionHavingNamedParamsDisabled( secondParam = secondValue,
firstParam = firstValue);
// Will not work, because this function is not declared to support named params.
Just an idea for a compromise ..
What I don't like here would be if I'd have to add some cryptographic
char instead of a keyword to the definition of the function.
I, too, am quite neutral to this feature.
Bye,
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Sat, Sep 7, 2013 at 6:55 PM, Matthew Leverton lever...@gmail.com wrote:
The OCD in me shudders to think about now having to parse through
people's code like:
substr('length' = 1, 'string' = 'Hello World');
Hi, Matthew
Wouldn't this just fail, because one required parameter is omitted?
You can just leave out parameters, that have a default-value.
Otherwise it's treated like calling:
substr('Hello World');
// Warning: substr() expects at least 2 parameters, 1 given in php
shell code on line 1
I would return the same, even so the parameter-count is 2, but the 2nd
parameter is missing, but required.
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a time interval to an interval
On Sun, Jul 21, 2013 at 6:14 PM, Jakub Zelenka bu...@php.net wrote: On Tue, Jul 2, 2013 at 8:21 AM, Simon Schick simonsimc...@gmail.com wrote: On Fri, Jun 28, 2013 at 11:20 PM, Derick Rethans der...@php.net wrote: Hey Simon, PS, please don't top-reply as per mailinglist guidelines: http://us2.php.net/reST/README.MAILINGLIST_RULES On Fri, 28 Jun 2013, Simon Schick wrote: On Fri, Jun 28, 2013 at 7:10 PM, Derick Rethans der...@php.net wrote: On Fri, 28 Jun 2013, Simon Schick wrote: I'd like to extend the API of php by a method. Great, let me know if you need any help with the implementation, or when you have any questions on how it currently works. Sorry - I that was easy to missunderstand ;) I thought of providing the idea. But I would happily also try to implement it by my own - just to also have contributed to the php-core. If you could give me a hint where to start - I feel quite lost in the code right now ... even so I read the great tutorials about php-internals provided by Anthony Ferrara. And this may take some time! I've just started with C/C++. Do you think this is an easy task to start? Depending on knowledge of php-internals ;) It's not that difficult, but not the easiest thing either. Basically, you have to do the following steps: 1. in ext/date/lib/interval.c add a function that has two arguments of the timelib_rel_time* type. It should return a *new* timelib_rel_time* structure that has the two intervals added up together. It shouldn't change either of the original timelib_rel_time* arguments. Add the function definition to ext/date/lib/timelib.h too. 2. You can only add two timelib_rel_time* arguments if neither of first_last_day_of, special, have_weekday_relative, and have_special_relative are set. You can'd add a first day of next month to a +5 days interval - it only works for simple y:m:d h:i:s intervals. 3. In ext/date/php_date.c add: a. a new ARG_INFO struct after the one for arginfo_date_interval_construct, b. Add a new method, add after PHP_ME_MAPPING(createFromDateString, date_interval_create_from_date_string,... c. Add a new PHP_FUNCTION(date_interval_add) after the function PHP_FUNCTION(date_interval_format) that takes two DateInterval objects, extract the timelib_rel_time information, call the new function that you've added in step 1, and replace the timelib_rel_time* that is part of the DateInterval object with the returned value. d. Add a forwards declaration to php_date.h after PHP_FUNCTION(date_interval_create_from_date_string); 4. Make sure that the function can be called both as a procedural way (date_interval_add) and an object oriented way (DateInterval-add()). 5. Write test cases and put them in ext/date/tests. That's what I can think off right now. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine Hi, Derick I thought a bit about the changes here and came up with the following feedback: If I can't add intervals where either one is relative, I'd also add a method isRelative() to the class, where the user can check if it's a relative interval. But anyways - what happens if the interval is relative and you try to access one of the public properties? They're all designed for static intervals (let's say +5days), right? What, if the user tries to add a relative to a fixed interval? Should I trigger a E_WARNING, because it's no breaking error, but the value can't be calculated? Bye, Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, here is the patch: https://github.com/php/php-src/pull/390 It's basically what Derick suggested. However there is one issue that needs to be resolved - interval normalization (timelib_do_rel_normalize). The problem is that currently there is no way how to get a base timelib_time from the interval. It means that it's not possible to find out how many days use for normalization. For example if interval1 is 20 days and interval2 is 21 days, then the resulted normalized interval will be 1 month and ?? days... :) There are few solution that come to my mind: 1. no normalization (currently implemented) - this is the easiest solution but the result from the example will be 0 months and 41 days can give interval that has over 31 days... 2. warning if the resulted interval has more than 28 days (February :) ) 3. save base timelib_time with the interval when created and then use it as a base class - it will probably require some sort of copying or ref counting but it seems like the most logical solution What do
Re: [PHP-DEV] Adding a time interval to an interval
On Fri, Jun 28, 2013 at 11:20 PM, Derick Rethans der...@php.net wrote: Hey Simon, PS, please don't top-reply as per mailinglist guidelines: http://us2.php.net/reST/README.MAILINGLIST_RULES On Fri, 28 Jun 2013, Simon Schick wrote: On Fri, Jun 28, 2013 at 7:10 PM, Derick Rethans der...@php.net wrote: On Fri, 28 Jun 2013, Simon Schick wrote: I'd like to extend the API of php by a method. Great, let me know if you need any help with the implementation, or when you have any questions on how it currently works. Sorry - I that was easy to missunderstand ;) I thought of providing the idea. But I would happily also try to implement it by my own - just to also have contributed to the php-core. If you could give me a hint where to start - I feel quite lost in the code right now ... even so I read the great tutorials about php-internals provided by Anthony Ferrara. And this may take some time! I've just started with C/C++. Do you think this is an easy task to start? Depending on knowledge of php-internals ;) It's not that difficult, but not the easiest thing either. Basically, you have to do the following steps: 1. in ext/date/lib/interval.c add a function that has two arguments of the timelib_rel_time* type. It should return a *new* timelib_rel_time* structure that has the two intervals added up together. It shouldn't change either of the original timelib_rel_time* arguments. Add the function definition to ext/date/lib/timelib.h too. 2. You can only add two timelib_rel_time* arguments if neither of first_last_day_of, special, have_weekday_relative, and have_special_relative are set. You can'd add a first day of next month to a +5 days interval - it only works for simple y:m:d h:i:s intervals. 3. In ext/date/php_date.c add: a. a new ARG_INFO struct after the one for arginfo_date_interval_construct, b. Add a new method, add after PHP_ME_MAPPING(createFromDateString, date_interval_create_from_date_string,... c. Add a new PHP_FUNCTION(date_interval_add) after the function PHP_FUNCTION(date_interval_format) that takes two DateInterval objects, extract the timelib_rel_time information, call the new function that you've added in step 1, and replace the timelib_rel_time* that is part of the DateInterval object with the returned value. d. Add a forwards declaration to php_date.h after PHP_FUNCTION(date_interval_create_from_date_string); 4. Make sure that the function can be called both as a procedural way (date_interval_add) and an object oriented way (DateInterval-add()). 5. Write test cases and put them in ext/date/tests. That's what I can think off right now. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine Hi, Derick I thought a bit about the changes here and came up with the following feedback: If I can't add intervals where either one is relative, I'd also add a method isRelative() to the class, where the user can check if it's a relative interval. But anyways - what happens if the interval is relative and you try to access one of the public properties? They're all designed for static intervals (let's say +5days), right? What, if the user tries to add a relative to a fixed interval? Should I trigger a E_WARNING, because it's no breaking error, but the value can't be calculated? Bye, Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a time interval to an interval
Hi, Derick Sorry - I that was easy to missunderstand ;) I thought of providing the idea. But I would happily also try to implement it by my own - just to also have contributed to the php-core. If you could give me a hint where to start - I feel quite lost in the code right now ... even so I read the great tutorials about php-internals provided by Anthony Ferrara. And this may take some time! I've just started with C/C++. Do you think this is an easy task to start? Depending on knowledge of php-internals ;) @Anthony, great thanks for the time writing the tutorials. ( http://blog.ircmaxell.com/search/label/PHP%20Source%20Code%20For%20PHP%20Developers%20Series ) Bye, Simon On Fri, Jun 28, 2013 at 7:10 PM, Derick Rethans der...@php.net wrote: On Fri, 28 Jun 2013, Simon Schick wrote: I'd like to extend the API of php by a method. Great, let me know if you need any help with the implementation, or when you have any questions on how it currently works. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Hi, Anthony Some questions coming up in my mind by reading this RFC: * Will the value of the constant *PASSWORD_DEFAULT* remain unchanged forever? Otherwise this lib, in my opinion, can cause big problems when trying to port an existing system to a newer PHP-version. * Is this a native version of phpass? http://www.openwall.com/phpass/ Sorry if those things have already been discussed somewhere. I was not actively following this list in the last weeks ;) Bye Simon On Tue, Jun 26, 2012 at 5:25 PM, Anthony Ferrara ircmax...@gmail.comwrote: Hello All, I've taken the conversation of the previous simplified password hashing API, and generated a patch and draft RFC for it. The patch isn't ready yet (needs review, cleanup and testing), but it's a start. https://wiki.php.net/rfc/password_hash Please have a look and comment away! Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] RFC - hash_pbkdf2 addition
Hi, Anthony I personally would rename the 2nd parameter to $data as this function is not only meant for creating secure hashes from passwords. Bye Simon On Thu, Jun 14, 2012 at 4:00 AM, Anthony Ferrara ircmax...@gmail.comwrote: Hello all, I've written up a quick draft version of an RFC for pull request 105 ( https://github.com/php/php-src/pull/105 ), to add hash_pbkdf2() to the core implementation. Please give it a look and provide some feedback, so that this can move into discussion as a more defined proposal. https://wiki.php.net/rfc/hash_pbkdf2 Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi, Everyone FYI: If you just want to check something before serving a file to the client, you can also use something called xsendfile. Apache: https://tn123.org/mod_xsendfile/ lighttpd: It's build in :) nginx: http://wiki.nginx.org/XSendfile Idea: Do what you're doing in your php-script and add the header X-Sendfile: $yourFile (nginx is using another header). This header will trigger the plugin and the webserver will serve the file instead of your php-process. I personally use it on my webserver and it works quite fine. Debian has a compiled package called libapache2-mod-xsendfile in version 0.9 Bye Simon On Fri, May 4, 2012 at 2:33 PM, Paul Reinheimer preinhei...@gmail.com wrote: Hi Everyone So, I think we're back to urban legend territory. I've updated the documentation for readfile() to help send more people down the path of checking for output buffering, and disabling that rather than contriving loops with fread(). http://docs.php.net/readfile paul -- Paul Reinheimer -- 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] is_numeric_string an hexadecimal numbers (123 == 0x7B)
2012/4/17 Nikita Popov nikita@googlemail.com
var_dump('123' == '0x7b'); // true
In all other parts of the engine hexadecimal strings are not recognized
[3]:
var_dump((int) '0x7b'); // int(0)
Hi, Nikita
I personally would rather change the type-conversion for strings to integer ...
At least if you force it to do a type-cast (in other words: forcing to
get any valuable integer of that string) ...
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
2012/4/17 Gustavo Lopes glo...@nebm.ist.utl.pt: I think that would be an error. As was mentioned a few months ago when 0b was introduced, no other number format has this behavior. You can't do 123 == 0b10 or 123 == 0876. Extending this hexadecimal oddity instead of eliminating it is inconsistent with the treatment given to those other formats. -- Gustavo Lopes Hi, Gustavo That's something I didn't know of ... if we're doing that, it should, of course, be also be done for the dual system. The only thing I wonder about is the code examples you're giving ... I would expect this to work if we start to change something here: var_dump((int) '0x7b'); // int(123) var_dump((int) '0b011'); // int(123) var_dump((int) '0123'); // int(123) The last example was not mentioned here before but as you set in an example, I did it here as well ... Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers (123 == 0x7B)
2012/4/17 Simon Schick simonsimc...@googlemail.com Hi, Gustavo That's something I didn't know of ... if we're doing that, it should, of course, be also be done for the dual system. The only thing I wonder about is the code examples you're giving ... I would expect this to work if we start to change something here: var_dump((int) '0x7b'); // int(123) var_dump((int) '0b011'); // int(123) var_dump((int) '0123'); // int(123) The last example was not mentioned here before but as you set in an example, I did it here as well ... Bye Simon Hi, all As I saw now in another thread - I forgot the octal number-system which takes 0 as prefix ... and this would change the result of my last example: var_dump((int) '0173'); // int(123) This makes me quite unsure if this should be done the way I proposed ... Here I would not expect it to happen like this. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
2012/4/16 Ralph Schindler ra...@ralphschindler.com I am not quite following. There is no functional difference between class, CLASS, or Class. The parser is case insensitive with regards to keywords, which class or T_CLASS is on of. The code snipped I showed there was from the .phpt test that I had included in the Zend/test code base to ensure it worked and did not break existing tests. As per the namespaced and non-namespaced blocks, I was demonstrating how ::class would resolve names regardless of if it were a FQCN or a short class name. Effectively, you can put ::class behind any type name and it should work as demonstrated. -ralph Hi, Ralph Thanks for clarification. I was missing the backslash before Moo::Class which lead to that thought. As the class-definition for Moo is missing, I think it's an empty class (like Baz) on the root-level defined somewhere else, right? Otherwise this should do something else than guessing the class-name. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
2012/4/16 Ralph Schindler ra...@ralphschindler.com
... PHP does not invoke the autoloader to determine if the class name
actually exists as a declaration somewhere, it simply resolves it according
to some very specific rules (in the case of this patch, carried out by
zend_resolve_class_name()).
If I am within a namespace and am using a short name without a preceding
\, it means the class I am referencing exists in the current namespace.
Whether or not that class exists is irrelevant as my short name can only
mean a class by this name in the current namespace. In this code:
namespace Foo\Bar {
global $foo;
if ($foo $foo instance Bar) {
// ...
}
}
... that you, the developer, intend that your reference to Baz actually
means Foo\Bar\Baz, it can never mean anything else.
So, in a nutshell, there is no guessing going on ;)
-ralph
Hi, Ralph
Agree on that. I'd like to have a comment in the test, specially for
this line where you're checking for non-existing classes. It does not
seem to be obvious what should be tested here (at least it was not
obvious for me). This may make it easier to fix stuff if this test
should fail in future.
I don't know if this here is the right test to put the comment in, but
it's at least relying on something global that may change.
Thanks for giving me a deeper knowledge here :)
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A possible defining characteristic of PHP 6 ( was [off] PHP: a fractal of bad design )
Hi, Michael 2012/4/13 Michael Morris dmgx.mich...@gmail.com It would not be easy. I lack the skills required. And those who have the skills lack the monumental time required. But PHP could do what Adobe did with Actionscript. But it would not be easy or painless. It probably isn't worth it. But the tools are in place and there are RFC ideas out there that, taken together might accomplish a fix. But to what end? I'm currently working on getting into the C (and C++) code for PHP, reading the articles on ircmaxell's blog: http://blog.ircmaxell.com/2012/03/phps-source-code-for-php-developers.html If you want to develop and help the php-community, I think this is a good place to start from. The idea I thought of a long time ago when AS3 came out was to do much the same with PHP. PHP 6 would ship with a legacy mode. In that mode all the existing functions would exist on the root namespace. Turn it off though and those functions disappear and get moved to \Legacy. What actually remains is a remapped function library, perhaps taking advantages of the autoboxing RFC to fake primitives as objects and allow the sort of chaining we see in JavaScript. Not every possible function would be present in this model - libraries such as mysql, mysqli or pdo would be imported into scope. On one side I'd like to have a namespaced core ... but I don't think this would be a good idea to say that no script written for PHP5 will work in PHP6 an vice-versa. But this wouldn't be easy, and I don't think the willpower exists to do it. This is after all a volunteer effort, and there are some things that are simply out of the scope of such efforts. PHP's goal has always been KISS, but the decisions over the last few years run contrary to that. Most onerous is, where Javascript, Java and C have one scope resolution operator - a period - PHP has three (-, \, :: ). The only possible backwards compat fix to that is to set up PHP 6 to not give a rat's ass about which of the three you use. That would restore simplicity, and two of the operators would die off (my money is on :: and \ dying) in common use. The engine implications of that change are likely staggering. This isn't the only structural issue that needs to be addressed either. Taken together they are significant. As to the original post that started this - it is what it is, a blogger wanting attention, stating the obvious and trying to look smart. I'm singularly unimpressed and reading the other responses I'm not alone. It would help to have a conversation about what we want the next major to be like before starting any work on it. Otherwise it will just be another evolution when what PHP really could use is a revolution the likes of which hasn't been seen since PHP 3 came out. But that conversation itself will take time and the scope of what must be done must truly be daunting. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Ability to assign new object to a class property.
2012/4/13 Dmitri Snytkine dsnytk...@ultralogistics.com:
I always wondered why can't we do something like this in php
class MyClass{
private $storage = new ArrayObject();
public function __construct($v){
// whatever
}
// rest of class
}
Why can't we create a new object and assign it to property like this?
Then when a new instance of MyClass is created the $storage variable is
automatically assigned a new ArrayObject.
Somethink like this is valid, possible and commonly used in Java, why not in
php?
Has anyone already asked for this to be valid syntax in php?
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi, Dmitri
Just to add a random thought
When do you expect this code to be executed?
class Foo {
static public $foo = new StdClass();
}
Sorry if this code contains syntax-errors, but I think you'll still
get the point ;)
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
2012/4/14 Ralph Schindler ra...@ralphschindler.com:
Hi all,
There are many different use cases were in code we expect classes names as
arguments to functions as fully qualified names. We do this in ZF a lot
with our Service Location and DI components, but also with our code
reflection API, etc. A more interesting use case I would like to call out
is with PHPUnit, for example in a test, you might find this:
$mock = $this-getMock('A\Namespaced\ClassName');
This becomes cumbersome when you are dealing with lots of strings about lots
of class names. This is also an area where, currently, namespace
declaration and use statements offer no real support.
The patch located here:
https://github.com/ralphschindler/php-src/commit/02210d51851a96d723fbedcfc64cde9f9ae2b22a
... implements the ability for a developer to leverage the file's namespace
declaration and use statements to be able to produce a scalar (string) of
the class name that can be then used, for example, as an argument to a
function elsewhere.
This overloads the class keyword, and by virtue of the existing usage of
class this feature is completely backwards compatible. All existing tests
pass. For example, the above PHPUnit snipped would become:
use A\Namespaced\ClassName;
$mock = $this-getMock(ClassName::class);
Another example with reflection:
use SomeOther\FullyNamespaced\ClassElsewhere as CE;
$r = new ReflectionClass(CE::class);
More examples from the test file:
namespace Foo\Bar {
class Baz {}
var_dump(Moo::CLASS); // Foo\Bar\Moo
}
namespace {
use Bee\Bop as Moo,
Foo\Bar\Baz;
var_dump(Baz::class); // Foo\Bar\Baz
var_dump(Boo::class); // Boo
var_dump(Moo::CLASS); // Bee\Bop
var_dump(\Moo::Class); // Moo
$class = Baz::class; // assign class as scalar to var
$x = new $class;
var_dump($x); object(Foo\Bar\Baz)#1 (0) {}
}
What do you guys think?
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi, Ralph
I really like this feature in general.
One thing I personally dislike in this implementation is the
difference between CLASS and class ... One with and one without
namespaces ...
If we can unify that, this would be a great help in understanding that
feature in future and getting the difference while reading code.
And please don't forget: Code will be written once, maybe rewritten
some times, but it will be read way more times!
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-src is now on git
2012/3/19 David Soria Parra d...@php.net: Hi Internals, The initial migration is done and initial testing was successful. http://git.php.net/?p=php-src.git;a=summary http://github.com/php/php-src Please note that some branches and tags were renamed to make the repository cleaner. Please checkout the repository and play around. I have created a workflow wiki page at https://wiki.php.net/vcs/gitworkflow. There is also an FAQ at https://wiki.php.net/vcs/gitfaq. If you have questions about the workflow or problems let me know. General git questions should be asked in the appropriate IRC channels and mailinglists. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, David Thanks for this great step! As I quickly viewed into the github-repository I recognized the big list of branches ... 52 is quite a big list .. I don't know if someone asked just that before: Are there plans reducing this list? Branches (at least to me) seems to be something like big features, bugfixes or releases that are or could actively be developed in the future. One step is for example closing all the php-4.x branches and leave them as tagged open-end if changes are not merged ... Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-src is now on git
2012/3/19 Kris Craig kris.cr...@gmail.com: Hey, Could we modify the workflow to recommend using the --no-ff switch when merging in a feature branch? This is by and large the recommended approach as it preserves the feature branch's commit history, making it *much*easier to sort through complex features that contain numerous commits. --Kris Hi, Kris I'd instead suggest to execute the following command in the git-repository: git config --add merge.ff false Then you do not have to add --no-ff to every merge-command you're doing. You could even set it per branch if you want :) (just to round it up ..) http://stackoverflow.com/questions/2500296/can-i-make-fast-forwarding-be-off-by-default-in-git Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-src is now on git
2012/3/19 Kris Craig kris.cr...@gmail.com: Simon, Yes that's a great recommendation and it should definitely be included IMHO! However, the merge.ff option is relatively new and is not available in many older Git clients that are still in use. So the --no-ff tag will still probably be necessary for some people. Perhaps we should recommend both, or would that make things too confusing? --Kris Hi, Kris Don't really know ... Do you know which version of GIT is the first who implements this feature? Would it be a problem to require an update or the people should find their own solution? I think that people who don't know much about GIT or are just starting with GIT should be fine with that as they haven't done much with that or just installed the latest version. The only problem I can see here is that some linux-distributions (Debian for example) tends to keep old versions in their repositories ;) Anyways ... I think it would be max-information to link the stackoverflow-discussion there if someone has a question to that. But this (of course) has to be describe it in a easy understandable way :) and I think that's the most dificult part. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
2012/3/18 John Crenshaw johncrens...@priacta.com: 2. Unenforced type hinting: This almost happened in 5.4, but eventually got pulled. More interestingly, the *community* rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...). Hi, John Thanks for clarifying that way. I understand why some people want to have that ... to please really all people ... make a solution that fits for EVERYONE. But that would (on the other hand) cause way more confusion if you're working with different projects (using Sebastian Bergmanns example) ... one implementing this the way we would implement Strict type hinting - because that's what he wants ... and another one is implementing it as Casting weak type hinting ... and so on. I know that the user still has to add some code, but I don't like the fact to have additional type-hinting that's just doing nothing - and the user is then adding it if he wants. I'm still for the 3rd solution as it is most likely the current type-hint and is not that strict as the first solution. Just to have it consistent. What I like most here: All parameters that can be converted to the wanted format without loosing something are accepted, all other will stop the execution of the script. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
2012/3/18 Simon Schick simonsimc...@googlemail.com: 2012/3/18 John Crenshaw johncrens...@priacta.com: 2. Unenforced type hinting: This almost happened in 5.4, but eventually got pulled. More interestingly, the *community* rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...). Hi, John Thanks for clarifying that way. I understand why some people want to have that ... to please really all people ... make a solution that fits for EVERYONE. But that would (on the other hand) cause way more confusion if you're working with different projects (using Sebastian Bergmanns example) ... one implementing this the way we would implement Strict type hinting - because that's what he wants ... and another one is implementing it as Casting weak type hinting ... and so on. I know that the user still has to add some code, but I don't like the fact to have additional type-hinting that's just doing nothing - and the user is then adding it if he wants. I'm still for the 3rd solution as it is most likely the current type-hint and is not that strict as the first solution. Just to have it consistent. What I like most here: All parameters that can be converted to the wanted format without loosing something are accepted, all other will stop the execution of the script. Bye Simon Hi, All Just to add an example why I want a more strictly type-check here as we have in the current type-juggling: http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rssutm_medium=rssutm_campaign=an-xss-vulerability-in-the-making Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
2012/3/18 Adam Jon Richardson adamj...@gmail.com: On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick simonsimc...@googlemail.comwrote: Hi, All Just to add an example why I want a more strictly type-check here as we have in the current type-juggling: http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rssutm_medium=rssutm_campaign=an-xss-vulerability-in-the-making I see the example given as one of poor validation, not a reason for more strict type checking in a dynamic, weakly typed language. One could: - use a regex - setting the third argument (strict comparison) of in_array() to true -OR- looping through the array and checking equivalence with === - ensure the type juggled value (the integer form) was returned and used rather than using the original string I actually like the conversation on scalar type hinting, and I've even offered some ideas for integrating a form of it, too. However, poor input validation is not one of the reasons that I would use to justify its inclusion. The goal of proper input validation should be to account for page requests that include invalid data and provide appropriate feedback within the natural flow of the application. Erring out when calling a more strongly typed function at runtime does not provide this type of application flow. Adam Hi, Adam I totally agree that type-hinting should not cover what the programmer should do for validating the given input ... But I just wanted to point out that this is something the author (and I) would never expect to happen ... in_array(123abc, array(3, 7, 123, 28)) === true But that's another thing :) I just wanted to point out that I don't want to have the string 123abc accepted as an integer :) Anyways ... This thread should be a discussion about the whole concept, not the details. Sorry for getting off-context here. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [benchmarks] Still under active development?
Hi, All I got some feedback from Paul Biggar and Nuno Lopes (the founders of the RFC https://wiki.php.net/rfc/better_benchmarks) and both want to give it to a new maintainer. I fond quite a bunch of possible starts but don't know which one would be the best to start with or if we should start from scratch and take the best of each one. Do you have time to support this project by giving ideas, writing code, helping to find good principles, code review or something else? Bye Simon 2012/2/19 Simon Schick simonsimc...@googlemail.com Hi, All I found one RFC in the php-wiki that requests a better php-benchmarking script ... Is this still under active development? Because I'd like to add some scripts to the list of currently existing benchmarks: http://www.free-webhosts.com/php-benchmark-script.php Updated link for current benchmark: http://svn.php.net/viewvc/php/php-src/trunk/Zend/bench.php?view=markup http://www.phpclasses.org/blog/post/117-PHP-compiler-performance.html http://www.php-benchmark-script.com/ http://code.google.com/p/dbench/ http://www.phpspeed.com/ (as the forum seems to be death I overtook it at GitHub: https://github.com/SimonSimCity/PhpSpeed) Some of these benchmarks listed here are php-only and others are also testing the implementation of php and therewith also the webserver. There are also quite a bunch of other benchmarks that should be tested if the values are still the same (some of them are containing some crazy comparison): http://www.phpbench.com/ Some simple tests against other languages: http://shootout.alioth.debian.org/ http://m-fernandez.developpez.com/articles/php/bench/ More Ideas: http://dan.doezema.com/2010/10/bench-php-class/ https://github.com/veloper/Bench http://pear.php.net/package/Benchmark/redirected How to analyze tests: http://www.devshed.com/c/a/PHP/How-to-Benchmark-PHP-Scripts-for-Speed/ http://talks.php.net/show/froscon08 Please give me a feedback if the benchmark stuff is still in work and if one of the links has interesting stuff for it. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: laltin
2012/3/16 Ángel González keis...@gmail.com On 16/03/12 18:45, Lütfi Altın wrote: I want to read PHP source and help PHP for further development. You don't need a svn account to read the php source. You can just download the source from http://php.net/downloads.php#v5 view the development version at http://svn.php.net/viewvc/php/php-src/trunk/ Or download through svn with svn checkout https://svn.php.net/repository/php/php-src/trunk/ You can then provide patches through the Bug Tracking System at https://bugs.php.net/ And only after having proved that you are a valuable contributor, would be appropiate to request svn access. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, Lütfi If I got it right, the community decided to switch all projects to git soon (only php-src is missing: http://git.php.net/). They will also connect their repositories to github. After that it should be possible to forge the repository, change something and start a pull-request. This will then send an email to a group of people who will look through the changes and give you feedback. Please correct me if I got it wrong. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Scalar-type-hinting - which way is the best to go?
Hi, all Today I read a post around that: http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think As some of us are leading to the 3rd and some to the 4th or other ways described in here (I think we can simply exclude the first one ...) Would it be an option (to get this moved forward) to let people vote which way they like most (or which comes closest to their best-solution)? I pretty much like the 3rd way ... the only thing I see that has not been discussed enough is how to handle integers on 64bit and 32bit installations. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Randomize hash-function in php
Hi, All I just came around that talk a couple of days ago .. http://www.youtube.com/watch?v=R2Cq3CLI6H8 I don't know much about hash-maps and internal php-stuff at all, but they say that the fix provided in 5.3.9 (and 5.4.0) is more a work-around than a fix ... Would it be an option to provide a real fix in PHP 6.0? They got the feedback that this will take some time and is not trivial, but we have a good time before PHP6 and can also break backwards compatibility for php-plugins if really necessary. As they said in the movie, PHP seems to have the algorithm DJBX33A implemented as Ruby. So as they're so proud of the fix provided by the Ruby-Team, may we can use that for PHP as well :) https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815 This is not much because some attacker can do something, but what if you have a real-world-application that (for some reason) build up an array that just will blow up because of that? I haven't experienced that until now, but it's possible ... Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Randomize hash-function in php
Hi, All I just came around that talk a couple of days ago .. http://www.youtube.com/watch?v=R2Cq3CLI6H8 I don't know much about hash-maps and internal php-stuff at all, but they say that the fix provided in 5.3.9 (and 5.4.0) is more a work-around than a fix ... Would it be an option to provide a real fix in PHP 6.0? They got the feedback that this will take some time and is not trivial, but we have a good time before PHP6 and can also break backwards compatibility for php-plugins if really necessary. As they said in the movie, PHP seems to have the algorithm DJBX33A implemented as Ruby. So as they're so proud of the fix provided by the Ruby-Team, may we can use that for PHP as well :) https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815 This is not much because some attacker can do something, but what if you have a real-world-application that (for some reason) build up an array that just will blow up because of that? I haven't experienced that until now, but it's possible ... Bye Simon
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
2012/3/12 Lazare Inepologlou linep...@gmail.com
function set_check_box_state( bool state = false ) { ... }
set_check_box_state( null ); // null will be converted to false here...
Therefore, this cannot work, unless the default value becomes null, which
is against the requirements. What I suggest is something like this:
function set_check_box_state( bool? state = false ) { ... }
set_check_box_state( null ); // works fine
In my opinion this is much clearer, as it separates the notions of the
type
and that of the default value.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Hi Lazare,
I'd like to keep the accptance of null as it is for classes and arrays.
Here's an example I wrote earlier:
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 new
feature we're discussing here.
function foo(int $d = 20) { var_dump($d); }
foo(null); // This should then also simply fail. Don't care about
what's the default-value or defined type.
function foo(int $d = null) { var_dump($d); }
foo(null); // And this should pass it through, providing the
NULL-value in the function.
function foo(int $d = 20) { var_dump($d); }
foo( (int)null ); // This can provide 0 as the programmer forcing it
to be an integer before putting it into this function-call.
I would personally not like to give the user the option to set a
null-value if it's not the default.
But .. I don't wanna screw up your idea.
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
2012/3/10 Pierre Joye pierre@gmail.com hi Pierrick, I would rather go with php-next. The amount of changes are not safe for a now very stable version in 5.3 and 5.4 (same code base), while the code could be nicer as you did it in trunk. Cheers, On Sat, Mar 10, 2012 at 5:57 PM, Pierrick Charron pierr...@webstart.fr wrote: Hi all, As you may know, the cURL PHP extension is currently not in sync (featurewise) with the original libcurl. I started to work on it to make it as close as possible from the original libcurl. I also did some cleaning to make it easier to maintain (ordered all the constants/features by their libcurl version). All those changes were made on the trunk branch only. I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. So please, test the new version of the curl extension, review the code, and give your input on either or not those changes should be merge on 5.4.1 Thanks Pierrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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 Hi, all I'd like to see a new interface for curl in php ... I have no special idea how, but I heard from several people that they pretty much don't like the way curl is implemented in php. May we have a little brainstorming around that .. may some other language has some good implementation ... When I see the list of constants, I feel like that is way to much ... this could be grouped somehow ... Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
2012/3/10 Reindl Harald h.rei...@thelounge.net: Am 10.03.2012 18:28, schrieb Simon Schick: I'd like to see a new interface for curl in php ... I have no special idea how, but I heard from several people that they pretty much don't like the way curl is implemented in php. many other people would not like to break their perfect working code! Hi, Reindl I do not mean to drop the implementation as it is right now - but think of something different for the future. If there would be an additional implementation it would probably be like mysqli, where you have an oop-implmentation and a non-oop. Bye Simon -- 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
Hi, all At first, many thanks to Anthony for writing the code! 2012/3/9 Anthony Ferrara ircmax...@gmail.com fooi(1.5); // int(1) Here an E_NOTICE would be a minimum as we are modifying the data. I'd like to see an E_RECOVERABLE_ERROR as well. You should use float-casting instead if you want to allow this as well. And this should be the only difference between int and float. (Float will of course also accept strings like 1.5) One more question I have to raise here ... is .5 a valid float? Or do I have to change it to 0.5 to get it valid? 2012/3/9 Nikita Popov nikita@googlemail.com a) I'm not sure that we really want to accept '123abc' on an int cast with just a notice. In my eyes that is clearly malformed input, which should not be accepted. In my opinion '123abc' is not a valid integer as well. 2012/3/9 Nikita Popov nikita@googlemail.com b) The bool cast rules also accept lots of input with dataloss. At least the fact that abc is considered a valid bool seems odd. I think all values that are not castable to an integer 0 or 1 should fail in Boolean. I pretty much like the rest. But as we are allowing classes implementing __toString() we should also think about updating the array type-cast - but that's another discussion that we can pick up later. Bye Simon -- 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
2012/3/9 Lazare Inepologlou linep...@gmail.com
Yes, like that, only better. Since automatic type casting is central in
PHP, as this is evident after all this discussion, I believe that it
should
be better supported. There are two thinks that I would like to see here:
1. No more magic methods, please.
2. It should cover (eventually) casting to and from any type.
:-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
Hi, Lazare
As you mentioned it in another thread, I like the idea of C# you described ...
Draw a line between explicit and implicit casting.
What the current idea would be is an implicit casting (as I understood
it right).
Let me just repeat your examples:
2012/3/7 Lazare Inepologlou linep...@gmail.com
function test_float( float test ) { ... }
test_float( 1.0 ); // ok
test_float( 1 );// implicit int to float cast, ok
function test_array( array test ) { ... }
test_array( array() ); // ok
test_array( 1 );// no implicit int to array cast, error!
test_array( (array)1 ); // explicit int to array cast, ok
An explicit type-cast should be always possible and try to get the
very last bit of useful information out of the given bunch. Here it
makes sense to have magic functions for integer, float, string etc.
But as we're here talking about an implicit casting when passing a
class to a function, I don't like the idea of calling the
magic-functions if you paste a class in here as it changes the content
of the variable. This won't make it easy passing a variable as
reference. If you just switch to another type, you can afterwards do
whatever you was able to do before.
Bye
Simon
--
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
2012/3/9 Lazare Inepologlou linep...@gmail.com
Type casting combined with passing by reference is problematic in many ways.
Just an example:
fuction foo( string $buffer) { ... }
foo( $my_buffer );
Here, $my_buffer has just been declared, so it is null. Should this be an
error? I don't know! So, I think that that passing by reference should not be
(immediately) supported.
Hi, Lazare
This should at least throw an E_NOTICE :) And also an error as NULL is
not allowed here.
Let me modify your example:
fuction foo( string $buffer = NULL) { ... }
foo( $my_buffer );
This would only raise the E_NOTICE because the variable has not been declared.
Or would you say that NULL is equal with an empty string (talking
about implicit casting)? I would not like that, but if, don't let it
be (int)0 or (bool)false as well.
Bye
Simon
--
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 miche...@gmail.com 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] hash / tiger regression in PHP 5.4.0
2012/3/8 Remi Collet r...@fedoraproject.org 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.
2012/3/8 Sebastian Bergmann sebast...@php.net: 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.
2012/3/8 Sebastian Bergmann sebast...@php.net: 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] Scalar Type Hinting
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 arvids.godj...@gmail.com:
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 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
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
2012/3/8 Simon Schick simonsimc...@googlemail.com:
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 arvids.godj...@gmail.com:
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 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
--
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 johncrens...@priacta.com: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Hi, It got quite around that because we have some RFCs to this where the functionality seems to be defined as the people thought it should be. Otherwise they can raise their hands and write a mail that they want to update the RFC - but as there's no one doing that, I think we're quite close to what we wanted. Take a look at it and feel free to add your ideas in this thread. https://wiki.php.net/rfc/parameter_type_casting_hints https://wiki.php.net/rfc/object_cast_to_types Bye Simon 2012/3/6 Kris Craig kris.cr...@gmail.com Wow no offense, but your timing is terrible, Raymond! We've been going back and forth on this for the past couple weeks now, though the discussion has quieted for the moment. I would suggest you go through some of the recent posts on Internals. Right now there basically is no solid consensus on this issue, though some of us have been working to change that. But as it stands now, I'm not aware of any plans to introduce expanded typing of any kind in the foreseeable future. And even if we did, I highly doubt it would happen before PHP 6. --Kris On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving xwis...@gmail.com wrote: Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
Hi, Lazare
This is something not obvious, at least for me, and should be handled in
the function itself.
Here it would be better to update the function *add()* that you could also
pass mixed and it will try to generate a *DateInterval *out of that or
whatever.
But that's another RFC.
Type-juggling applies just to weak-types like string, int, float and
boolean. I don't like to have this for resource, array or class excepted
they are compatible to each other (like array and SplFixedArray,
SplObjectStorage, ArrayIterator, ...)
If you have to do something special to get the expected type (like creating
a new object) type-juggling would not be the good-way to go.
Bye
Simon
2012/3/4 Lazare Inepologlou linep...@gmail.com
I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)
Why not? I would definitely like something like that, in the future. Here
is an example:
class DateTime {
...
public function add( (DateInterval) $interval ) { ... }
...
}
$date = new DateTime;
$date-add( 'P3D' ); // string to DateInterval casting
$date-add( 3600 ); // int (seconds) to DateInterval casting
Personally, I find this to be much closer to free type-juggling PHP style
than the current implementation with type hints (
http://www.php.net/manual/en/datetime.add.php).
[ Actually, I would prefer even type hints to work like this. Check if the
passed argument if of the correct type and, if not, try to cast it. Failure
to do so will lead to the E_RECOVERABLE_ERROR as today. ]
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/4 Paul Dragoonis dragoo...@gmail.com
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)
- Paul.
On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
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 commit).
https://wiki.php.net/rfc/parameter_type_casting_hints
Please provide feedback here on the implementation and RFC topics.
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
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hi, Lazare
In your examples you are accessing an maybe non-existing array-key.
This will raise an E_NOTICE. See the note below this example:
http://php.net/manual/en/language.types.array.php#example-85
Maybe you also want something like that:
isset($x) ? (is_null($x) ? null : (int)$x) : null
But let's discuss that in a different thread.
Bye
Simon
2012/3/5 Lazare Inepologlou linep...@gmail.com
Anthony,
I still don't like the null-as-a-default-value solution. I find it
confusing.
I know that something similar appears in class type hinting, but:
1. Class type hinting does not do casting (yet).
2. Apart from null, no other value could be placed anyway. (Even that is a
little bit wrong as null belongs to a different type than the hinted
class).
---
I have a different proposal. The argument type hinting/casting should not
be bothered with that at all. Instead, we could expand the type juggling
system a little bit, with the introduction of a special type of casting
that leaves null unchanged. Something like this:
(int?) $x
which should be strictly translated to the following, without any way to
change that behavior by any type casting overload system:
is_null($x) ? null : (int)$x
Examples:
(int?) 13 // 13
(int?) '' // 0
(int?) 0// 0
(int?) null // null
(int?) '342.3Test' // 342
I can think of many real world scenarios that could benefit from this. The
first that comes to my mind is reading from a database, in cases that the
value of null totally different than the value of 0.
$parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different things
here...
A second example is reading from the query string:
$id = (int?) @$_GET['id']; // the error-silencing operator will return
null on error.
Thoughts?
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Anthony Ferrara ircmax...@gmail.com
Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 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
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
(c) seems the most sane option ot me as well.
2. Should (array) be supported? Perhaps. So at that point, foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value (if
possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a value
to a function/method call.
snip
5. What about BC breaks? Well, this entire patch (up to this point)
wouldn't require one. it's only adding the casting functionality
(which is not implemented today), so no problem. Existing code would
still function fine.
This is something that should be highlighted. I've seen a lot of folks
claiming type hinting is viral, and the arguments make no sense to me.
What your patch is offering is _opt_in_ type casting of function/method
arguments. You don't _have_ to write your functions or methods using
them, and for those who do, it should have no side effects on code
calling it.
I would _LOVE_ to see this as part of PHP.
--
Matthew
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hi, Lazare
Sorry, I've only looked at your first array-example :)
Bye
Simon
2012/3/5 Lazare Inepologlou linep...@gmail.com
In your examples you are accessing an maybe non-existing array-key
Yes, this is why I used the error silencing (@) operator. But anyway, it
is irrelevant to the whole proposal.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Simon Schick simonsimc...@googlemail.com
Hi, Lazare
In your examples you are accessing an maybe non-existing array-key.
This will raise an E_NOTICE. See the note below this example:
http://php.net/manual/en/language.types.array.php#example-85
Maybe you also want something like that:
isset($x) ? (is_null($x) ? null : (int)$x) : null
But let's discuss that in a different thread.
Bye
Simon
2012/3/5 Lazare Inepologlou linep...@gmail.com
Anthony,
I still don't like the null-as-a-default-value solution. I find it
confusing.
I know that something similar appears in class type hinting, but:
1. Class type hinting does not do casting (yet).
2. Apart from null, no other value could be placed anyway. (Even that is
a
little bit wrong as null belongs to a different type than the hinted
class).
---
I have a different proposal. The argument type hinting/casting should not
be bothered with that at all. Instead, we could expand the type juggling
system a little bit, with the introduction of a special type of casting
that leaves null unchanged. Something like this:
(int?) $x
which should be strictly translated to the following, without any way to
change that behavior by any type casting overload system:
is_null($x) ? null : (int)$x
Examples:
(int?) 13 // 13
(int?) '' // 0
(int?) 0// 0
(int?) null // null
(int?) '342.3Test' // 342
I can think of many real world scenarios that could benefit from this.
The
first that comes to my mind is reading from a database, in cases that the
value of null totally different than the value of 0.
$parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different
things
here...
A second example is reading from the query string:
$id = (int?) @$_GET['id']; // the error-silencing operator will return
null on error.
Thoughts?
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Anthony Ferrara ircmax...@gmail.com
Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 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
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
(c) seems the most sane option ot me as well.
2. Should (array) be supported? Perhaps. So at that point,
foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to
array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value
(if
possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a
value
to a function/method call.
snip
5. What about BC breaks? Well, this entire patch (up to this point)
wouldn't require one. it's only adding the casting functionality
(which is not implemented today), so no problem. Existing code
would
still function fine.
This is something
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hi, Anthony
At first, thanks for your great work!
As I have to learn C and C++ from scratch it was quite a good help to have
someone like you pushing it forwards.
I like having the casting exactly in the definition of the function, even
if it just saves the 6 characters. You have all information in one place.
As you added array as type-cast ... is it now possible to put an instance
of ArrayIterator in there? Would the following code work out?
function foo((array) $a) { /* do something */ }
$bar = new ArrayIterator( array() );
foo($bar);
I'd pretty much like the idea to break the script if you pass a value that
would produce a E_WARNING in type-casting.
But here comes another question for type-casting ... is it meant (as php
supports type-juggling) to get something of nearly every value (like to
parse foo to an integer) or is it more meant like getting a value in
another type and you should know that it is compatible with this other type
(like only parsing 1 to an integer)?
If it's meant like the last, then I'd may look for another way to implement
this ... Then this code would may make sense (not really to me, but it
would work out) ...
function foo((int) $i) { /* do something */ }
foo( (int)foo ); // would work as type-casting tries to get the last bit
of valuable data out of the passed information
foo( foo ); // would fail because the passed value is incompatible with
an integer
foo( 10 foo ); // I personally would like to let it fail ... But maybe we
should let it be parsed to (int)10 silently ...
foo( 1 ); // would work
As far as I know, this is the behavior used for internal function calls -
isn't it?
I hope you'll get the difference ;)
I don't know if this difference actually applies to type-juggling and
type-casting ... As I understand type-juggling is just transforming it into
the other type if it can get something useful out of the content (like
parsing 1 or 10 foo to an integer but not foo). Maybe type-juggling
uses the same functionality as weak-comparison ...
Bye
Simon
2012/3/3 Anthony Ferrara ircmax...@gmail.com
Hey all,
Here's a much more robust and updated patch (actually, it seems good
to go to me, but needs significant review)...
https://gist.github.com/1963999
One potential issue is that it requires an API change to
zend_verify_arg_type (which appears to only be called in zend_vm_def.h
- and by generation zend_vm_execute.h)... Otherwise, it's functional
from my perspective...
Here's what's implemented:
The following cast syntaxes to the parameter type hints:
(int)
(float)
(bool)
(string)
(array)
(object)
Basically, they behave exactly as the normal cast works. So it won't
error except in odd edge cases (for example, passing StdClass object
into (string)...
So, based on that:
function ((int) $i) {}
is identical to:
function ($i) {
$i = (int) $i;
}
Additionally, the last 2 are a bit more interesting, as they will cast
it to an array/object if necessary.
To be honest, I'm not as sold on this version (I built it as a POC,
but to see how useful it is). It feels like it's not doing enough.
All it really does is save 6 characters.
Instead, I think I'd rather see it check for a clean cast, and at
least throw an error on unclean cast (casting (int) foo in this
context). 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 questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
2. Should (array) be supported? Perhaps. So at that point, foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value (if
possible) as well.
4. What about consistency? Well, there currently is no consistency.
Internal function parameters behave one way, and explicit casts behave
another. And even more confusing implicit casts behave yet another
way ($a + $b). So to implement this, we'd need to be
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make sense
(at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.cr...@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com
wrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the
way.
And in 20 minutes I can hack into that application 20 different ways.
This isn't really PHP's fault...or is it? By deliberately catering to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the unwashed masses argument, and yet, the security geek
in me sometimes questions how good this is.
(Before someone flames me, I'm not really saying that we should scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is Don't do this! it's good enough for
most of them.
Other times the decision was made to just deprecate a feature and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion developers.
No, you've misunderstood. The average new not-really-a-developer has no
concept of security. Every SQL query they write is vulnerable to
injection.
Every echo exposes their site to XSS vulnerabilities. Every form is
vulnerable to CSRF. If they did anything with files in their script I may
be able to read arbitrary files to their server and/or upload and execute
arbitrary scripts. If they used eval() or system() I can probably execute
arbitrary shell code and take control of the entire site. If their server
is badly configured I could capture the entire machine.
This isn't a question of keeping software updated and not using
deprecated
functions, this is a question of discipline that is completely missing
among the unwashed masses as you call them. The intuitive way to handle
many of the most common PHP tasks is also the completely insecure way.
Philosophically, I wonder if we do a great disservice by encouraging
these
people to tinker with code at all. We do so knowing (or at least we
should
know) that anything they create will inevitably be hacked. We fuel the
widespread security
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, All
Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:
foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
Now here a rule I thought could be acceptable to differ between the
type-hint for classes and arrays and this notation:
If the type is wrapped in parentheses, the system will try to convert the
given value. Otherwise it will handle it strict.
Strict is currently only available for classes and arrays, and I don't want
to get more things in this list (excepted by resources, what is the last
what would make sense here).
Dynamic (the one with the parentheses) could then well be something like
boolean, integer, float, string and array. Array is also in this list as I
would like to have an option to give an object in here that implements all
interfaces that makes an object accessible as an array - for example
ArrayIterator.
Bye
Simon
2012/3/2 Simon Schick simonsimc...@googlemail.com
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make
sense (at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.cr...@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com
wrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody
useful
web application, breaking 10,000 Computer Science rules along the
way.
And in 20 minutes I can hack into that application 20 different
ways.
This isn't really PHP's fault...or is it? By deliberately catering
to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the unwashed masses argument, and yet, the security
geek
in me sometimes questions how good this is.
(Before someone flames me, I'm not really saying that we should
scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is Don't do this! it's good enough for
most of them.
Other times the decision was made to just deprecate a feature and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi, all It's really hard to make a decision here because you also have to care about big companies in one way, that have not updated to PHP 5.3 now ... But instead of that I read some posts from November last year that they have PHP6 in their control-panel, what is basically PHP 5.4 beta ... One or two years is way to short if you'd ask me. A major release should be supported with all kind of bug fixes for min. 3 years after a new release has been brought out. Specially if it's a wide-spread language like PHP that has been implemented by such big and lazy companies. Please do not misunderstand that. Lazy is not meant in the way that they are doing nothing, but that it takes way more time as it does for me installing a new PHP version on my 2-3 servers. Bye Simon 2012/3/2 Adam Harvey ahar...@php.net On 2 March 2012 21:05, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Fair enough. Option #1 seems the most appropriate then. The others seem too drastic to implement with such short notice. +1. We can't drop bug fixes immediately without warning, and I don't think the overhead of backporting security fixes is too onerous for one additional year, particularly in light of how significant a release PHP 5.3 was. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Intentions
Hi, Adam I just get the feeling that this is exactly what we're currently discovered in some other threads in this mailing-list. We're now getting more and more closer to what we really want and a good way to write it the PHP-way. Please try to get a rough overview over the last messages we wrote on the following threads: * [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting) * RE: [PHP-DEV] Scalar type hinting The second one is quite big ;) and sometimes the messages contain only religious stuff like This will never be, go away - but that's just because we're in discussion. Like the wind blows. But I think we'll get to list of rock-solid possible solutions here. I think we'll soon create a RFC for that and discuss it after we have it on one paper. I would kind-of like the idea to add the *scalar *type in addition just to avoid objects or arrays in there, but let's look how the discussion goes. Bye Simon 2012/3/1 Adam Jon Richardson adamj...@gmail.com First, phpunit is a fantastic tool! I'm thankful for your contributions to all of the PHP community (especially with the code coverage capabilities.) I speak to your 2 points inline below: On Wed, Feb 29, 2012 at 9:36 PM, Sebastian Bergmann sebast...@php.net wrote: On 02/29/2012 09:01 PM, Adam Jon Richardson wrote: However, the aliases would allow developers to better communicate intentions AND provide more information for IDE's and static analyses tools. 1) You are trying to solve a social problem through technology. That usually does not work. I believe technology can provide effective tools for social problems, although I won't go so far as to say that it usually does work. More importantly, I believe programming is riddled with social problems: Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. D. Knuth 2) What you want to achieve is already possible through docblocks. The greater part of the proposal rests on the general scalar hint. That said, I still believe the aliases for the scalars hold value. Sure, the communicative aspect of the aliases can be achieved through use of docblocks. However, in cognitive psychology and human factors research, proximity of relevant information plays a role in perception and processing, and I would posit that code with the type intentions displayed closer to the actual body of the function would hold benefits (this would be very testable, though, and research could prove me wrong.) When available, the scalar aliases could then be used to help auto-generate the docblocks. I would appreciate the scalar hinting, along with the aliases I outlined very much in my code. I believe that this form of hinting stays true to the PHP principles outlined in Richard's PHP Philosophy thread (a great read), and I believe it helps developers who want to better enforce (scalar hinting) and communicate (scalar aliases) the intentions of their code. Thank you for the feedback, Adam
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error(Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,, E_RECOVERABLE_ERROR);
}
The error-message is just an example - but that would keep the three
type-hint possibilities in one and the same functionality - like just
allowing exactly this type.
You cannot even pass a class that extends* ArrayIterator *into a property
that requires an array. So I think we should also here (at least for
scalar) do a really strict thing.
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too
closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time
('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical
perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent
(BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do
this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick
simonsimc...@googlemail.com wrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
Ah, didn't notice the *new* behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong
precedent for treating parameter hints more aggressively than a type cast.
For example, you can cast between arrays and objects, with no errors, but
the type hints will still generate errors. I think this settles the
consistency issue for me.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] PHP 5.4.0 released!
Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon 2012/3/2 Kris Craig kris.cr...@gmail.com Lol agreed. I typically just build manually off the latest release anyway. But not everybody does that. There are a lot of servers out there running on PHP 5.1.x right now. --Kris On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2012 00:46, schrieb Kris Craig: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key
Re: [PHP-DEV] Scalar type hinting
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:
function foo(SimpleClass $a) {
$a-getName();
}
foo(Test);
If you now get *method called from an non-object* or a message that you
have passed a value that's not compatible with *SimpleClass* ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays) or
bind a variable to a strict type?
- should it then also be possible bind variables to a specific class
or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all that's
compatible with the given type.
Bye
Simon
2012/2/29 John Crenshaw johncrens...@priacta.com
I would personally be inclined towards something simpler like E_NOTICE or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
should be consistent, and the consistency argument may make the difference.
There may be a strong case for changing the error level on all type hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw johncrens...@priacta.com
mailto:johncrens...@priacta.com wrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.com
mailto:vch...@developersdesk.comwrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad it is no
longer PHP hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on the
fence with that. =)
--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the strong int and weak int in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] Scalar type hinting
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magic
If an integer is required and you pass an object, it first checks if this
object is castable to integer ;)
Bye
Simon
2012/2/29 Simon Schick simonsimc...@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:
function foo(SimpleClass $a) {
$a-getName();
}
foo(Test);
If you now get *method called from an non-object* or a message that you
have passed a value that's not compatible with *SimpleClass* ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.
Bye
Simon
2012/2/29 John Crenshaw johncrens...@priacta.com
I would personally be inclined towards something simpler like E_NOTICE or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
should be consistent, and the consistency argument may make the difference.
There may be a strong case for changing the error level on all type hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw johncrens...@priacta.com
mailto:johncrens...@priacta.com wrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.com
mailto:vch...@developersdesk.comwrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad it is no
longer PHP hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on
the fence with that. =)
--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the strong int and weak int in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] Scalar type hinting
Hi, Arvids
I did not meant to putt all in one big RFC but more to think about the
connection between these two while developing.
Bye
Simon
2012/2/29 Arvids Godjuks arvids.godj...@gmail.com
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_magic one.
And thanks for the support :)
2012/2/29 Simon Schick simonsimc...@googlemail.com:
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magic
If an integer is required and you pass an object, it first checks if this
object is castable to integer ;)
Bye
Simon
2012/2/29 Simon Schick simonsimc...@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I
only
want what Arvids suggested last time:
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:
function foo(SimpleClass $a) {
$a-getName();
}
foo(Test);
If you now get *method called from an non-object* or a message that you
have passed a value that's not compatible with *SimpleClass* ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.
Bye
Simon
2012/2/29 John Crenshaw johncrens...@priacta.com
I would personally be inclined towards something simpler like E_NOTICE
or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I
think we
should be consistent, and the consistency argument may make the
difference.
There may be a strong case for changing the error level on all type
hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most,
something
that I and others strongly disagree with. The logical approach, to me
at
least, is to follow the example of include() and require(); i.e.
they're
both identical except that one throws a scary error while the other
one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw
johncrens...@priacta.com
mailto:johncrens...@priacta.com wrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer
vch...@developersdesk.com
mailto:vch...@developersdesk.comwrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an
error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad it is no
longer PHP hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on
the fence with that. =)
--Kris
OK, if we're all on the same page there, I think this means that there
is
no significant difference between the strong int and weak int in
your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to
deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.
John Crenshaw
Priacta, Inc.
[PHP-DEV] Vulnerability by loading doctype-declaration of xml
Hi, all I just read this post about a vulnerability by loading doctype-declaration of an xml-string given in a request: http://www.idontplaydarts.com/2011/02/scanning-the-internal-network-using-simplexml/ Would it be a good point to restrict which urls can be loaded in the doctype, or is the following line the only possibility to prevent it in a good way? libxml_disable_entity_loader(true); Bye Simon
Re: [PHP-DEV] Scalar type hinting
Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the error-messages for classes and arrays as they
are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into the
other data-type.
Lets have an example:
function foo(integer $i) {
// do something
}
foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo(1); // wont throw an error because the transformation into an integer
is loose-less
foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
integer is required here.
foo(horse); // Throws an E_RECOVERABLE_ERROR because if you transform
horse into a float, it's 1 and that's not equal to the string anymore.
I personally would treat float - int miss matches the same way as all other
stuff, because it cannot be converted loose-less.
And if the Object-cast-stuff comes through, we have to think about this in
addition:
https://wiki.php.net/rfc/object_cast_magic
class MyInteger {
public function __castTo(string $type) {
if ($type === integer)
return 5;
}
}
function foo(integer $i) {
// do something
}
foo(new MyInteger()); // Even if this is an object - it's cast-able to an
integer and therefore should be valid
But this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.
Bye
Simon
2012/2/29 Kris Craig kris.cr...@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).
--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.cr...@gmail.com wrote:
@Richard I think you made a very good point. Should we treat a float =
int mismatch the same as we would a string = int mismatch, or should the
former fail more gracefully? I can see good arguments for both.
--Kris
On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch c...@l-i-e.com wrote:
On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for floor()
streak int $i = 123.456; //In contrast to previous
streak int $i = 1 ; //value=1 is ridiculously common HTML
It's all well and good to say that any loss of data is bad and to
raise some E_* for it, but there are some idioms so common that feel
wrong as I consider them...
If everyone for the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I think
wrt E_RECOVERABLE_ERROR vs E_WARNING
If current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new streak with it.
I don't even object to using E_ERROR for the strong variant, if that
passes review, really, since strong is, errr, strong. :-)
Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue after E_ERROR is like
playing russian roulette...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hi, Kris
As we have some RFCs around that we should update them I think.
In my opinion we should split them up into 3 RFCs (and one grouping RFC):
Weak and strong type-checks (whatever that in detail means) should be
discussed in one single RFC. The option1 in the existing one is pretty
close to what I expect it to be - but why should f.e. 12abc be a valid
integer? As said - we should update that.
https://wiki.php.net/rfc/typecheckingstrictandweak
Split the following RFC into two RFCs. Parameter type-hint and return
type-hint:
https://wiki.php.net/rfc/typehint
Until now we have two RFCs for return type-hint that should also be
combined. Add the information from the last mentioned here as well:
https://wiki.php.net/rfc/returntypehint2
https://wiki.php.net/rfc/returntypehint
And finally update the grouping-RFC:
https://wiki.php.net/rfc/typechecking
The RFCs for parameter- and return-type-hint should not contain the
definition of strict or weak type-hints.
After all three RFCs have been voted by a bunch of people we can write down
a RFC for a combination - f.e. how it should look like to have weak
function type-hinting or strong return type-hinting.
So .. here's quite a lot of work to do to gather the people who wrote these
RFCs and let their ideas float into one specific definition with several
options how to implement them.
Bye
Simon
2012/2/29 Kris Craig kris.cr...@gmail.com
And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes yes with differentiation, 2 votes yes without differentiation, and
5 votes no. If we tally the two yes columns, it's 10 - 5, which would be
the required 2/3 majority. However, how would we calculate the mandate on
differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
majority in favor of it. But if you count the no votes as being no to
differentiation and add them to the total, it suddenly becomes 8 - 7, which
falls short of the 2/3 majority. An argument could be made that these
people who voted no would not want differentiation, but another argument
could be made that; while they don't like the idea, if it does happen
they'd rather have it differentiated than not. In other words, determining
voter intent from that group would be difficult and thus only tallying
among the yes votes would make sense. Both arguments would have about
equal merit I think
The voting RFC does allow for different options in the vote, but it does
not elaborate on this. We could break the no group into two as well,
though that could make things a bit too confusing.
Since there's presently no clear procedure on this (at least none that I'm
aware of), what are your thoughts on this? I do believe the two should be
in the same vote since they're pretty integral to one another, but I'm not
sure how best to do that while maintaining accurate results without making
it too complicated.
--Kris
On Wed, Feb 29, 2012 at 12:18 PM, Kris Craig kris.cr...@gmail.com wrote:
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.
--Kris
On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick
simonsimc...@googlemail.com wrote:
Hi, Kris
I don't think we have to care about scripts that are written right now
if we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the error-messages for classes and arrays as
they are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into
the other data-type.
Lets have an example:
function foo(integer $i) {
// do something
}
foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo(1); // wont throw an error because the transformation into an
integer is loose-less
foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
integer is required here.
foo(horse); // Throws an E_RECOVERABLE_ERROR because if you transform
horse into a float, it's 1 and that's not equal to the string anymore.
I personally would treat float - int miss matches the same way as all
other stuff, because it cannot be converted loose-less.
And if the Object-cast-stuff
Re: [PHP-DEV] Scalar type hinting
Hi, All Sorry for pulling the old RFCs out. But why is their status is still *in draft* or something like that? I did not know something about the 6-month-rule. That's also what I mentioned before with the missing solution ... If you close an RFC or set it to *accepted*, please also write what has been accepted. Btw: the old RFCs need to be cleaned up some when ... archived ... As I see from your mails, you're not in detail following this conversation. Btw. The conversation got quite down to a personal level in the last hours ... not really talking about facts and arguments. I don't want a strict/weak type-binding of variables, either do I want something strict if you pass stuff into a function. I simply want to define a type for each argument of a function/method. If someone calls this function with a parameter that is not compatible with the required type, let it break. The other RFCs were just something I saw on my way. That's nothing I personally wanted to push forward (not right now at least) but they fit in our discussion and were written in an RFC that was related to what I wanted. @Kris: I prefer the latter, which is why I am now pushing this. What I am very thankful for ;) Bye Simon 2012/2/29 Kris Craig kris.cr...@gmail.com With all due respect, it's a logical fallacy to draw a direct comparison between these two simply because they both happen to be uphill battles. We've demonstrated in this discussion that it can, in fact, be done without breaking the PHP concept at all. The only consistent argument I'm hearing against it is, It's been voted down before. And yet, it keeps coming up. Why do you suppose that is? Mind you, this is the first time that I have ever brought this up. So it's not just me. Ignoring this obviously hasn't made it go away. We can either continue sitting in denial and whining whenever somebody brings this up, or we can finally stop procrastinating and take on the unpleasant task of actually working this out. PHP 6 presents the perfect opportunity for something like this anyway. Voting it down hasn't made it go away. What is it they say about the definition of insanity? Doing the same thing over and over again and expecting a different result. This concept has been proposed in many different ways, but now it seems like some of you have decided to just vote it down because you're tired of it being talked about. But that hasn't worked, has it? And it won't. So we can either keep doing this every 6 months or we can try to work something out that addresses this finally. Even if we were to take the totalitarian approach of restricting the voting process, that wouldn't stop people from bringing this up on the list, so the problem of people continuing to bring this up would still go on. Seriously, just step back and look at this from a practical, logical standpoint. What we've been doing hasn't worked. Summarily voting anything resembling this down to make it go away hasn't made it go away. One of the main reasons I finally jumped into this discussion after all these years is because I noticed this pattern was once again repeating itself in the enum thread. This isn't going to just magically go away. People aren't going to see the light and suddenly stop asking for this just because they've realized the core devs decided to click the ignore button. We can either keep repeating this pattern or we can step out of denial and finally address this. I prefer the latter, which is why I am now pushing this. --Kris On Wed, Feb 29, 2012 at 2:46 PM, Matt Wilson sha...@gmail.com wrote: I once pushed this hard for namespaces. Then, after years of it being shot down, they did it. And now I'm sad. It didn't occur to me until after it had been implemented how bad an idea it was for php. I think this is one of those times. Type hinting is wonderful, but i'm not sure you could really make it fit in php without bastardizing the concept. The last time I looked at this discussion, I saw something about call-time silent type conversion (essentially foo((int) $bar)) and if that's not bastardizing a concept... I think the community has spoken. And when the core devs put their foot down, I think it's best to listen. If it's so important to you, then by all means, fork. Or simply write a patch. Put it to a vote. But this is beating a very dead horse. -M On Feb 29, 2012, at 4:36 PM, Kris Craig wrote: I agree. I'm against strict type hinting as well. Of course, nobody here is suggesting that we should go with strict typing, so it's a moot question anyway. --Kris On Wed, Feb 29, 2012 at 2:35 PM, Arvids Godjuks arvids.godj...@gmail.comwrote: Please.read my emails carefuly. What i said is last time the work has been done, and two different patches have been developed and iterated. But dificulties in implementation and strong resistance from the
Re: [PHP-DEV] Scalar type hinting
Hi, all What's next? I think the next step would be to write down a good Introduction, Requirement, Solution and Examples. As we had some discussions and ideas around here I think we came to a proper place where we could write the first draft and discuss it after writing it down in one place. I wont have the time tomorrow but I'll try my best to get it done at the weekend. If someone else has a good overview and wants to write the RFC, just go ahead and ping me when you've started. @Kris: I like the idea of having a second vote-level. The first level could be Like / Dislike this feature and the second one could be Like Solution1 / Like Solution2 / Like Solution3 Bye Simon 2012/3/1 Kris Craig kris.cr...@gmail.com @Simon Well said! For some reason, the issue of typing in the PHP and other programming communities brings out a lot of emotion in people. Given some of the heated rhetoric we've seen, you'd think we were debating whether Roe v. Wade should be overturned lol. I think it is important that we try to remember to be civil, on both sides. Falling into cliche hyperbole, condescention, and personal attacks just makes us look immature to the outside world IMHO. I'll try to do my part and not fly off the handle so much whenever somebody jumps in with a dismissive, patronizing comment relating to something that was already addressed earlier. Regarding the RFCs, just to clarify my earlier remarks, I should mention that the current policy, at least as I understand it, does not provide for expiring old/abandoned RFCs. The idea that it should was just a recommendation on my part. That said, I think you've got the right idea by looking at previous RFCs for insight into this! All I was saying is that, when it comes time to put forth our own proposal(s), it would probably be easier to write it from the ground up instead of trying to modify a bunch of older ones. =) Oh and if anybody has any thoughts on the suggestion I made earlier about adding secondary questions to the voting procedure (please read it before commenting), I'd love to hear them! I think that could be very helpful in future RFCs, so if there's any interest I'll go ahead and draft one for this. --Kris On Wed, Feb 29, 2012 at 3:56 PM, Simon Schick simonsimc...@googlemail.com wrote: Hi, All Sorry for pulling the old RFCs out. But why is their status is still *in draft* or something like that? I did not know something about the 6-month-rule. That's also what I mentioned before with the missing solution ... If you close an RFC or set it to *accepted*, please also write what has been accepted. Btw: the old RFCs need to be cleaned up some when ... archived ... As I see from your mails, you're not in detail following this conversation. Btw. The conversation got quite down to a personal level in the last hours ... not really talking about facts and arguments. I don't want a strict/weak type-binding of variables, either do I want something strict if you pass stuff into a function. I simply want to define a type for each argument of a function/method. If someone calls this function with a parameter that is not compatible with the required type, let it break. The other RFCs were just something I saw on my way. That's nothing I personally wanted to push forward (not right now at least) but they fit in our discussion and were written in an RFC that was related to what I wanted. @Kris: I prefer the latter, which is why I am now pushing this. What I am very thankful for ;) Bye Simon 2012/2/29 Kris Craig kris.cr...@gmail.com With all due respect, it's a logical fallacy to draw a direct comparison between these two simply because they both happen to be uphill battles. We've demonstrated in this discussion that it can, in fact, be done without breaking the PHP concept at all. The only consistent argument I'm hearing against it is, It's been voted down before. And yet, it keeps coming up. Why do you suppose that is? Mind you, this is the first time that I have ever brought this up. So it's not just me. Ignoring this obviously hasn't made it go away. We can either continue sitting in denial and whining whenever somebody brings this up, or we can finally stop procrastinating and take on the unpleasant task of actually working this out. PHP 6 presents the perfect opportunity for something like this anyway. Voting it down hasn't made it go away. What is it they say about the definition of insanity? Doing the same thing over and over again and expecting a different result. This concept has been proposed in many different ways, but now it seems like some of you have decided to just vote it down because you're tired of it being talked about. But that hasn't worked, has it? And it won't. So we can either keep doing this every 6 months or we can try to work something out that addresses this finally. Even if we were to take the totalitarian approach
Re: [PHP-DEV] Possibility to add finally to try/catch?
Hi, Dmitri
Great that someone's mentioning it.
I thought about that several times but did not put it in here.
This is a must-have for me. Really useful if you're working with external
resources (streams, database connection etc).
I used a destructor until now for stuff like that but there are some
situations where a destructor won't be called.
http://stackoverflow.com/questions/2385047/when-will-destruct-not-be-called-in-php
Bye
Simon
2012/2/28 Paul Dragoonis dragoo...@gmail.com
Tried to do something the other day and had to write something a bit quirky
tht would have been super clean with a finally block.
+1000
On Tue, Feb 28, 2012 at 2:22 PM, Kiall Mac Innes ki...@managedit.ie
wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or
Python
know that
it is very neat feature to have in some situations.
Basically the code inside 'finally' is guaranteed to run even if there
is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the
code
inside finally block executes and then remembered value is returned.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hey, Michael
This is by far the best possible way I read in the whole conversation.
I like the way of backwards-compatibility, error-reporting and so on.
This is would be very useful and would not disturb someone's
framework-combination.
This should be written down in a new RFC.
For all who want the strict types, you can write an error handler and
convert all you get into an exception :D
But then you'll end up with code-snippets like this (extracted from
Magento):
try {
$value = unserialize($optionValue);
} catch (Exception $e) {
$value = $optionValue;
}
Sorry but I had to mention it somewhere ;) This is by far the worst and
most complex code-snippet I've seen ever. It relies on the hidden feature
that the error-handler converts all errors into an exception - but only in
DEV mode :D Therefore it works for all developers but on in the live-mode :D
Bye
Simon
2012/2/28 Michael Morris dmgx.mich...@gmail.com
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo(123)
We are still ok, since the conversion of 123 to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, 123 is an
explicit string value.
$a = 456;
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = 456;
will raise an E_Notice and so will
$a = Hello World;
If we want $a to go back to being a scalar one might try...
unset($a);
$a = Hello World;
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = 456
foo($a);
As proposed, works, no error as discussed above.
$a = Hello World;
foo($a);
E_NOTICE raised.
string $a;
foo($a);
E_WARNING raised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.
So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)
On Tue, Feb 28, 2012 at 9:35 AM, Lazare Inepologlou linep...@gmail.com
wrote:
Hello everyone,
Let's stop the religious war between strongly and weekly typed languages.
In software, there is no silver bullet. Both approaches have their
benefits
and their disadvantages, so trying to prove that one is better to the
other
leads to nowhere.
Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to
strongly
typed languages, I see no reason to just close the door. I think it's
high
time that we separated the PHP *platform* from the PHP *language*. That
will eventually lead to the creation of strongly typed languages that
could
be executed on the PHP platform.
Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/2/28 Arvids Godjuks arvids.godj...@gmail.com
Aren't you people getting tired of saying that arguments like it's
not the PHP way or that does not fit the PHP paradigm are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!.
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).
Besides that - a scripting
Re: [PHP-DEV] Scalar type hinting
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers. A
string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a E_STRICT
or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part of the
php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point why I
want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer whereas
the documentation says that this function expects a string (or an error if
it should be an object or array).
Bye
Simon
2012/2/28 Arvids Godjuks arvids.godj...@gmail.com
Function type hints are ok, but I can't imagine a reason why would you
really use the locked variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)
2012/2/28 Michael Morris dmgx.mich...@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo(123)
We are still ok, since the conversion of 123 to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, 123 is an
explicit string value.
$a = 456;
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = 456;
will raise an E_Notice and so will
$a = Hello World;
If we want $a to go back to being a scalar one might try...
unset($a);
$a = Hello World;
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = 456
foo($a);
As proposed, works, no error as discussed above.
$a = Hello World;
foo($a);
E_NOTICE raised.
string $a;
foo($a);
E_WARNING raised. The reason for this higher error state to be raised
is an attempt was made to place an
Re: [PHP-DEV] bugs.php.net php 6
Hi, Richard The development of the unicode-as-default-charset should really be done within the next release coming after 5.4 I heared somewhere that it's nearly done ... I would have happily seen it in 5.4 but as this release is late right now we have to wait ;) Bye Simon p.s. * http://www.php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog *http://www.php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog 2012/2/27 Richard Lynch c...@l-i-e.com On Sun, February 26, 2012 2:03 am, Stas Malyshev wrote: Just discovered that our stock php 4 support discontinued message in bugs looks like: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Unless I've missed something, the momentum for php 6 is very much nonexistent, so we probably want to fix that message :) Isn't the emotional scarring of PHP 6 == Unicode far enough in the past to start some momentum for PHP 6? I sure core Devs have thought about this, and have gone so far as to make statements for what should be in PHP 6... PS If it isn't already, I want to write an RFC to change the default error_reporting to include E_NOTICE. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini
Hei, Richard I've looked into the php.ini.* files of PHP 5.4 for windows and saw the following line in *production*: error_reporting = E_ALL ~E_DEPRECATED ~E_STRICT display_errors = On log_errors = On and the following line in *development*: error_reporting = E_ALL display_errors = Off log_errors = On I also looked up the function error_reporting and came around that: http://no.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting http://php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog The first link seems to contain some out-dated information ... That was the reason why you raised the RFC, right? Here's how I understood the second link and the settings I found in the windows version: You'll get every message reported by the php-parser in your log by default if you're working using the development version and won't get any deprecated and strict messages in *production*. If this messages are written into a log-file or passed to the output is up to the rest of the settings where in both environments both they're written into the error-log-file but only *development *it is additionally visible to the user. So for the windows environment (if you'd ask me) this seems solved. I have not looked into the other environments yet. If they are not the same we should work to keep the default-configuration in one way, whatever OS you're working on. Bye Simon 2012/2/27 Richard Lynch c...@l-i-e.com On Mon, February 27, 2012 1:33 pm, Kris Craig wrote: I think it's a good idea, though I'm not sure it should be done in the production one as well. I'm not sure, but I think these errors are generally suppressed in production because of potential security concerns involved in making those errors public. I would contend that if you have any errors at any level of E_* going out over HTTP, you have done it wrong. It is true that in the days of register_globals, the E_NOTICE going to the HTML was a gold-mine for abusers of potential security threats. But all of E_* messages are also goldmines of the same ilk. That said, I would suggest amending the RFC so that it only applies to php.ini-development. Other than that, I like it. If most cheap webhosts chose php.ini-development, I'd be okay with this, as it probably is not suitable for PRODUCTION environments for the experts. Unfortunately, most cheap webhosts go with php.ini-production, as they are production environments, and the unwashed masses of users of said cheap webhosts are the target audience of the proposal. As stated in the RFC, the experts can and will change their php.ini to their taste in each environment: It's the masses of users who don't even know there is a choice that are being hurt by the current default setting, writing bad code, asking questions of obvious typos that E_NOTICE would catch, and remaining un-educated for too long that they develop bad habits. Not that I think this will eliminate newbie postings. There will always be those who don't even read or comprehend the most clear error messages. But I think it will reduce the number of postings by newbies who are tripped up by the typical mistakes E_NOTICE exposes. PS I want to thank you for your reasoned response, especially given the other thread we are involved in! -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
Hi,
This does not seem like a good way for me ...
Think about combining many scripts.
It's for example quite usual to use Symfony and parts of Zend Framework
together. Think about what will happen if the one framework uses another
autocast logic ...
Bye
Simon
2012/2/27 Anthony Ferrara ircmax...@gmail.com
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 extreme performance penalties, as every callback in
the chain (at least up to a valid cast) would then need to be called
for every single cast operation.
Not to mention that you're now externalizing where the cast happens
into a non-obvious and non-extendable spot (meaning that you're
removing the possibility of modifying behavior via polymorphism)...
I prefer the concept of binding the cast operations (two, for
symmetry) to the class itself, as it localizes the functionality to
that class, and is quite predictable and extendable.
If I missed the point you were trying to make, please elaborate.
Thanks,
Anthony
2012/2/26 Ángel González keis...@gmail.com:
I just realised that if it were going to add magic casting, it could as
well
be done with a spl_autocast_register(), so that you could either cast
things
when they match, throw an exception, etc. (there should be some default
value dynamic typing, so the perfomance wouldn't hurt) .
I don't think that's the perfect solution, though.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Hi, Daniel I'd also set the collation to *utf8_unicode_ci*. Here's a link to the full diff of the *my.cnf* file I am using on my dev-server: https://github.com/SimonSimCity/webserver-configuration/blob/master/mysql/patch.diff Bye Simon 2012/2/24 Daniel Convissor dani...@analysisandsolutions.com Hi Johannes: 1) You said * /etc/my.cnf settings are (no other my.cnf files exist): * + default-character-set = utf8 * + character-set-server = utf8 In which section of the my.cnf file? Both for the server, or for the client? [client] default-character-set = utf8 [mysqld] character-set-server = utf8 Thanks for looking into this, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
