So the official response is "get lost"?
I don't know about the internals implications. But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so. Legacy code would
not be affected unless it was trying to use the new reserved word
"strict"
2012/2/27 Johannes Schlüter <johan...@schlueters.de>:
> Hi,
>
> PHP is no strickt-typed language. Changing this is a massive change, if
> you want to go there: There are plenty of other languages.
>
> If you want this to be an optional feature:
> a) It's not optional (one has to maintain code written by others, uses
> libraries, frameworks, ...)
> b) It causes a hell lot of trouble with copy-on-write. going from
> fixed-typed to non-fixed-typed variables (in a funciton call or
> assignment or such) will always have to cause a copy. This will hurt the
> performance in hardly predictable ways.
>
> johannes
>
> On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote:
>> What I've wanted for awhile, but don't know what the implementation
>> problems would be, is to allow for two new variable types to solve
>> this problem - Strict and tolerant variables. Both of these must be
>> declared formally (otherwise PHP assumes scalar) and the datatype must
>> be included. The syntax
>>
>> // A tolerant variable.
>> integer $a = 3;
>>
>> // A strict variable
>> strict integer $b = 2;
>>
>> Tolerant variables silently cast values to their declared datatype.
>> Maybe they should raise E_NOTICE?
>> Strict variables refuse to be assigned a value with an incorrect
>> datatype. Raise E_WARNING?
>>
>> A strict function would have the current behavior of kicking a warning
>> when the type hinting fails. Otherwise, functions should be tolerant
>> -
>>
>> function foo ( integer $a, string $b, $c ) {}
>>
>> strict function foo ( integer $a, $string $b, $c ) {}
>>
>> A function parameter without a datatype would be ignored.
>>
>> This does open the door to function overloading, but the engine
>> problems of this are well documented and have been discussed. Still,
>> I don't think it's a bad thing to have a syntax that allows for method
>> overloading in the future.
>>
>> On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig <kris.cr...@gmail.com> wrote:
>> > I'll try to find some time tonight to create that for ya.
>> >
>> > Once this discussion comes together a little bit more and we have at least
>> > a vague-ish idea what direction we're moving in, I'll also go ahead and
>> > create an RFC as well so we have a conceptual product to build on.
>> >
>> > --Kris
>> >
>> >
>> > On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal <samuel.d...@gmail.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> I create a new thread to discuss about Scalar type hinting.
>> >>
>> >> Following the John Crenshaw proposed terminology:
>> >> > - "Strict Typing" means the super strict old C style typing that has
>> >> been proven to be ridiculous in this environment because of the obvious
>> >> problems inherent in the fact that almost every input is a string.
>> >> > - "Weak Typing" means types in the same sense that the PHP documentation
>> >> uses types (for example, the docs indicate substr(string, integer), and
>> >> substr(12345, "2") == "345".)
>> >> > - "No Scalar Typing" should be used to indicate the current system
>> >> (where there is no provision for hinting at scalar types.)
>> >>
>> >> Previous weak typing proposal could be found here :
>> >> https://wiki.php.net/rfc/typechecking
>> >>
>> >> I have no rights to edit the wiki and make a summary of previous
>> >> arguments, so if someone could create it...
>> >>
>> >>
>> >> --
>> >> Samuel DEAL
>> >> samuel.d...@gmail.com
>> >>
>> >>
>>
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
