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<arvids.godj...@gmail.com>
Function type hints are ok, but I can't imagine a reason why would you
really use the "locked" variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)
2012/2/28 Michael Morris<dmgx.mich...@gmail.com>:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo("123")
We are still ok, since the conversion of "123" to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, "123" is an
explicit string value.
$a = "456";
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = "456";
will raise an E_Notice and so will
$a = "Hello World";
If we want $a to go back to being a scalar one might try...
unset($a);
$a = "Hello World";
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = "456"
foo($a);
As proposed, works, no error as discussed above.
$a = "Hello World";
foo($a);
E_NOTICE raised.
string $a;
foo($a);
E_WARNING raised. The reason for this higher error state to be raised
is an attempt was made to place an 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
