There are indeed valid arguments for and against hinting. It seems to me
that having it optional as people have suggested would be the "best of both
worlds" approach, since it would allow the developer to choose for
themselves. I guess that means I'm on the "pro-choice" side of this debate
lol (seriously, all kidding aside, I've seen debates over abortion that
weren't as heated as this!).
--Kris
On Tue, Feb 28, 2012 at 10:35 AM, Simon Schick
<simonsimc...@googlemail.com>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
> >
> >
>
