Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58245
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.170 as permitted sender)
Received-SPF: pass (google.com: domain of simonsimcity@googlemail.com designates 10.182.17.100 as permitted sender) client-ip=10.182.17.100;
MIME-Version: 1.0
In-Reply-To: <CAGovj_OudJnF5gRbZFUaffDnvn+1krsM1UDw7AN87sdXK3jVmQ@mail.gmail.com>
References: <CAG=uTXEfTBqX7n0_zfGjB_txQFKtZXF4MOo6RHHPSRPerGeKZA@mail.gmail.com>
	<CAKOpQSwP_VXazO1WgQgOWiKTmgiwzorg2=ii+Mdz58a=TKs6VA@mail.gmail.com>
	<CAGovj_O5UQx9aAaYg302i-kKp13CtBKNLmQ48OLHNvk61rM1sw@mail.gmail.com>
	<1330357150.2159.30.camel@guybrush>
	<CAGovj_MUt60EJfG8a7r-cqrC2PKsi8mqh6v_iyNoRDq8q-jh2Q@mail.gmail.com>
	<CAH-PCH6Bre5yzc6r3zxEj3=zZY0PHDOCVQ0s=f8JBDSPnK+5Fw@mail.gmail.com>
	<CAAyV7nFmfhb97CGAK1ZAkp9qb3oCPxbUDnS-Z-v3cP2APcYs=g@mail.gmail.com>
	<CAH-PCH5mYpAJAyMoyODDSwTvmgpf6ZN_dmC58v0b=K-s-mL0EA@mail.gmail.com>
	<CAAyV7nEpCWE2Gg5MCvfyhGGspgMGB+oYORKK=BKfm48sgXkROA@mail.gmail.com>
	<4F4C1324.2040905@gmail.com>
	<CAKOpQSzop8NuwnD1gPYmgzE2=E5_AHj_N+-ezTp4DFpHXktTqw@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B8069DC46C55@MAILR001.mail.lan>
	<CAKOpQSyptTG2=+QtxZoDAB9uh=T=Jgw0DzsAEpTSPv5fGLY7mw@mail.gmail.com>
	<CAL0xaBE9Gnw0teC_VBkGU9Z99g0yZKcu4gnVKqQk6FpfiKt0UQ@mail.gmail.com>
	<CAMyk_Abp7F+EgQe-0o4r79-6=QS_hpm54D4vDEgHzpJdWA9=1A@mail.gmail.com>
	<CAGovj_OudJnF5gRbZFUaffDnvn+1krsM1UDw7AN87sdXK3jVmQ@mail.gmail.com>
Date: Tue, 28 Feb 2012 16:46:08 +0100
Message-ID: <CAJWj5+GNrLi6sCgedVT1P_qxm29mSAHuxdYaiK258RcEj0z9uQ@mail.gmail.com>
To: Michael Morris <dmgx.michael@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d044469252ba2b704ba0820f7
Subject: Re: [PHP-DEV] Scalar type hinting
From: simonsimcity@googlemail.com (Simon Schick)

--f46d044469252ba2b704ba0820f7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =3D unserialize($optionValue);
} catch (Exception $e) {
  $value =3D $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.michael@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 =3D 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 =3D "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 =3D 123;
>
> A is now type locked to integer. So
>
> $a =3D "456";
>
> will raise an E_Notice and so will
>
> $a =3D "Hello World";
>
> If we want $a to go back to being a scalar one might try...
>
> unset($a);
> $a =3D "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 =3D "456"
> foo($a);
>
> As proposed, works, no error as discussed above.
>
> $a =3D "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 <linepogl@gmail.com>
> wrote:
> > Hello everyone,
> >
> > Let's stop the religious war between strongly and weekly typed language=
s.
> > 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=C3=A9nieur Logiciel
> >
> >
> > 2012/2/28 Arvids Godjuks <arvids.godjuks@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
>
>

--f46d044469252ba2b704ba0820f7--