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