Hey, Michael
This is by far the best possible way I read in the whole conversation.
I like the way of backwards-compatibility, error-reporting and so on.
This is would be very useful and would not disturb someone's
framework-combination.
This should be written down in a new RFC.
For all who want the strict types, you can write an error handler and
convert all you get into an exception :D
But then you'll end up with code-snippets like this (extracted from
Magento):
try {
$value = unserialize($optionValue);
} catch (Exception $e) {
$value = $optionValue;
}
Sorry but I had to mention it somewhere ;) This is by far the worst and
most complex code-snippet I've seen ever. It relies on the hidden feature
that the error-handler converts all errors into an exception - but only in
DEV mode :D Therefore it works for all developers but on in the live-mode :D
Bye
Simon
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
>
>
