[PHP-DEV] Re: Flexible type hinting
Hi! 2) Type hinting will not create a mess of cast to the right types in the code as Stas had suggested, in close to a million lines of PHP code we have, I've been able to find less then 1000 (just did a grep) instances of casts. There is a good reason for that once you get out of the input processing stage you typically (aside from __toString()) have the data in the right type. The code also includes bits from PEAR and external The problem here is that if you want to write a robust code that wouldn't randomly fail at runtime "typically" isn't good enough - since wrong type is supposed to be a fatal error (which one could not handle in the typehinted library code since it happens on the client side before your code takes control), you would want to ensure that would never happen when you call a typedhinted function. And there's only two ways to do it - either make absolutely all functions and variables that interact with typehinted functions to be strict-typed (which we don't plan do) or do casts on each call to hinted function. I do not see how anything else could produce robust code provided that type mismatch is a fatal error and variables can not carry type. "stock php" for people to use. But please, don't reject this idea because you personally don't see yourself using it or because you want Being a C programmer for... hmm... about 20 years now I think I don't have too much problem with strictly typed languages :) I just think doing it in PHP the way you want to do it is going to produce a lot of issues that people tend to under-appreciate when they cheer the new cool feature. Also, looking at the patch I think it doesn't cover the matter of inheriting the typehinted methods - i.e. if there's a typehinted method, could I override it with non-typehinted version or vice versa? What about typehinted interfaces? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting revisited for PHP 5.3
Hello,
For what it's worth, a large +1 from me.
One concern I do have, however, is that the addition of scalar type hints
will put more attention to the lack of method overloading. Right now methods
can accept multiple values due to the type-lessness, and while it will
remain a possibility, code with type-hints usually is a lot clearner. To
demonstrate:
class Example {
public function setValue (int $value) {}
public function setValue (string $value) {}
}
While there are two obvious solutions for this (not using type-hinted
parameters and using setIntValue/setStringValue) I think inclusion of a
patch like this would be a good moment to overthink overloading like this.
Peter
"Ilia Alshanetsky" wrote in message
news:fc14fafe-6785-4067-9b49-9fc14f159...@prohost.org...
I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types
as well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type
that will allow any scalar data element.
The patch is available here: http://ia.gd/patch/type_hint_53.txt
It should be noted that this patch is fully compatible with opcode caches
and and requires no changes on the part of an opcode cache such as APC to
work.
My hope is that the latest changes will allow this to become a standard
part of PHP.
Ilia Alshanetsky
P.S.
It should be noted that this is not the first idea for type hints, that
credit goes to Hannes Magnusson who had posted a similar patch on the
internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
hinting patch for PHP that is available on wiki.php.net.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SOAPClient authentication problem
I sent this message to the php.soap newsgroup, but noone answered me.
Today I found a nasty problem with a simple php SOAP client. Never had
problems before, but today I have the following error at SOAPClient
constructor line:
SoapClient::SoapClient(http://www.w3.org/2001/xml.xsd): failed to open
stream: HTTP request failed! HTTP/1.1 401 Authorization Required
The source is as simple as:
$client = new SoapClient("http://my.host.com/my_web_service?wsdl";,
array( 'trace' => TRUE,
'login'=>'mylogin',
'password'=>'secret'
)
);
It seems that the php xml parser tries to fetch the url
http://www.w3.org/2001/xml.xsd at wsdl parsing time. Sniffing the
network operations I found that php uses my login and password (for the
web service) also to access external references! :-O
GET /2001/xml.xsd HTTP/1.0
Authorization: Basic bXlsb2dpbjpzZWNyZXQ=
Host: www.w3.org
In the past probably w3.org just ignored the issue, but now I receive an
HTTP 401 Unauthorized error in response...
In any case it is a serious security issue if SOAPClient sends password
around the web, when the intent is that they are used only for the web
service host!
I tried the following PHP versions:
PHP 5.2.3-1ubuntu6.5 (cli) (built: Feb 11 2009 19:55:53)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
PHP 5.2.8 (cli) (built: Dec 17 2008 00:54:27)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by
Zend Technologies
with Zend Optimizer v3.2.0, Copyright (c) 1998-2006, by Zend
Technologies
with Zend Debugger v5.2.2, Copyright (c) 1999-2006, by Zend Technologies
Regards,
Davide
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 8:28 AM, Stanislav Malyshev wrote: > Also, looking at the patch I think it doesn't cover the matter of inheriting > the typehinted methods - i.e. if there's a typehinted method, could I > override it with non-typehinted version or vice versa? What about typehinted > interfaces? I don't think we need to worry about this. Consider it to be the same as default values. So yes, yes, allowed but dont do anything since those functions are never called. Paul > -- > Stanislav Malyshev, Zend Software Architect > s...@zend.com http://www.zend.com/ > (408)253-8829 MSN: s...@zend.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi! I don't think we need to worry about this. Consider it to be the same as default values. So yes, yes, allowed but dont do anything since those functions are never called. There is a functionality handling default values (or, more precisely, optional arguments) with inheritance, etc. And it is doing something - if you declare interface as foo(int $a) and implement it as foo(string $a) there may be a lot of WTF happening. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 9:27 AM, Stanislav Malyshev wrote: > There is a functionality handling default values (or, more precisely, > optional arguments) with inheritance, etc. Are optional argument specifications inherited? I did not think they were, but its not clear if you are saying they are. My understanding of PHP's optional arguments is that they only apply to a function once it is called. > And it is doing something - if > you declare interface as foo(int $a) and implement it as foo(string $a) > there may be a lot of WTF happening. I mean that it is never called, therefore the type hints are not checked, and this is fine. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 5:26 AM, Ilia Alshanetsky wrote: > 1) Strict type hinting helps to solve bugs, both the ones made out of > careless/missing validation as well as subtle logic bugs that often take > hours to resolve. I can tell you that within a week of implementing type > hints we've been able to identify 30-40 bugs within a period of day. Many of > which would not have been detected with "flexible" type hints that Paul is > suggesting here is one example: I think you might not have read what I suggested (it is different than the one I emailed to you privately). What you want is fully supported. If you must be passed an int, use the +int hint. > type. The code also includes bits from PEAR and external libs like fpdf and > guess what those have no type hints and they work along side with type > hinted code without any issues. It is instructive that PEAR could not use your proposed hints. The "flexible" system would work fine though. > situations. Of all the replies I see no objection so far and the only > complaint (funnily enough) is about existence of IS_NUMERIC. Yes. Nobody wants numeric. It doesnt hint at anything. > I do not wish to start a flame war or arrive at a wishy washy compromise > that does not provide a solid solution. If the majority disagrees with the I think my "flexible" system is not a wishy washy compromise (the one I sent you by private email was). I think rather it has all the advantages you want, all the advantages I want, and even supports what Stas wants. > to work in a future with a library/framework that is strict about its input > or some far fetched idea that it will change the very nature of PHP. I don't think we are worried about it changing PHP, or about libraries using strict type hints. We are worried that libraries will use no hints, because the ones on offer are not useful to them. Please, take a read over my full proposal. I think you'll find it that it supports everyone's features without compromise. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 02.07.2009, at 10:45, Paul Biggar wrote: to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP. I don't think we are worried about it changing PHP, or about libraries using strict type hints. We are worried that libraries will use no hints, because the ones on offer are not useful to them. I think he is replying to me here. I am worried that with Ilia's proposal, people will strictly type everything, even where weakly typed would suffice. The reason being that developers are lazy. With these type "hints" (they are not actually hints, but "checks" as you already made clear), they can very easily move the burden of type juggeling explicitly to the user of their code. At least in my world, I use a lot of 3rd party libraries, which will then likely become essentially strictly typed. While strictly typing can prevent bugs and all sorts of good stuff, we should be more hesitant when it comes to giving people tools that make it easy (encourage) to turn a core principle of PHP upside down. I know that "numeric" was a concession to people with my concern from the last discussion. But it doesnt cover all the bases of types. In that vain Paul's proposal does indeed provide a syntax that at least enables both approaches. More importantly it proposes a syntax that requires the same number of characters for both approaches. You might laugh at this comment, but I believe that the overuse of "private" that I am seeing has a lot to do with the fact that its shorter than "protected". I have not really made up my mind about Paul's proposal, but I just wanted to make the above points. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP] Re: PHP 5.3.0 Released!
Does anyone have any further information on the PECL Binaries for 5.3, will they be released? 2009/6/30 pan > Lukas Kahwe Smith wrote: > >> Hello! > >> > >> The PHP Development Team would like to announce the immediate release > >> of PHP 5.3.0. This release is a major improvement in the 5.X series, > >> which includes a large number of new features and bug fixes. > >> > >> Release Announcement: http://www.php.net/release/5_3_0.php > >> Downloads:http://php.net/downloads.php#v5.3.0 > >> Changelog:http://www.php.net/ChangeLog-5.php#5.3.0 > >> > >> regards, > >> Johannes and Lukas > > Great ! > > The downloads page is devoid of any note in re pRCL binaries > for Windows. > windows.php.net doesn't say anything either of which pre-existing > PECL binaries will work with 5_3. > > Is the 5_2_6 set of PECL binaries compatible with 5_3 ? > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi, I'm a userland developer with limited C skills, and while I don't yet have an opinion on the whole type enforcing issue, aside from a fear of libraries abusing it, I'd like to propose a little change in the patch. Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to be thrown? I don't know whether InvalidArgumentException satisfies the semantics, but it's a step in that direction. On 7/1/2009 19:59, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict appears to be that in some cases typical type hinting is just too strict for PHP's typeless nature (most people expect that "1" == 1, while int type hint would definitely reject string "1"). Personally, I disagree with that opinion, but I can understand people who raise that issue. At work we've been using PHP 5.2 with type hinting for nearly 2 years now with great success, it makes code much easier to read and understand and the security benefit of type hinting is not to be under valued. In many cases type hinting can present a last line of defense against unexpected input for numeric fields, which are typically abused to do SQL injection. I've taken a few hours this morning to port my 5.2 type hinting patch to 5.3. In recognition of a need for a more 'flexible' numeric type I've introduced (numeric) type hint that would allow bool/int/float data types as well as a string containing a numeric entity as identified by is_numeric_string(). For completion i've also added (scalar) data type that will allow any scalar data element. The patch is available here: http://ia.gd/patch/type_hint_53.txt It should be noted that this patch is fully compatible with opcode caches and and requires no changes on the part of an opcode cache such as APC to work. My hope is that the latest changes will allow this to become a standard part of PHP. Ilia Alshanetsky P.S. It should be noted that this is not the first idea for type hints, that credit goes to Hannes Magnusson who had posted a similar patch on the internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type hinting patch for PHP that is available on wiki.php.net. -- Ionut G. Stan I'm under construction | http://igstan.blogspot.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tiny correction to type hinting patch
In Ilia's type hinting patch, on line 255, is the line:
+"string"|"binary"|"unicode" {
This failed for me. I fixed it by changing it to:
+("string"|"binary"|"unicode") {
Which matches all the other lexing rules for type hints. My
understanding of the lexer is insufficient to understand why this
particular set of parenthesis makes any difference at all, but there
you have it.
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi 2009/7/2 Ionut G. Stan : > Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to > be thrown? I don't know whether InvalidArgumentException satisfies the > semantics, > but it's a step in that direction. I don't think we should start changing the standard way of the engine to error out, having a custom error that checks for E_RECOVERABLE_ERROR can be made to throw an InvalidArgumentException within few lines of code/parsing. -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP] Re: PHP 5.3.0 Released!
Nick Cooper wrote: Does anyone have any further information on the PECL Binaries for 5.3, will they be released? I don't, but I suspect it is just a matter of compile + test. On Linux (CentOS) I've only done testing with i386 but none of the pecl modules I personally am using w/ 5.2.9 failed to build (for i386 or x86_64) and they all seem to work as expected (i386). So I expect for most of them, the distributed binaries will appear once they have had a little testing. -=- The problems I personally have run into: eAccelerator (stable) fails to build. Devel version does (at least according to their bug system) but does not work properly. suhosin module builds and works but kills the ability of pear to properly work (pear packages work fine, it's the package management that suhosin kills - can't even list channels w/o segfault) Many of the pear packages throw deprecation errors to screen if you have display_errors enabled. They seem to work, and it seems that these are errors that were thrown before as well but only under strict reporting. My guess is they are being brought to the forefront so the code can be fixed before php 6. Not a biggie if error reporting disabled, but a PITA on a development machine where you are trying to see errors thrown in *your* code. Maybe it's time for the community to go through pear, fix the errors, and submit patches to the maintainers that take care of the deprecated usage. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Thu, Jul 2, 2009 at 11:24, Ionut G. Stan wrote: > Hi, > > I'm a userland developer with limited C skills, and while I don't yet have > an > opinion on the whole type enforcing issue, aside from a fear of libraries > abusing > it, I'd like to propose a little change in the patch. > > Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to > be thrown? I don't know whether InvalidArgumentException satisfies the > semantics, > but it's a step in that direction. http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
I'm an advocate for introducing optional type hinting as I write many
assert('is_*($foo)') a day.
On Thu, Jul 2, 2009 at 9:28 AM, Stanislav Malyshev wrote:
> And there's only two ways to do it - either make absolutely all functions
> and variables that interact with typehinted functions to be strict-typed
> (which we don't plan do) or do casts on each call to hinted function. I do
> not see how anything else could produce robust code provided that type
> mismatch is a fatal error and variables can not carry type.
In an application not all layers have to deal with arbitrary parameters,
only the layer with user input does. Do I write a (Traversable) cast before
passing an object to foreach()? No, because the object is not user input. My
application will parse POST, GET, COOKIE parameters in layer 1 and call the
underlying layer 2 with the right data type; down from the layer 2 to 4, 5,
10 layer I can use type hinting.
Type hints became part of the contract of layer N: if there is a runtime
error the problem is in layer N-1 not respecting the contract.
function generate_numbers(int $maximum)
{
return .
}
function presentation_layer_display_numbers($input) {
if (isset($input['max']) and is_numeric($input['max'])) {
foreach (generate_numbers($input['max']) as $i) {
echo "$i";
}
} else {
echo $formCodeWithHighlightedErrors;
}
}
presentation_layer_display_numbers($_POST);
Validating input it's something we should already do, but the other parts of
the code can use type hinting. If I really pass a type that is not right to
generate_numbers(), it will be a very bad thing because the function will
not know how to recover; and it should not do: it's a job for the top layer.
Also, looking at the patch I think it doesn't cover the matter of inheriting
> the typehinted methods - i.e. if there's a typehinted method, could I
> override it with non-typehinted version or vice versa? What about typehinted
> interfaces?
For the Liskov Substitution Principle if B extends A you should be able to
call B as if it were A. So typehinted methods should be overriden respecting
the typehint to allow polymorphism.
interface Calculator
{
public function sum(int $a, int $b);
}
class ScientificCalculator
{
public function sum(int $a, int $b);
}
class BrokenCalculator
{
public function sum(int $a, string $b); // some error is thrown
}
class AnotherBrokenCalculator
{
public function sum(int $a, $b); // some error is thrown
}
--
Giorgio Sironi
Piccolo Principe & Ossigeno Scripter
http://ossigeno.sourceforge.net
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On 7/2/2009 13:56, Hannes Magnusson wrote: Actually, I'd use an exception class which extends from the builtin ErrorException class, but that's not the point. Anyway, probably Kalle Sommer Nielsen is right, and the way PHP already behaves in that regard should be kept. At least for now. -- Ionut G. Stan I'm under construction | http://igstan.blogspot.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Ionut G. Stan wrote: On 7/2/2009 13:56, Hannes Magnusson wrote: Actually, I'd use an exception class which extends from the builtin ErrorException class, but that's not the point. Anyway, probably Kalle Sommer Nielsen is right, and the way PHP already behaves in that regard should be kept. At least for now. I think it should be E_WARNING with auto type juggling if bad data comes through. This way it behaves as normal PHP code does without special handling to mitigate a script failure. The log files will still alert you to the problem, and if you really want an exception handler then you still have that option. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
2009/7/1 Stanislav Malyshev : > Hi! > >> The patch is available here: http://ia.gd/patch/type_hint_53.txt > > Technical comment: as this patch changes binary API this shouldn't happen in > 5.3 branch. So maybe it's better to make it for 6. > > As for the idea itself, it is obvious that many people like it, I would just > note that it would produce a confusion for some people due to the fact that > true, 1, 1.0, b'1' and '1' now become incompatible values and (once you > start using typehints, of course) you'd have to explicitly convert them. > That would lead people to stuff their code with explicit type conversions, > which doesn't add to code cleanness. This also means that internal functions > and user functions would behave differently with regard to type conversions. > -- > Stanislav Malyshev, Zend Software Architect > s...@zend.com http://www.zend.com/ > (408)253-8829 MSN: s...@zend.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Doesn't "stuff their code with explicit type conversions" actually mean "perform appropriate validation and conversion on incoming data" ? The majority of data that a program gets is either from a DB (and if ALL your columns are varchars, well, I give up and a xxx_fetch_row SHOULD cast to an appropriate type in my mind, but ...), from a config file (normally all strings), $_xxx (normally all strings). Internal values are inherently cast. How many people write ... $some_boolean = "1"; // Set some_boolean flag to true. No, they write ... $some_boolean = true; // No need to document anything here as the code is pretty much speaking for itself. We are constantly told about GIGO and not accepting anything a user supplies as safe, so, with that in mind, you validate the incoming data (one way is to cast to the valid type and then check ranges, etc.) and from then on everything is in the appropriate type. PHP's type juggling is useful, without a doubt. But it seems to be limited to 2 areas. 1 - Casting to strings for output. 2 - Casting to boolean for equality testing. So they don't "perform appropriate validation and conversion on incoming data", then you will end up with having to "stuff their code with explicit type conversions". That's something I'm prepared to live with. So. A big +1 from me to incorporate type hinting into PHP. Regards, Richard Quadling. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" I need a car : http://snipurl.com/l4pih ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Boxing and Unboxing
Hi, I recommend that you sign up on the wiki and publish your proposal on wiki.php.net/rfc regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 3:28 AM, Stanislav Malyshev wrote: Hi! 2) Type hinting will not create a mess of cast to the right types in the code as Stas had suggested, in close to a million lines of PHP code we have, I've been able to find less then 1000 (just did a grep) instances of casts. There is a good reason for that once you get out of the input processing stage you typically (aside from __toString()) have the data in the right type. The code also includes bits from PEAR and external The problem here is that if you want to write a robust code that wouldn't randomly fail at runtime "typically" isn't good enough If it fails it means some funciton did not return the expected value and that's a problem, not something that should be ignored if you decided (if you don't want to use, then things remain as they are) to use type hinting. - since wrong type is supposed to be a fatal error (which one could not handle in the typehinted library code since it happens on the client side before your code takes control), you would want to ensure that would never happen when you call a typedhinted function. And there's only two ways to do it - either make absolutely all functions and variables that interact with typehinted functions to be strict-typed (which we don't plan do) or do casts on each call to hinted function. I do not see how anything else could produce robust code provided that type mismatch is a fatal error and variables can not carry type. "stock php" for people to use. But please, don't reject this idea because you personally don't see yourself using it or because you want Being a C programmer for... hmm... about 20 years now I think I don't have too much problem with strictly typed languages :) I just think doing it in PHP the way you want to do it is going to produce a lot of issues that people tend to under-appreciate when they cheer the new cool feature. Also, looking at the patch I think it doesn't cover the matter of inheriting the typehinted methods - i.e. if there's a typehinted method, could I override it with non-typehinted version or vice versa? What about typehinted interfaces? Which is fine, because some people can use that functionality to overload methods they don't want to be type hinted from external libs the may be using. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: On Thu, Jul 2, 2009 at 5:26 AM, Ilia Alshanetsky wrote: 1) Strict type hinting helps to solve bugs, both the ones made out of careless/missing validation as well as subtle logic bugs that often take hours to resolve. I can tell you that within a week of implementing type hints we've been able to identify 30-40 bugs within a period of day. Many of which would not have been detected with "flexible" type hints that Paul is suggesting here is one example: I think you might not have read what I suggested (it is different than the one I emailed to you privately). What you want is fully supported. If you must be passed an int, use the +int hint. I'd rather use -int, then +int and make people who want loose typing do the extra bit, because native typing should be strict. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote: > > On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: >> I think you might not have read what I suggested (it is different than >> the one I emailed to you privately). What you want is fully supported. >> If you must be passed an int, use the +int hint. > > I'd rather use -int, then +int and make people who want loose typing do the > extra bit, because native typing should be strict. I think everyone wants their favourite to be default. I was eager to have the typing that's currently in the manual be the default, since that's what people are used to seeing. I suggested that strong type checks use +int exactly because that's different to what's in the manual, so there would be no confusion. I'm really looking to get people to agree to the principle that we would like to be able to hint every signature without large changes to the manual, since we've been looking at it for years. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 4:56 AM, Lukas Kahwe Smith wrote: On 02.07.2009, at 10:45, Paul Biggar wrote: to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP. I don't think we are worried about it changing PHP, or about libraries using strict type hints. We are worried that libraries will use no hints, because the ones on offer are not useful to them. I think he is replying to me here. I am worried that with Ilia's proposal, people will strictly type everything, even where weakly typed would suffice. The reason being that developers are lazy. With these type "hints" (they are not actually hints, but "checks" as you already made clear), they can very easily move the burden of type juggeling explicitly to the user of their code. At least in my world, I use a lot of 3rd party libraries, which will then likely become essentially strictly typed. While strictly typing can prevent bugs and all sorts of good stuff, we should be more hesitant when it comes to giving people tools that make it easy (encourage) to turn a core principle of PHP upside down. First of all PHP is a tool, if some developers choose(!!) to adopt stricter practices (which I doubt will happen), then perhaps its time for the tool to change with them. As far as I know PHP is there to solve problems and make it easy to do so, not support/enforce certain programming paradigms. I know that "numeric" was a concession to people with my concern from the last discussion. But it doesnt cover all the bases of types. In that vain Paul's proposal does indeed provide a syntax that at least enables both approaches. More importantly it proposes a syntax that requires the same number of characters for both approaches. You might laugh at this comment, but I believe that the overuse of "private" that I am seeing has a lot to do with the fact that its shorter than "protected". Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
Personally, I am uncertain about +int or -int in general, IMO that compromise will eventually be identical to numeric an cause endless confusion for the users between (+/-)int and int. The reason I used a completely different name is to prevent confusion. On 2-Jul-09, at 8:53 AM, Paul Biggar wrote: On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote: On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: I think you might not have read what I suggested (it is different than the one I emailed to you privately). What you want is fully supported. If you must be passed an int, use the +int hint. I'd rather use -int, then +int and make people who want loose typing do the extra bit, because native typing should be strict. I think everyone wants their favourite to be default. I was eager to have the typing that's currently in the manual be the default, since that's what people are used to seeing. I suggested that strong type checks use +int exactly because that's different to what's in the manual, so there would be no confusion. I'm really looking to get people to agree to the principle that we would like to be able to hint every signature without large changes to the manual, since we've been looking at it for years. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 02.07.2009, at 15:02, Ilia Alshanetsky wrote: Personally, I am uncertain about +int or -int in general, IMO that compromise will eventually be identical to numeric an cause endless confusion for the users between (+/-)int and int. The reason I used a completely different name is to prevent confusion. I do not see the risk for confusion as being high. Like I said, I havent made up my mind on this proposal, however for now Paul mainly asked for feedback in the general concept, not necessarily on the syntax. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Have you using existing array or class type hinting? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 9:23 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Have you using existing array or class type hinting? I have, and IMHO it makes more sense for strict checking (though not too strict since super classes make sense) when objects are being passed. But in the case of primitive datatypes where coercion between types is well established and understood, I think it should be a warning. PHP knows how to convert the string '1' to integer. It knows how to convert 0 to boolean false. These were established many years ago. On the other hand PHP does not know how to coerce (in a sensible way) class FreakyDeaky to class GobbletyGoot. It is not about what PHP can convert, in the past and if you use old function parameter parsing api PHP will even convert arrays to stirngs. Its about delivering to the function/method exactly what it wants and not a close facsimile thereof. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
2009/7/2 Robert Cummings : > Ionut G. Stan wrote: > I think it should be E_WARNING with auto type juggling if bad data comes > through. This way it behaves as normal PHP code does without special > handling to mitigate a script failure. The log files will still alert you to > the problem, and if you really want an exception handler then you still have > that option. It should be an E_RECOVERABLE, as it would make most sense, the error is recoverable as it did not leave the engine in a state that it cannot continue from a technical standpoint. -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Ilia Alshanetsky wrote: On 2-Jul-09, at 9:23 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Have you using existing array or class type hinting? I have, and IMHO it makes more sense for strict checking (though not too strict since super classes make sense) when objects are being passed. But in the case of primitive datatypes where coercion between types is well established and understood, I think it should be a warning. PHP knows how to convert the string '1' to integer. It knows how to convert 0 to boolean false. These were established many years ago. On the other hand PHP does not know how to coerce (in a sensible way) class FreakyDeaky to class GobbletyGoot. It is not about what PHP can convert, in the past and if you use old function parameter parsing api PHP will even convert arrays to strings. Its about delivering to the function/method exactly what it wants and not a close facsimile thereof. That's why I said, instead of E_RECOVERABLE it should be an E_WARNING with type coercion to what the hint requested. The function gets what it wants, and the developer gets a warning that it wasn't quite what it expected. Run time code doesn't just die because I've upgraded an application and missed a single API call update to comply with primitive type hinting. That's annoying in a production environment, and since it's run-time fail, it's not necessarily easy to catch all the issues. There *will* be production systems dying due to missed updates. There's the suggestion to capture the E_RECOVERABLE error, but that's putting the onus on developers and non-developers installing applications to have this in place, and due to the run-time nature of the problem, *everyone* would be better off putting it in place, just in case their production system goes down. Since 99% of coercions of primitive types are fine, I don't see why the majority must suffer the problem when the minority will be perfectly served by an E_WARNING to correct their code. You mentioned in your environment you've been using this for a while now and found problems otherwise very difficult to find. These same problems would also have been detected with an E_WARNING with the added value of the application not dying (or do you already have that E_RECOVERABLE handler in place). Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Ilia Alshanetsky wrote: On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Have you using existing array or class type hinting? I have, and IMHO it makes more sense for strict checking (though not too strict since super classes make sense) when objects are being passed. But in the case of primitive datatypes where coercion between types is well established and understood, I think it should be a warning. PHP knows how to convert the string '1' to integer. It knows how to convert 0 to boolean false. These were established many years ago. On the other hand PHP does not know how to coerce (in a sensible way) class FreakyDeaky to class GobbletyGoot. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 1:53 PM, Ilia Alshanetsky wrote: > Paul's proposal is some part does not make sense because it allows weak type > hinting, which should not be used if you need type hinting. The whole idea > about type hinting is definition of strict interfaces, not loosely based > one. That's just my opinion, which admittedly I feel fairly strongly about. No, the idea of type hinting is that you hint to the user about what type the interface expects. You have implemented "strong type checking" instead. I wonder that you cannot see the conflict between the term "type hinting" and "strict interfaces". I would be happier if you renamed your patch "optional strong scalar type checking", which is what it is. I have described a system that allows "strong type checking", "type hinting", and "type casting", which I think is all the use cases. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Flexible type hinting
On Thu Jul 2 08:53 AM, Paul Biggar wrote: > On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote: > > > > On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: > >> I think you might not have read what I suggested (it is different > >> than the one I emailed to you privately). What you want is fully > supported. > >> If you must be passed an int, use the +int hint. > > > > I'd rather use -int, then +int and make people who want loose typing > > do the extra bit, because native typing should be strict. > > I think everyone wants their favourite to be default. I was eager to > have the typing that's currently in the manual be the default, since > that's what people are used to seeing. I suggested that strong type > checks use +int exactly because that's different to what's in the > manual, so there would be no confusion. > > I'm really looking to get people to agree to the principle that we > would like to be able to hint every signature without large changes to > the manual, since we've been looking at it for years. > >From userland, I'm a big fan of this proposal / agree to the principle >although I'm not convinced that function($quantity) function(int $quantity) function(+int $quantity) function(-int $quantity) looks appropriate... Userland Note: The "-int" semantics confuses me, I realize it would cast null's etc... but is it really a requirement? Can it be dropped? function($quantity) function(int $quantity) paul's (S) casting function(int! $quantity) STRICT type --- seems appropriate for php, follows CSS/web style '!important' To me, strict as default doesn't seem appropriate in php. But if it does, this syntax could be interesting: function($quantity) function(int $quantity) STRICT type function(~int $quantity) paul's (S) casting Btw, really interesting discussions -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 3:17 PM, Jonathan Bond-Caron wrote: > From userland, I'm a big fan of this proposal / agree to the principle > although I'm not convinced that > > function($quantity) > function(int $quantity) > function(+int $quantity) > function(-int $quantity) > > looks appropriate... > > Userland Note: The "-int" semantics confuses me, I realize it would cast > null's etc... but is it really a requirement? Can it be dropped? Yes, it looks off, doesnt it. I quite like ~int, which you suggested below, for the casting. It makes me think "this is kinda an int". > function($quantity) > function(int $quantity) paul's (S) casting > function(int! $quantity) STRICT type --- seems appropriate for php, follows > CSS/web style '!important' Yes, I like that too. > To me, strict as default doesn't seem appropriate in php. But if it does, > this syntax could be interesting: > > function($quantity) > function(int $quantity) STRICT type > function(~int $quantity) paul's (S) casting This is also a nice, internally-consistent syntax. If you had something for (H) in your suggestions, I'd be happier. We need to cast there too. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] constructors are callable as regular functions.
I just realised that the following is valid php code:
class Foo {
function __construct() {
echo "constructor called\n";
}
}
$f = new Foo();
$f->__construct();
Output:
constructor called
constructor called
I would have expected the second call to __construct() to yield an error.
Has this been discussed before? In that case, was it decided to go
with this behaviour or is it purely accidental? Are there perhaps some
implementation issues in preventing the second call to __construct()?
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 10:02 AM, Paul Biggar wrote: On Thu, Jul 2, 2009 at 1:53 PM, Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. No, the idea of type hinting is that you hint to the user about what type the interface expects. You have implemented "strong type checking" instead. I wonder that you cannot see the conflict between the term "type hinting" and "strict interfaces". I would be happier if you renamed your patch "optional strong scalar type checking", which is what it is. That's a fair statement I suppose. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constructors are callable as regular functions.
2009/7/2 troels knak-nielsen : > Has this been discussed before? In that case, was it decided to go > with this behaviour or is it purely accidental? Are there perhaps some > implementation issues in preventing the second call to __construct()? Magic methods can always be called directly because they must be declared public to work. I don't see a reason why to disallow it, if a user manually executes a magic method they should be knowing what they are doing and remember that there might be side-effects with there code. -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constructors are callable as regular functions.
Excerpts from troels knak-nielsen's message of Thu Jul 02 10:14:18 -0400 2009:
> I would have expected the second call to __construct() to yield an error.
Why should it? Especially since this is idiomatic code:
class A {
public function __construct($a) {
$this->a = $a;
}
}
class B extends A {
public function __construct($a, $b) {
$this->b = $b;
parent::__construct($a);
}
}
__construct doesn't do anything like allocate memory. It just happens
to get called when we do "new B(1, 2)"
Cheers,
Edward
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
2009/7/2 Paul Biggar > On Thu, Jul 2, 2009 at 3:17 PM, Jonathan Bond-Caron > wrote: > > From userland, I'm a big fan of this proposal / agree to the principle > although I'm not convinced that > > > > function($quantity) > > function(int $quantity) > > function(+int $quantity) > > function(-int $quantity) > > > > looks appropriate... > > > > Userland Note: The "-int" semantics confuses me, I realize it would cast > null's etc... but is it really a requirement? Can it be dropped? > > Yes, it looks off, doesnt it. I quite like ~int, which you suggested > below, for the casting. It makes me think "this is kinda an int". > > > > function($quantity) > > function(int $quantity) paul's (S) casting > > function(int! $quantity) STRICT type --- seems appropriate for php, > follows CSS/web style '!important' > > Yes, I like that too. > But the exclamation mark has previous use in conditionals, so it may be confused with "anything but an int" Lewis.
Re: [PHP-DEV] constructors are callable as regular functions.
On Thu, Jul 2, 2009 at 4:47 PM, Edward Z. Yang wrote:
> Excerpts from troels knak-nielsen's message of Thu Jul 02 10:14:18 -0400 2009:
>> I would have expected the second call to __construct() to yield an error.
>
> Why should it? Especially since this is idiomatic code:
>
> class A {
> public function __construct($a) {
> $this->a = $a;
> }
> }
>
> class B extends A {
> public function __construct($a, $b) {
> $this->b = $b;
> parent::__construct($a);
> }
> }
In that example, the object instance is not initialised when
parent::__construct() is called.
> __construct doesn't do anything like allocate memory. It just happens
> to get called when we do "new B(1, 2)"
I understand that. It's not a technical issue - It's more a matter of
language semantics. Constructors are used for initializing state on an
object. Basically, this behaviour makes it impossible to implement
immutable objects in php. It's not a huge deal - I don't remember ever
seen __construct() called directly.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constructors are callable as regular functions.
Excerpts from troels knak-nielsen's message of Thu Jul 02 10:55:48 -0400 2009:
> I understand that. It's not a technical issue - It's more a matter of
> language semantics. Constructors are used for initializing state on an
> object. Basically, this behaviour makes it impossible to implement
> immutable objects in php. It's not a huge deal - I don't remember ever
> seen __construct() called directly.
Au contraire, you can employ this little trick:
class A {
private $a;
private function __construct($a) {
$this->a = a;
}
public function make($a) {
return new A($a);
}
}
But I agree; stab anyone who is doing $foo->__construct(). Except for
testing. Testing is ok.
Cheers,
Edward
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constructors are callable as regular functions.
troels knak-nielsen wrote:
> On Thu, Jul 2, 2009 at 4:47 PM, Edward Z. Yang wrote:
>> Excerpts from troels knak-nielsen's message of Thu Jul 02 10:14:18 -0400
>> 2009:
>>> I would have expected the second call to __construct() to yield an error.
>> Why should it? Especially since this is idiomatic code:
>>
>> class A {
>> public function __construct($a) {
>>$this->a = $a;
>> }
>> }
>>
>> class B extends A {
>> public function __construct($a, $b) {
>>$this->b = $b;
>>parent::__construct($a);
>> }
>> }
>
> In that example, the object instance is not initialised when
> parent::__construct() is called.
>
>> __construct doesn't do anything like allocate memory. It just happens
>> to get called when we do "new B(1, 2)"
>
> I understand that. It's not a technical issue - It's more a matter of
> language semantics. Constructors are used for initializing state on an
> object. Basically, this behaviour makes it impossible to implement
> immutable objects in php. It's not a huge deal - I don't remember ever
> seen __construct() called directly.
>
> --
> troels
Hi,
__construct can be private or protected, it just requires implementing a
factory() or singleton() method to retrieve the immutable object.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constructors are callable as regular functions.
2009/7/2 troels knak-nielsen : > [snip] ... - I don't remember ever > seen __construct() called directly. Its commonly done when extending reflection for example, or to populate the Exception class constructor when extending it: code = (integer) $code; parent::__construct($message); } } ?> Or more complex constructors without having to re-implement their logic / handling of constructing the object. -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi! Are optional argument specifications inherited? I did not think they were, but its not clear if you are saying they are. Of course they are - how couldn't they be, they are part of method definition. My understanding of PHP's optional arguments is that they only apply to a function once it is called. Yes, but it doesn't prevent them from being part of inheritance logic. if you have foo($a = 1) then you can't override it with foo($a) - it violates LSP (imagine somebody calling $a->foo()). And it is doing something - if you declare interface as foo(int $a) and implement it as foo(string $a) there may be a lot of WTF happening. I mean that it is never called, therefore the type hints are not checked, and this is fine. But it is called! The whole point of the interface is to call it - i.e. to have code use the fact that you can be sure to have foo(int $a) in some object of some unknown class. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! Doesn't "stuff their code with explicit type conversions" actually mean "perform appropriate validation and conversion on incoming data" ? Sometimes it does, but in many cases it doesn't - since variables are not typed and types can be juggled, you'd have to take precautions even though you could be sure the value itself is sanitized. We are constantly told about GIGO and not accepting anything a user supplies as safe, so, with that in mind, you validate the incoming It's not about the user input and security - it's about having different parts of your code working together through all possible changes. If you've got strict API you've got to make sure what you are sending to it would pass those strict checks, and would keep doing so through all changes done to the code. A big +1 from me to incorporate type hinting into PHP. I think calling this proposal "type hinting" just confuses the discussion. It's (optional) strict typing and it should be called so. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Thu, Jul 02, 2009 at 09:59:43AM -0700, Stanislav Malyshev wrote: > >A big +1 from me to incorporate type hinting into PHP. > > I think calling this proposal "type hinting" just confuses the > discussion. It's (optional) strict typing and it should be called so. +1 But first we must fix the current PHP manual that refers to it as type hinting: http://www.php.net/manual/en/language.oop5.typehinting.php -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Flexible type hinting
> -Original Message- > From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] > Sent: 02 July 2009 14:05 > To: Ilia Alshanetsky > Cc: Paul Biggar; PHP Internals; Derick Rethans; Stanislav Malyshev; > Hannes Magnusson > Subject: Re: [PHP-DEV] Re: Flexible type hinting > > > On 02.07.2009, at 15:02, Ilia Alshanetsky wrote: > > > Personally, I am uncertain about +int or -int in general, IMO that > > compromise will eventually be identical to numeric an cause > endless > > confusion for the users between (+/-)int and int. The reason I > used > > a completely different name is to prevent confusion. > > > I do not see the risk for confusion as being high. > Like I said, I havent made up my mind on this proposal, however for > now Paul mainly asked for feedback in the general concept, not > necessarily on the syntax. Interesting discussion. Not sure where I stand on this one, but I definitely don't like the [+-]int syntax. Even before Paul's proposal came out, though, I was thinking that I'd want to consider leveraging an existing well-understood syntax, so I could write function func(int $i) for strict type checking, and function func((int)$i) for coercion aka casting (although now I've seen it written down I'm not so sure! ;). I don't see the need for another option beyond the current syntax/behaviour -- in my opinion, anything else is documentation and should be treated as such. Cheers! Mike -- Mike Ford, Electronic Information Developer, C507, Leeds Metropolitan University, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi! function func(int $i) for strict type checking, and function func((int)$i) Without saying anything on the merits of having both syntaxes, visually I think this looks much nicer, even with the disadvantage of parentheses overload. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.0, phar symlink breaks rpm building.
Congratulations on the 5.3 milestone! Packaging the 5.3.0 stable release into an RPM (linux) will error as the bin/phar symlink is created using the build-time path variable. This has been submitted as bug: http://bugs.php.net/bug.php?id=48740 Patch: --- php-5.3.0/ext/phar/Makefile.frag.orig 2009-07-02 11:44:24.0 -0700 +++ php-5.3.0/ext/phar/Makefile.frag2009-07-02 11:45:42.0 -0700 @@ -43,4 +43,4 @@ install-pharcmd: pharcmd -...@$(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL) $(builddir)/phar.phar $(INSTALL_ROOT)$(bindir) - $(LN_S) -f $(INSTALL_ROOT)$(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar + $(LN_S) -f phar.phar $(INSTALL_ROOT)$(bindir)/phar I encourage this to be included in the next 5.3 release as it is likely cause some woe for vendors that are packaging php. I didn't see any specific rpm building automation tests available and the makerpm script included in the source is a bit dated. Would it be of any benefit to the community to provide an updated reference spec file and makerpm script for rpm capabable platforms? --- Michael McLane On Tue, Jun 30, 2009 at 03:01 PM, Lukas Kahwe Smith said: > Hello! > > The PHP Development Team would like to announce the immediate release > of PHP 5.3.0. This release is a major improvement in the 5.X series, > which includes a large number of new features and bug fixes. > > Release Announcement: http://www.php.net/release/5_3_0.php > Downloads:http://php.net/downloads.php#v5.3.0 > Changelog:http://www.php.net/ChangeLog-5.php#5.3.0 > > regards, > Johannes and Lukas > > -- > 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] PHP 5.3.0, phar symlink breaks rpm building.
Xyntrix wrote: > Congratulations on the 5.3 milestone! > > Packaging the 5.3.0 stable release into an RPM (linux) will error as the > bin/phar symlink is created using the build-time path variable. This has been > submitted as bug: > > http://bugs.php.net/bug.php?id=48740 > > Patch: > > --- php-5.3.0/ext/phar/Makefile.frag.orig 2009-07-02 11:44:24.0 > -0700 > +++ php-5.3.0/ext/phar/Makefile.frag2009-07-02 11:45:42.0 -0700 > @@ -43,4 +43,4 @@ > install-pharcmd: pharcmd > -...@$(mkinstalldirs) $(INSTALL_ROOT)$(bindir) > $(INSTALL) $(builddir)/phar.phar $(INSTALL_ROOT)$(bindir) > - $(LN_S) -f $(INSTALL_ROOT)$(bindir)/phar.phar > $(INSTALL_ROOT)$(bindir)/phar > + $(LN_S) -f phar.phar $(INSTALL_ROOT)$(bindir)/phar > > > I encourage this to be included in the next 5.3 release as it is likely cause > some woe for vendors that are packaging php. > > I didn't see any specific rpm building automation tests available and the > makerpm script included in the source is a bit dated. Would it be of any > benefit to the community to provide an updated reference spec file and > makerpm script for rpm capabable platforms? Sure, I don't think we have been paying much attention to that. Contributions would be welcome. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi 2009/7/2 Stanislav Malyshev : > Without saying anything on the merits of having both syntaxes, visually I > think this looks much nicer, even with the disadvantage of parentheses > overload. I agree, using the type cast operators for casting to the type, and non parentheses for strict checking isnt such a bad idea actually. It even makes sense without knowing the difference almost ;) -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Ford, Mike wrote: function func(int $i) for strict type checking, and function func((int)$i) for coercion aka casting (although now I've seen it written down I'm not so sure! ;). Just want to throw my 2 cents in. Big +1 for this syntax I think with the addition of this and __cast() for objects, PHP's OO will be very flexible and can build great Frameworks, ORM's, etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 9:09 PM, Ryan Panning wrote: > Ford, Mike wrote: > >>function func(int $i) >> >> for strict type checking, and >> >>function func((int)$i) >> >> for coercion aka casting (although now I've seen it written down I'm not >> so sure! ;). >> > > Just want to throw my 2 cents in. > > Big +1 for this syntax > > I think with the addition of this and __cast() for objects, PHP's OO will > be very flexible and can build great Frameworks, ORM's, etc. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > function($quantity) function(int $quantity) STRICT type function(?int $quantity) Thought id throw it out there. Interesting discussion though. Ólafur
Re: [PHP-DEV] Re: Flexible type hinting
this one looks much more intuitive. Tyrael 2009/7/2 Ford, Mike : > > >> -Original Message- >> From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] >> Sent: 02 July 2009 14:05 >> To: Ilia Alshanetsky >> Cc: Paul Biggar; PHP Internals; Derick Rethans; Stanislav Malyshev; >> Hannes Magnusson >> Subject: Re: [PHP-DEV] Re: Flexible type hinting >> >> >> On 02.07.2009, at 15:02, Ilia Alshanetsky wrote: >> >> > Personally, I am uncertain about +int or -int in general, IMO that >> > compromise will eventually be identical to numeric an cause >> endless >> > confusion for the users between (+/-)int and int. The reason I >> used >> > a completely different name is to prevent confusion. >> >> >> I do not see the risk for confusion as being high. >> Like I said, I havent made up my mind on this proposal, however for >> now Paul mainly asked for feedback in the general concept, not >> necessarily on the syntax. > > Interesting discussion. Not sure where I stand on this one, but I > definitely don't like the [+-]int syntax. Even before Paul's proposal > came out, though, I was thinking that I'd want to consider leveraging an > existing well-understood syntax, so I could write > > function func(int $i) > > for strict type checking, and > > function func((int)$i) > > for coercion aka casting (although now I've seen it written down I'm not > so sure! ;). > > I don't see the need for another option beyond the current > syntax/behaviour -- in my opinion, anything else is documentation and > should be treated as such. > > > Cheers! > > Mike > > -- > Mike Ford, Electronic Information Developer, > C507, Leeds Metropolitan University, Civic Quarter Campus, > Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom > Email: m.f...@leedsmet.ac.uk > Tel: +44 113 812 4730 > > > > To view the terms under which this email is distributed, please go to > http://disclaimer.leedsmet.ac.uk/email.htm > > -- > 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
