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 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 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
