Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58293 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86742 invoked from network); 28 Feb 2012 22:24:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2012 22:24:07 -0000 X-Host-Fingerprint: 134.29.239.140 140-239-29-134.minnesota.edu Received: from [134.29.239.140] ([134.29.239.140:6325] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 23/BA-36673-4045D4F4 for ; Tue, 28 Feb 2012 17:24:04 -0500 Message-ID: <23.BA.36673.4045D4F4@pb1.pair.com> To: internals@lists.php.net Date: Tue, 28 Feb 2012 16:23:59 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 References: <4F4C1324.2040905@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 134.29.239.140 Subject: Re: [PHP-DEV] Scalar type hinting From: justin.rovang@minnesota.edu (Justin Rovang) Additionally, return type hinting could strengthen the use of interfaces. That could problems with implementing interfaces (or an API) from having to do checking to ensure a method in a class implementing an interface is behaving as it should (returning the right stuff). On 2/28/2012 12:35 PM, Simon Schick wrote: > 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 > >> 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: >>> 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 >> 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 >>>> >>>>> 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 language is much easier to learn, use it >>>>> and learn it. Things like strict typing, strict type hinting and so on >>>>> are not as trivial to understand and learn unless you start with a >>>>> strict typed compiled language. When you deal with the script language >>>>> and loose variable typing you get used to being able to convert types >>>>> on the fly. And imagine the shock when you start using some strict >>>>> typed library and now you have to convert all your variables >>>>> explicitly. And now the code looks just like C/C++/Java/Delphi code - >>>>> type conversion statements all over the place. I sure don't want such >>>>> code. And not because it is hard to combine (or impossible) weak and >>>>> strict type hinting - that just does not suit a scripting language >>>>> created with loose/weak typing in the first place. And adding such >>>>> things will not improve the code - it will mess it up big time. I >>>>> don't know about you, but I have seen and worked with folks who did >>>>> some really weird things in PHP. An instrument like strict type >>>>> hinting will just give them the ability to write code that is plain >>>>> stupid. It will be just like OOP for the sake of OOP. Too many people >>>>> do not understand the philosophy behind the PHP and they build over >>>>> complex things and complain that they had to become "inventive" to be >>>>> able to do implement something from the C++/Java/Python/Ruby world. >>>>> And they complain that PHP is a bad language, but still eat the >>>>> cactus. I wonder why? >>>>> >>>>> I really liked what the O'Raily wrote here: >>>>> >>>>> >> http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html >>>>> I know, some things are a little over the top, but in general it >>>>> describes the best PHP feature - it's easy to work with, it's easy to >>>>> make something without using any frameworks, libraries and just do the >>>>> work you need for the WEB. >>>>> And I think it should stay that way. And I personally like it that >>>>> way. And it's because of that I don't want to migrate to Ryby or >>>>> Python. Adding strict type hinting will ruin it because I know for a >>>>> fact that there are plenty of programmers who will turn their API's >>>>> into strict typed all over the place. And I will have to select my >>>>> data from the database and go through the records and explicitly >>>>> convert all my data to the correct types so I can use that wonderful >>>>> library whose author is a fond of strict typing. I see such things >>>>> with OOP right now in many places - they ask you for an object, but I >>>>> know it just really needs a string with the data to do the work. >>>>> Many people migrate to PHP from different languages, and mostly those >>>>> are strictly typed compile languages (I actually had teached PHP for 2 >>>>> years at the private school of web technologies - I saw many people >>>>> learning PHP after Java, C++, Delphi, even assembler). >>>>> It's not the problem that will become a problem in a year or two - it >>>>> will become so in 5-7 years. Just like register_globals, magic_quotes >>>>> and things like that gave their evil effects in time. >>>>> >>>>> So please, take your time to think this through. The technical aspect >>>>> is only part of the puzzle. As they say "The road to hell is paved >>>>> with good intentions". And adding strict and weak type hinting >>>>> together is just plainly a very bad idea. It may be good for library >>>>> and framework writers (but not all of them agree on that), but to the >>>>> people using them it will be a headache. >>>>> >>>>> -- >>>>> PHP Internals - PHP Runtime Development Mailing List >>>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>>> >>>>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >