Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] Scalar type hinting

Posted by Samuel Deal 
Kris Craig
Re: [PHP-DEV] Scalar type hinting
February 27, 2012 10:34PM
Yeah again sorry about the 1. Another dyslexic moment on this end lol.

I don't care about the specific terminology we use, just so long as it
makes sense and people aren't confusing it with something else. I
differentiated between strong and weak in order to accommodate the looser
functionality that Arvids had suggested. I'm fine with just going with the
stronger approach and calling that weak if that's what everyone wants.

--Kris


On Mon, Feb 27, 2012 at 1:24 PM, Ferenc Kovacs <[email protected]> wrote:

>
>
> On Mon, Feb 27, 2012 at 8:15 PM, Kris Craig <[email protected]> wrote:
>
>> Now, to rewind a bit past the latest chunk of "I hate this idea" posts.....
>>
>> I'd like to suggest a new term: "strong".
>>
>
> I think it would be better if we could not introduce terms for new
> definition if that term is already used in the vocabulary for type systems:
> http://en.wikipedia.org/wiki/Strong_typing
>
>
>>
>> This term would be similar to "weak", except with a few key differences:
>>
>> - Weak would behave very much like Arvids suggested in his earlier
>> post; i.e. if the variable is an integer but you pass a string (like "aaa")
>> to it, a warning would be thrown and PHP would attempt to convert it (i.e.
>> it would become 1).
>>
>> why would "aaa" turn to 1? it would be 0 by the php type juggling rules.
>
>
>>
>> - Strong, on the other hand, would throw a fatal error if you
>> attempted to pass an incompatible value to an array. Or, to put it another
>> way, if the "converted" value does not match the original value. For
>> example, if we're assigning "aaa" to an integer, that would convert to 1;
>> and, since "1" != "aaa", a fatal error would be thrown. On the other hand,
>> if you were to pass the string "1" to that integer variable, it would
>> convert to 1; and, since "1" == 1, there wouldn't be a problem.
>>
>> same error here, it seems that it isn't the typo. putting that aside: so
> you say that the type checking would behave the same was as does currently
> the == and === operator.
>
>>
>> - In both instances, if the converted value matches the original
>> (i.e. "1" == 1), no warning error would be displayed. Should it perhaps
>> display a notice though? Or no error at all? I can think of reasonable
>> arguments on both sides of that question.
>>
>>
> I remember seeing that suggestion before, I think that it was proposed
> more than once, see
> http://marc.info/?l=php-internals&m=128159992610321&w=3
> did you read that thread?
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>
Anthony Ferrara
Re: [PHP-DEV] Scalar type hinting
February 27, 2012 11:00PM
Ferenc,

Thanks for the comments!

On Mon, Feb 27, 2012 at 4:09 PM, Ferenc Kovacs <[email protected]> wrote:
>
>
> On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara <[email protected]>
> wrote:
>>
>> > no, it is: "come back after you did your homework, and you can provide
>> > new
>> > arguments to the discussion"
>>
>>
>> To be completely fair, I did homework on this.  I went back to 2000 on
>> marc.info's archives and read almost all of the 400 posts matching the
>> search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
>> and a bunch of the posts on
>> http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=b
>>
>
> that's nice.
> as I mentioned in my previous (and maybe in some other) mail, I think that
> it would be __really__ nice to have those discussions summarized.
> sorry for replying your mail later than some others, but I was afraid of the
> wall of text. :)

Without committing to anything, I will try to find time to do so...

>> The vast majority of what I found were quite good arguments for
>> including the feature.  I found quite a bit of "this was discussed to
>> death, do your homework and provide new arguments".  What's odd, is
>> that one of the earliest on-topic threads that I found (2007:
>> http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
>> the third reply.  The only on-topic discussion that I found prior to
>> that was in 2006 (almost exactly 1 year prior:
>> http://marc.info/?l=php-internals&m=116257685415135&w=2 ).
>>
>> Discussed to death.  Yet only one time before (discussing a specific
>> patch)...
>
>
> I only joined the lists like 3 years ago, but I remember discussing this
> idea more than that.
> I can dig up the threads if you are interested, the biggest discussion was
> after Derick commited the scalar typehint patch from Ilia to trunk and after
> a pretty heated and long discussion and multiple alternative proposals the
> patch was reverted and Derick implemented a Reflection based infrastructure
> for checking the typehints.

Well, that's absolutely relevant, but that was for one of the
possibilities on how to implement it. But worth bringing up...

> some history:
> 2006
> http://derickrethans.nl/typehints-for-scalar-types.html
> http://php.markmail.org/message/nalhrp5n5p3srj7u#query:+page:1+mid:nalhrp5n5p3srj7u+state:results
> 2008
> https://wiki.php.net/rfc/typehint
> 2009
> http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html
> http://schlitt.info/opensource/blog/0712_scalar_type_hints_in_php.html
> 2010
> http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html
> http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html
> http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-trunk.html

That's quite helpful.

>>
>> And the opponents still said no...
>
>
> with the new RFC process there is a rule of thumb/gentlemen agreement that
> if a large portion of the core devs are against a specific change, then it
> shouldn't be added, or to form it otherwise consensus should be reached
> instead of pushing through changes by 50%+1 (or 66%+1).
> this specific change was such a controversial one that we couldn't reach
> conclusion..

I have no problem with the maintainers/core devs saying no if they
really feel it's bad (in fact, I agree with it). What I do have a
problem with is them (or anyone) saying no without understanding what
they are saying no to (which is obvious by some of the comments, and
by some of the banter about "PHP is not java").

>>
>> There were also quite a few problems identified with scalar hinting
>> and auto-casting vs strict erroring.  However, there were also
>> solutions proposed to nearly each and every one of them.
>
>
> There were ideas, but they didn't have enough traction.
> IMO we can't have a proper solution without changing the existing behavior
> for complex types, if you implement strict typing for scalars that turns the
> language strict typed, if you add dynamic/weak typing for the scalars, you
> will have an inconsistent implementation.

What behavior would need to be changed for complex types? Adding the
ability to hint/cast between trees? I'm kind of confused by this
bit...

>> And the opponents still said no...
>
>
> to tell the truth they said no, but it was the original commiter who
> reverted the change.
> (sorry Derick, I don't remember the details, feel free to correct me on
> this.)

Sure, but again, that's talking about implementing very strict typing
(fatal on incorrect). Which to be perfectly honest, I would say no to
as well. But I think there's enough merit to continue the discussion,
and separate the concepts... But very fair point...

>>
>>
>> It has been brought up time and time again.  Solutions have been
>> proposed which have no fundimental issues (inconsistencies,
>> problematic operations - such as references, etc)...
>
>
> maybe I missed those, what are you referring to?
> I see the ones that I linked + the following:
> https://wiki.php.net/rfc/typechecking
>
> https://wiki.php.net/rfc/autoboxing
> https://wiki.php.net/rfc/boxingandunboxing
> https://wiki.php.net/rfc/splweaktypehintingwithautoboxing

I'm talking about in the lists, message by message. Perhaps most of
them didn't actually get into RFC, or were glossed over, or lost in
the noise...

>>
>> And the opponents instead said "this has been discussed to death, no"...
>
>
> nope, they first discussed to death. then when people without much insight
> or knowledge without the past discussion brought back the topic, some people
> felt that it is too soon to discuss it again, as nothing new is on the
> table.

I understand that sentiment. I really do. But at the same token, why
do we need to kill the conversations from happening? Why not ignore
it if you think it's too soon, and let the others get to the point of
an RFC with patch, and then step in and see how the idea matured.

I think that's my biggest problem with the dynamics of this list.
Ideas aren't really nurtured as well as they could be. If the idea is
solid, and has an implementation, then it's great. But there are
plenty of seedling ideas that get lost or down trodden-ed simply
because it's not bulletproof...

>> Please can you stop saying "this has been discussed to death".  To be
>> frank, don't stop the discussion because you don't like the idea.  It
>> has been discussed to death.  But the discussion has only really ever
>> involved people who are for it.  The opponents by and large have used
>> two arguments: "It has been discussed already, so no" and "don't make
>> PHP into Java".
>
>
> I don't mind what others do with their free time, so feel free to discuss
> it, but somehow it seems for that some people are wasting their time running
> the same circles others did years before, and yelling others for not reading
> through 50 mails (from which maybe 5-10 has insightful comments) or wanting
> to discuss the topic in detail.
> I really think that after seeing this as a hot topic as it is, that we don't
> have a proper wiki page summarizing and linking all of the previous
> discussions. That way even if we can't find the final/best solution, we
> could continue the discussion anytime, and we could just point
> the newcomers to that page, and they would be able to catch up.
> I really think that it is no bad intention from the php devs side in this
> topic, but they are burned out discussing this, and the general tone and
> finger pointing of this thread doesn't really help the issue.
> If somebody have the time, and would like to move this forward, the first
> step would be to trying to understand the issue and hand, gathering all
> previous discussion/info available, creating a wiki page then:
> - document what is the current typehinting implementation, what are the
> pro/cons.
> - what are the pros/cons for scalar type hints in general.
> - what are the pros/cons for weak/strict scalar type hints in general
> - what are the previously suggested solutions/implementations, what are the
> pros/cons for them
> - (optionally do the same for the return type hints)

I think that was the point of this very thread, if I'm not mistaken...

>>
>> There has been some discussion of technical merit and problem
>> resolution by opponents, but finding it is VERY difficult among all
>> the down trodding commentary.
>
>
> I found your usage of the word opponent a little bit disturbing, but maybe
> I'm just thinking into it too much.

Well, I mean it as it comes off, to an extent. I mean the very small
group of people who are littered in these threads who are saying "PHP
is not Java" and shooting down the idea without even considering it
(in the least). If you don't think it can be done, that's a different
story. I'm talking about the people who have nothing constructive at
all to add, yet generate these long diatribes of dialog, without
getting anything done...

> I agree that it is frustrating if your arguments are turned down that "we
> already discussed that" (been there, done that. I mean in your situation)..
> I also think that it would also help if the signal/noise(+personal attack)
> ration would be better. Usually I try to follow the discussion on the list,
> but I have to tell you that I'm almost out of being able to do that, as the
> discussion seems to have lack of focus (Scalar type hinting, Object Casting,
> both spawned from the ENUM proposal and there are also 3-4 other hot topics
> currently.).
> I think that we all should calm down a little bit, and catch up with the
> reading and focus on how to solve the issue instead of just trying to prove
> that the "opponent" is wrong.

Sounds good to me!

>>
>>
>> So let me make a plea:
>>
>> If you don't like this feature, and you can explain from a TECHNICAL
>> perspective why, please do so!  If you don't like the feature, and are
>> going to lean on "It's not Java", or "We've discussed this to death
>> already", please don't...
>
>
> This goes both way, so one side would need to not turn down the other simply
> based on the past discussion, but the other side should also read those
> discussions if provided.

I think that's the problem. I don't mind "It has been discussed
before, here and here, can you solve those problems". If links are
provided, I think it's 100% reasonable to have people read the links
that were provided. I don't consider it reasonable to ask people to
"go read prior discussions" without any insight onto which (and which
are even valid anymore due to engine changes, and the like). That's
like telling someone to just go google it. Sure, but if you don't
know what you're looking for, a huge time waster (and a bit
disrespectful as well)...

> I think that I expressed my personal opinion and linked a few articles and I
> can also gather some of the discussions on the mailing list (at least what
> took place after me joining the list).
> Now it would be nice if you could point out that what are your solutions
> those technical arguments brought up there.

I'll go through them tonight when I get some free time.

Thanks a bunch,

Anthony

>>
>>
>>
>>
>> And to be fair: "and you can provide new arguments to the discussion"
>> has already happened quite a bit (dating back the past 5 years), but
>> those arguments were ignored or overruled for political reasons.
>
>
> I disagree.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
John Crenshaw
RE: [PHP-DEV] Scalar type hinting
February 27, 2012 11:32PM
> -----Original Message-----
> From: Kris Craig [mailto:[email protected]]
>
> Now, to rewind a bit past the latest chunk of "I hate this idea" posts.....
>
> I'd like to suggest a new term: "strong".
>
> This term would be similar to "weak", except with a few key differences:
>
> ...
>
> Some possible examples of how this would look:
>
> weak int $i = "aaa"; // Converts to 1 and throws a warning.
> strong int $ii = "aaa"; // Throws a fatal error.
> weak int $i = "1"; // Converts to 1.
> strong int $ii = "1"; // Converts to 1.
>
>
> --Kris

Can we use a different word (not "strong") at least for just discussion purposes? I worry that "strong" will produce a feeling of intense fear and anxiety in people who have been burned out by strict typing debates. The words "strong" and "strict" are basically inflammatory at this point. In the interest of facilitating a reasonable discussion, I think we should avoid language that is likely to cause discussion to break down.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
John Crenshaw
RE: [PHP-DEV] Scalar type hinting
February 27, 2012 11:32PM
> -----Original Message-----
> From: John LeSueur [mailto:[email protected]]
>
> Maybe this discussion should start from the end of the last discussion on non-strict type hints, where really smart people came up with some options to handle the conversion:
>
> https://wiki.php.net/rfc/typecheckingstrictandweak#option_1_current_type_juggeling_rules_with_e_strict_on_data_loss
>
> The RFC talks about throwing E_STRICT or E_FATAL, and has a couple of options for a matrix of conversion rules.

I've actually read that proposal. To some level it is good, but I felt like there were too many problems. E_ERROR is overkill. For comparison, (function (array $bar) {})('a') generates a catchable fatal error (E_RECOVERABLE_ERROR) so that's the furthest this should go in any case, but when dealing with jugglable types and there's just some unexpected data loss even E_RECOVERABLE_ERROR is too much IMO; E_WARNING or E_NOTICE would be more appropriate. IIRC it also failed conversions too aggressively.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] Scalar type hinting
February 27, 2012 11:40PM
I think this is the main reason for differentiating between "strong" (or
whatever word is appropriate) and "weak." The developer may very well want
their script to blow-up in such a case.

I would liken this to the fact that we have both an "include" statement and
a "require" statement. One is recoverable, the other is not. I think the
same principle applies here.

--Kris


On Mon, Feb 27, 2012 at 2:31 PM, John Crenshaw <[email protected]>wrote:

> Inline
>
> > -----Original Message-----
> > From: Richard Lynch [mailto:[email protected]]
> >
> > On Mon, February 27, 2012 1:15 pm, Kris Craig wrote:
> > > Now, to rewind a bit past the latest chunk of "I hate this idea"
> > > posts....
> > >
> > > I'd like to suggest a new term: "strong".
> > >
> > > This term would be similar to "weak", except with a few key
> > > differences:
> > >
> > > - Weak would behave very much like Arvids suggested in his earlier
> > > post;
> > > i.e. if the variable is an integer but you pass a string (like
> > > "aaa") to
> > > it, a warning would be thrown and PHP would attempt to convert it
> > > (i.e. it
> > > would become 1).
> >
> > Nitpick:
> > Two backwards compatibility breaks:
> > 1) Throwing E_WARNING
> > 2) "aaa" converted to (int) is 0.
>
> Sorry, I don't understand the BC break on the warning. Old code doesn't
> have this anyway, so what exactly would break? Shouldn't all existing
> scripts continue to work exactly the same as before unless they add a type
> check?
>
> (I'm sure the example was just wrong, "aaa" should convert to 0)
>
> > > strong int $ii = "aaa"; // Throws a fatal error.
> >
> > Okay.
> >
> > E_FATAL seems drastic to me, but I'm not even going to use "strong" so
> don't really care either way, I suppose.
>
> I totally agree. E_RECOVERABLE_ERROR is the most severe that this should
> be (also matches the behavior of current type hints).
>
> > > weak int $i = "1"; // Converts to 1.
> >
> > Again, old-school (int) or set_type covers this.
>
> Unfortunately it doesn't completely. Yes, behavior is the same so long as
> the conversion is good, but a cast will silently accept impossible
> conversions, which is not what you really want here.
>
> John Crenshaw
> Priacta, Inc.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
John Crenshaw
RE: [PHP-DEV] Scalar type hinting
February 27, 2012 11:40PM
> Would "firm" work better?
>
> --Kris

As a working name that would be fine. Of course, if this discussion moves to a sub-group that becomes less critical since it would be less likely for people to jump in the middle and misunderstand the terms.

John Crenshaw
Priacta, Inc.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield
Re: [PHP-DEV] Scalar type hinting
February 27, 2012 11:51PM
That's going to get turned into the "real" name if used. I suggest instead:

Gribblefritz.

Gribble typing: the type handling that PHP does today in 5.3/5.4 for
scalar values.

Fritz typing: Some as-yet-undefined type handling that is pickier than
Gribble typing, but how much pickier is unclear.

That, at least, no one has any pre-conceived definition of.

--Larry Garfield

On 2/27/12 4:31 PM, Kris Craig wrote:
> Would "firm" work better?
>
> --Kris
>
>
> On Mon, Feb 27, 2012 at 2:27 PM, John Crenshaw<[email protected]>wrote:
>
>>> -----Original Message-----
>>> From: Kris Craig [mailto:[email protected]]
>>>
>>> Now, to rewind a bit past the latest chunk of "I hate this idea"
>> posts....
>>>
>>> I'd like to suggest a new term: "strong".
>>>
>>> This term would be similar to "weak", except with a few key differences:
>>>
>>> ...
>>>
>>> Some possible examples of how this would look:
>>>
>>> weak int $i = "aaa"; // Converts to 1 and throws a warning.
>>> strong int $ii = "aaa"; // Throws a fatal error.
>>> weak int $i = "1"; // Converts to 1.
>>> strong int $ii = "1"; // Converts to 1.
>>>
>>>
>>> --Kris
>>
>> Can we use a different word (not "strong") at least for just discussion
>> purposes? I worry that "strong" will produce a feeling of intense fear and
>> anxiety in people who have been burned out by strict typing debates. The
>> words "strong" and "strict" are basically inflammatory at this point. In
>> the interest of facilitating a reasonable discussion, I think we should
>> avoid language that is likely to cause discussion to break down.
>>
>> John Crenshaw
>> Priacta, Inc.
>>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ángel González
Re: [PHP-DEV] Scalar type hinting
February 27, 2012 11:51PM
On 27/02/12 20:05, Richard Lynch wrote:
> You are correct.
>
> I'd have to come up with some OTHER scenario not involving fatal
> error, such as:
>
> strict $db = new DB();
>
> and your database being down, unavailable, or connection parameters
> being wrong.
>
> The principle remains.
>
> You probably still want $db to be NULL in that situation, rather than
> an unusable DB object.
>
> Otherwise, you'll have to write a lot more sanity checking code
> elsewhere, which is what you are trying to avoid in the first place...
>
> Or, perhaps not.
>
> Perhaps you really do want this case to just plain bomb out with a
> failure that the $db is not strictly an object, with no recourse to
> try again, or deal with the error in application logic...
It could be throwing an exception.
You usually want it to be just what you want. In some cases you may
want to accept NULLs. You should provide a different qualifier in that
case, such as "strict?"

Yes, you may end up with things like

nullable strict DB $db = DB::factory();


which doesn't look like PHP at all. But I suppose that's what you wanted?



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 12:10AM
No that's like a million times worse, Larry!! Gaylord T. Gribblefritz III
was a serial killer who terrorized the midwest for over 40 years! That
monster murdered me and my entire family! He would sell milk laced with
sleeping pills to school children then take them back to his secluded
ranch, where wealthy businessmen would hunt them for sport. The
International Criminal Court has accused him of committing the worst crimes
against humanity in the last 10,000 years and the Aryan Nations has run
television ads saying this man proves that Hitler really wasn't all that
bad, after all. The Israelis and Palestinians issued a joint statement
condemning this man's violence. The Dalai Lama has gone on record, saying,
"Shit, even I think we should kill this fucking asshole!"

Also, Mr. Gribblefritz (or "Satan's Evil Twin" as they call him in Utah)
recently wrote an op-ed arguing that PHP should be re-written in Fortran
and that its syntax should be changed to resemble QBASIC.


How DARE you insult this list by suggesting THE MOST INFLAMMATORY WORD OF
ALL TIME?!?! You should be Gribblefritzed (you don't want to know) for
even suggesting something so horrible! It's like, FIFTY TRILLION TIMES
WORSE than "strong"!

Other than that, though, I think it's a good idea. ;P

--Kris



On Mon, Feb 27, 2012 at 2:41 PM, Larry Garfield <[email protected]>wrote:

> That's going to get turned into the "real" name if used. I suggest
> instead:
>
> Gribblefritz.
>
> Gribble typing: the type handling that PHP does today in 5.3/5.4 for
> scalar values.
>
> Fritz typing: Some as-yet-undefined type handling that is pickier than
> Gribble typing, but how much pickier is unclear.
>
> That, at least, no one has any pre-conceived definition of.
>
> --Larry Garfield
>
>
> On 2/27/12 4:31 PM, Kris Craig wrote:
>
>> Would "firm" work better?
>>
>> --Kris
>>
>>
>> On Mon, Feb 27, 2012 at 2:27 PM, John Crenshaw<johncrenshaw@priacta.**com<[email protected]>
>> >wrote:
>>
>> -----Original Message-----
>>>> From: Kris Craig [mailto:[email protected]]
>>>>
>>>> Now, to rewind a bit past the latest chunk of "I hate this idea"
>>>>
>>> posts....
>>>
>>>>
>>>> I'd like to suggest a new term: "strong".
>>>>
>>>> This term would be similar to "weak", except with a few key differences:
>>>>
>>>> ...
>>>>
>>>> Some possible examples of how this would look:
>>>>
>>>> weak int $i = "aaa"; // Converts to 1 and throws a warning.
>>>> strong int $ii = "aaa"; // Throws a fatal error.
>>>> weak int $i = "1"; // Converts to 1.
>>>> strong int $ii = "1"; // Converts to 1.
>>>>
>>>>
>>>> --Kris
>>>>
>>>
>>> Can we use a different word (not "strong") at least for just discussion
>>> purposes? I worry that "strong" will produce a feeling of intense fear
>>> and
>>> anxiety in people who have been burned out by strict typing debates. The
>>> words "strong" and "strict" are basically inflammatory at this point. In
>>> the interest of facilitating a reasonable discussion, I think we should
>>> avoid language that is likely to cause discussion to break down.
>>>
>>> John Crenshaw
>>> Priacta, Inc.
>>>
>>>
>>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Ángel González
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 12:41AM
On 27/02/12 22:52, Anthony Ferrara wrote:
> Ferenc,
>
> Thanks for the comments!
Thanks from me, too.

And thanks to you, Anthony if you get to summarise that.


>> There were ideas, but they didn't have enough traction.
>> IMO we can't have a proper solution without changing the existing behavior
>> for complex types, if you implement strict typing for scalars that turns the
>> language strict typed, if you add dynamic/weak typing for the scalars, you
>> will have an inconsistent implementation.
> What behavior would need to be changed for complex types? Adding the
> ability to hint/cast between trees? I'm kind of confused by this
> bit...
I suspect one of the scalars should be complex (= objects?)



> I think that's my biggest problem with the dynamics of this list.
> Ideas aren't really nurtured as well as they could be. If the idea is
> solid, and has an implementation, then it's great. But there are
> plenty of seedling ideas that get lost or down trodden-ed simply
> because it's not bulletproof...
Yes, the noise ratio of this list is quite high. Probably related to its
high
volume. That makes people faster in discarding ideas as "been there"
and generates friction. And low-quality discussions like that don't
attract smart people insights, precisely.
It's a vicious circle.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 12:41AM
I agree. What does everyone think about the idea of creating a new list
specifically discussion of new feature ideas? The idea could be announced
on the Internals list with a link to the discussion on the other list.
That way, the noise ratio would be reduced and only those who are
interested in brainstorming new ideas would have to listen to it.

Thoughts?

--Kris


2012/2/27 Ángel González <[email protected]>

> On 27/02/12 22:52, Anthony Ferrara wrote:
> > Ferenc,
> >
> > Thanks for the comments!
> Thanks from me, too.
>
> And thanks to you, Anthony if you get to summarise that.
>
>
> >> There were ideas, but they didn't have enough traction.
> >> IMO we can't have a proper solution without changing the existing
> behavior
> >> for complex types, if you implement strict typing for scalars that
> turns the
> >> language strict typed, if you add dynamic/weak typing for the scalars,
> you
> >> will have an inconsistent implementation.
> > What behavior would need to be changed for complex types? Adding the
> > ability to hint/cast between trees? I'm kind of confused by this
> > bit...
> I suspect one of the scalars should be complex (= objects?)
>
>
>
> > I think that's my biggest problem with the dynamics of this list.
> > Ideas aren't really nurtured as well as they could be. If the idea is
> > solid, and has an implementation, then it's great. But there are
> > plenty of seedling ideas that get lost or down trodden-ed simply
> > because it's not bulletproof...
> Yes, the noise ratio of this list is quite high. Probably related to its
> high
> volume. That makes people faster in discarding ideas as "been there"
> and generates friction. And low-quality discussions like that don't
> attract smart people insights, precisely.
> It's a vicious circle.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Ángel González
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 12:41AM
Kris, go out for a walk. We don't need fake
stress after the real one :)

Yes, it's midnight here, but who cares?
That you are afraid of going out at night? Because
you had a bad experience with a serial killer?
Oh, well...


PS: This is what I called 'sane weak typing' in the other
thread before you proposed 'strong'...


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 12:50AM
Lol I'm not worried. Gribblefritz may be a psychopatic serial killer, but
he's also my personal bodyguard. What could possibly go wrong?

--Kris


2012/2/27 Ángel González <[email protected]>

> Kris, go out for a walk. We don't need fake
> stress after the real one :)
>
> Yes, it's midnight here, but who cares?
> That you are afraid of going out at night? Because
> you had a bad experience with a serial killer?
> Oh, well...
>
>
> PS: This is what I called 'sane weak typing' in the other
> thread before you proposed 'strong'...
>
>
John Crenshaw
RE: [PHP-DEV] Scalar type hinting
February 28, 2012 05:50AM
I don't think we need yet another list. That said, I think that some features (such as weak typing) would benefit greatly from having a small body of people get together and flesh out a proposal together before presenting it for sacrifice on the altar of public discussion. Part of the value in this is keeping the group limited to just collaborators on that specific feature, so a general features mailing list wouldn't really add anything.

Not sure how you want to coordinate this group. In my company we have a distributed team and we typically coordinate this sort of design process using Google Docs + Donedesk(our own product, but free) + Skype. This works well and strikes a nice balance between persistent and realtime collaboration. I'm open to other ideas, but if I had to choose how to coordinate a group to design a single feature, that's what I would use.

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: Kris Craig [mailto:[email protected]]
Sent: Monday, February 27, 2012 6:36 PM
To: Ángel González
Cc: Anthony Ferrara; Ferenc Kovacs; Michael Morris; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting

I agree. What does everyone think about the idea of creating a new list specifically discussion of new feature ideas? The idea could be announced on the Internals list with a link to the discussion on the other list.
That way, the noise ratio would be reduced and only those who are interested in brainstorming new ideas would have to listen to it.

Thoughts?

--Kris


2012/2/27 Ángel González <[email protected]>

> On 27/02/12 22:52, Anthony Ferrara wrote:
> > Ferenc,
> >
> > Thanks for the comments!
> Thanks from me, too.
>
> And thanks to you, Anthony if you get to summarise that.
>
>
> >> There were ideas, but they didn't have enough traction.
> >> IMO we can't have a proper solution without changing the existing
> behavior
> >> for complex types, if you implement strict typing for scalars that
> turns the
> >> language strict typed, if you add dynamic/weak typing for the
> >> scalars,
> you
> >> will have an inconsistent implementation.
> > What behavior would need to be changed for complex types? Adding
> > the ability to hint/cast between trees? I'm kind of confused by
> > this bit...
> I suspect one of the scalars should be complex (= objects?)
>
>
>
> > I think that's my biggest problem with the dynamics of this list.
> > Ideas aren't really nurtured as well as they could be. If the idea
> > is solid, and has an implementation, then it's great. But there are
> > plenty of seedling ideas that get lost or down trodden-ed simply
> > because it's not bulletproof...
> Yes, the noise ratio of this list is quite high. Probably related to
> its high volume. That makes people faster in discarding ideas as "been
> there"
> and generates friction. And low-quality discussions like that don't
> attract smart people insights, precisely.
> It's a vicious circle.
>
>
> --
> 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
Kris Craig
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 06:00AM
Lol you're making me feel like an old fogey! I've always just used
email/listservs (or carrier pigeon if I'm getting a busy signal dialing in
to AOL).

Either way, I think we should give serious thought to how we move forward
on this, as it could wind up being a blueprint for future PHP feature
collaborations. I do agree with all your points though. Let me ponder
over it a little bit then get back to ya, just in case I have a better idea
that I haven't thought of yet. ;)

--Kris


2012/2/27 John Crenshaw <[email protected]>

> I don't think we need yet another list. That said, I think that some
> features (such as weak typing) would benefit greatly from having a small
> body of people get together and flesh out a proposal together before
> presenting it for sacrifice on the altar of public discussion. Part of the
> value in this is keeping the group limited to just collaborators on that
> specific feature, so a general features mailing list wouldn't really add
> anything.
>
> Not sure how you want to coordinate this group. In my company we have a
> distributed team and we typically coordinate this sort of design process
> using Google Docs + Donedesk(our own product, but free) + Skype. This works
> well and strikes a nice balance between persistent and realtime
> collaboration. I'm open to other ideas, but if I had to choose how to
> coordinate a group to design a single feature, that's what I would use.
>
> John Crenshaw
> Priacta, Inc.
>
> -----Original Message-----
> From: Kris Craig [mailto:[email protected]]
> Sent: Monday, February 27, 2012 6:36 PM
> To: Ángel González
> Cc: Anthony Ferrara; Ferenc Kovacs; Michael Morris;
> internals@lists.php.net
> Subject: Re: [PHP-DEV] Scalar type hinting
>
> I agree. What does everyone think about the idea of creating a new list
> specifically discussion of new feature ideas? The idea could be announced
> on the Internals list with a link to the discussion on the other list.
> That way, the noise ratio would be reduced and only those who are
> interested in brainstorming new ideas would have to listen to it.
>
> Thoughts?
>
> --Kris
>
>
> 2012/2/27 Ángel González <[email protected]>
>
> > On 27/02/12 22:52, Anthony Ferrara wrote:
> > > Ferenc,
> > >
> > > Thanks for the comments!
> > Thanks from me, too.
> >
> > And thanks to you, Anthony if you get to summarise that.
> >
> >
> > >> There were ideas, but they didn't have enough traction.
> > >> IMO we can't have a proper solution without changing the existing
> > behavior
> > >> for complex types, if you implement strict typing for scalars that
> > turns the
> > >> language strict typed, if you add dynamic/weak typing for the
> > >> scalars,
> > you
> > >> will have an inconsistent implementation.
> > > What behavior would need to be changed for complex types? Adding
> > > the ability to hint/cast between trees? I'm kind of confused by
> > > this bit...
> > I suspect one of the scalars should be complex (= objects?)
> >
> >
> >
> > > I think that's my biggest problem with the dynamics of this list.
> > > Ideas aren't really nurtured as well as they could be. If the idea
> > > is solid, and has an implementation, then it's great. But there are
> > > plenty of seedling ideas that get lost or down trodden-ed simply
> > > because it's not bulletproof...
> > Yes, the noise ratio of this list is quite high. Probably related to
> > its high volume. That makes people faster in discarding ideas as "been
> > there"
> > and generates friction. And low-quality discussions like that don't
> > attract smart people insights, precisely.
> > It's a vicious circle.
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > visit: http://www.php.net/unsub.php
> >
> >
>
Arvids Godjuks
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 10:42AM
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
Lazare Inepologlou
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 03:40PM
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 <[email protected]>

> 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
>
>
Michael Morris
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 04:32PM
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 <[email protected]> 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 <[email protected]>
>
>> 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
Simon Schick
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 04:50PM
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 <[email protected]>

> 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 <[email protected]>
> 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 <[email protected]>
> >
> >> 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
>
>
Arvids Godjuks
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 05:11PM
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 <[email protected]>:
> 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 <[email protected]> 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 <[email protected]>
>>
>>> 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
Simon Schick
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 07:42PM
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 <[email protected]>

> 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 <[email protected]>:
> > 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 <[email protected]>
> 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 <[email protected]>
> >>
> >>> 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
>
>
Kris Craig
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 09:00PM
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
<[email protected]>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 <[email protected]>
>
> > 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 <[email protected]>:
> > > 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 <
> linepogl@gm[email protected]>
> > 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 <[email protected]>
> > >>
> > >>> 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
> >
> >
>
John Crenshaw
RE: [PHP-DEV] Scalar type hinting
February 28, 2012 09:00PM
OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect ("strict typing" means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms:

- "Strict Typing" means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.)
- "Weak Typing" means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, "2") == "345".) (If you think you want "strict typing", this is probably what you mean.)
- "No Scalar Typing" should be used to indicate the current system (where there is no provision for hinting at scalar types.)

In addition, if someone potentially new expresses support for "Strict Typing", please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want "Strict Typing" (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are.

John Crenshaw
Priacta, Inc.
Michael Morris
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 09:10PM
Thank you.

Now I'm going to go work up a detailed RFC for what I posted earlier
with some additional clarification as to when errors should and
shouldn't be thrown.

On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw <[email protected]> wrote:
> OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect ("strict typing" means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms:
>
> - "Strict Typing" means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.)
> - "Weak Typing" means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, "2") == "345".) (If you think you want "strict typing", this is probably what you mean.)
> - "No Scalar Typing" should be used to indicate the current system (where there is no provision for hinting at scalar types.)
>
> In addition, if someone potentially new expresses support for "Strict Typing", please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want "Strict Typing" (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are.
>
> John Crenshaw
> Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Anthony Ferrara
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 09:20PM
Can I make a suggestion? Instead of an rfc, can we collate the existing
discussion into an easier to digest format (historical as well). Summarize
the conversations and existing rfcs with the discussion around them
(including the pros/cons and problems). That way we have a point of
reference and comparison with which to base the rfc on, and a way to judge
and rate the rfc...

Anthony
On Feb 28, 2012 3:09 PM, "Kris Craig" <[email protected]> wrote:

> @Michael Would you be willing to delay that? Rather than create a bunch of
> new RFC's, I was thinking it might be better if all interested parties came
> together on some other communication medium and worked on a single,
> collaborative RFC instead.
>
> --Kris
>
>
> On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris <[email protected]
> >wrote:
>
> > Thank you.
> >
> > Now I'm going to go work up a detailed RFC for what I posted earlier
> > with some additional clarification as to when errors should and
> > shouldn't be thrown.
> >
> > On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw <[email protected]
> >
> > wrote:
> > > OK everyone, it seems that some people have forgotten or missed the
> > original agreement that this thread started with. There is a
> communication
> > disconnect ("strict typing" means horribly different things to different
> > people right now). Please read through and understand the following
> > terminology before continuing to post on this thread. We've agreed to the
> > following terms:
> > >
> > > - "Strict Typing" means the super strict old C style typing *with no
> > implicit conversions*. (If you really think this is what you want, you
> are
> > probably mistaken. Look through prior discussions on this topic. This
> fails
> > for numerous reasons, including the fact that almost every input to PHP
> is
> > a string.)
> > > - "Weak Typing" means types in the same sense that the PHP
> documentation
> > uses types (for example, the docs indicate substr(string, integer), and
> > substr(12345, "2") == "345".) (If you think you want "strict typing",
> this
> > is probably what you mean.)
> > > - "No Scalar Typing" should be used to indicate the current system
> > (where there is no provision for hinting at scalar types.)
> > >
> > > In addition, if someone potentially new expresses support for "Strict
> > Typing", please assume that they really mean weak typing unless proven
> > otherwise (this is by far the more likely intent.) Don't get mean,
> politely
> > clarify terminology so that everyone can be on the same page. If someone
> > still insists that they want "Strict Typing" (as defined above), point
> them
> > to the prior discussions on the topic which explain exactly what the
> > problems with this are.
> > >
> > > John Crenshaw
> > > Priacta, Inc.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
Adam Richardson
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 09:20PM
On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw <[email protected]>wrote:

> OK everyone, it seems that some people have forgotten or missed the
> original agreement that this thread started with. There is a communication
> disconnect ("strict typing" means horribly different things to different
> people right now). Please read through and understand the following
> terminology before continuing to post on this thread. We've agreed to the
> following terms:
>
> - "Strict Typing" means the super strict old C style typing *with no
> implicit conversions*. (If you really think this is what you want, you are
> probably mistaken. Look through prior discussions on this topic. This fails
> for numerous reasons, including the fact that almost every input to PHP is
> a string.)
>

Where is the term "strict typing" coming from? I've not seen this used to
describe any type system (doesn't mean it's not been used, but I'd really
like to see the usage so I can understand the label.)


> - "Weak Typing" means types in the same sense that the PHP documentation
> uses types (for example, the docs indicate substr(string, integer), and
> substr(12345, "2") == "345".) (If you think you want "strict typing", this
> is probably what you mean.)
>

Doesn't weak typing mean that the language implicitly converts types for
use according to a set of rules? The opposite of this being strong typing,
which means the language does not perform implicit conversions.


> - "No Scalar Typing" should be used to indicate the current system (where
> there is no provision for hinting at scalar types.)
>

And, curious about the "No Scalar Typing"?

Sorry for the questions.

Thanks,

Adam

--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
Kris Craig
Re: [PHP-DEV] Scalar type hinting
February 28, 2012 09:32PM
+1 what Anthony said.

I think it would be prudent, as some have already suggested, for those of
us who are interested in this topic to move it to a more discreet location
so as to reduce some of the noise all around. I'll take a look at Google
docs and see if that will suit our purposes. If anyone else has any ideas
on this, please share them! =)

--Kris


On Tue, Feb 28, 2012 at 12:18 PM, Adam Richardson <[email protected]>wrote:

> On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw <[email protected]
> >wrote:
>
> > OK everyone, it seems that some people have forgotten or missed the
> > original agreement that this thread started with. There is a
> communication
> > disconnect ("strict typing" means horribly different things to different
> > people right now). Please read through and understand the following
> > terminology before continuing to post on this thread. We've agreed to the
> > following terms:
> >
> > - "Strict Typing" means the super strict old C style typing *with no
> > implicit conversions*. (If you really think this is what you want, you
> are
> > probably mistaken. Look through prior discussions on this topic. This
> fails
> > for numerous reasons, including the fact that almost every input to PHP
> is
> > a string.)
> >
>
> Where is the term "strict typing" coming from? I've not seen this used to
> describe any type system (doesn't mean it's not been used, but I'd really
> like to see the usage so I can understand the label.)
>
>
> > - "Weak Typing" means types in the same sense that the PHP documentation
> > uses types (for example, the docs indicate substr(string, integer), and
> > substr(12345, "2") == "345".) (If you think you want "strict typing",
> this
> > is probably what you mean.)
> >
>
> Doesn't weak typing mean that the language implicitly converts types for
> use according to a set of rules? The opposite of this being strong typing,
> which means the language does not perform implicit conversions.
>
>
> > - "No Scalar Typing" should be used to indicate the current system (where
> > there is no provision for hinting at scalar types.)
> >
>
> And, curious about the "No Scalar Typing"?
>
> Sorry for the questions.
>
> Thanks,
>
> Adam
>
> --
> Nephtali: A simple, flexible, fast, and security-focused PHP framework
> http://nephtaliproject.com
>
John Crenshaw
RE: [PHP-DEV] Scalar type hinting
February 28, 2012 09:32PM
Inline. Quoted portion edited extensively for brevity.

> -----Original Message-----
> From: Michael Morris [mailto:[email protected]]
>
> $a = 123;
> function foo ( int $i ) {}
> foo($a); // OK
>
> foo("123"); // NOTICE, because "123" is a constant
>
> $a = "456";
> foo($a); // OK, because conversion is lossless
>

-1. Should be no notice in either of the last two cases. Raising the notice when a constant is used is inconsistent and confusing. I also doubt that this sort of implementation is even possible without some pretty massive internal changes. Not worth it IMO.

> int $a = 123; // "type locked" to integer
>
> $a = "456"; // E_NOTICE
>
> $a = "Hello World"; // E_NOTICE

I'm very dubious on hinting variables. This would require storing additional data with the variable, which (as far as I can see) would break binary compatibility (same problem as taint). I don't see much of a use for this most of the time, with the notable exception of member variables (sometimes type locking a class member would be really nice.)

Also, there should be no notice in case 2 (same argument as before with functions)

Notice on case 3 is fine

>
> unset($a);
> $a = "Hello World"; // OK, because of unset
>
> int $a; // E_NOTICE, $a had a value which can't convert without loss of data.

This just seems silly to me. Trying to declare int $a after $a is already present and set is a nonsense construct. I think E_RECOVERABLE_ERROR should be raised on this and $a should be set to null regardless of convertibility (the more likely intent and meaning of that line of code) in case the error handler decides to continue execution.

> scalar $a;

-1, I don't think we need this any more than we need an explicit "mixed" type. Saying "this function needs a number or it can't work" is one thing. There is a sound logical foundation for that. A scalar could be anything though. You're still going to have to check types to decide what you really have and alter code paths as appropriate.

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

-1, same argument as int $a; when $a is already set. This is a nonsensical construction. You are using a variable declaration like a typecast and reusing a variable. This is sloppy and confusing to reduce code in a badly structured edge case. If you really honestly must untype a local variable, you can always do this instead:

$tmp = $a;
unset($a);
$a = $tmp;

BUT, if there is any reason why you would actually need to untype a variable, then there are much bigger problems. This shouldn't be handled in the core language.

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

If using types causes a large number of unnecessary notices that's a spec problem. The core devs aren't going to accept that.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
John Crenshaw
RE: [PHP-DEV] Scalar type hinting
February 28, 2012 10:00PM
From: Adam Richardson [mailto:[email protected]]

On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw <[email protected]<mailto:[email protected]>> wrote:
OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect ("strict typing" means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms:

- "Strict Typing" means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.)

Where is the term "strict typing" coming from? I've not seen this used to describe any type system (doesn't mean it's not been used, but I'd really like to see the usage so I can understand the label.)

Adam, When you say you want "Strict" or "Strong" typing, this (case 1) is what the opponents of stronger typing think you are asking for, which is why I've defined it this way. There have been a tiny handful of individuals that really are asking for this, but most people don't really want this level of strictness. Also, this level of strictness is fundamentally at odds with the nature of PHP, and it's just never going to happen. The level of typing in this first case is littered with problems. I won't get into it all, but you can read prior discussions in the archives to see it. Look for the passionate arguments made by typing opponents that talk about "massive changes", "destroying the language", and "Go use JSP". Scattered in there are some occasional explanations of the actual core issues, all of which refer to this level of typing. (Incidentally, even C++ is not this strict, so this really isn't what you want, I'm sure of it. If this is what you want, then this isn't the thread for you, because this is *not* what will be advocated or discussed here.)

- "Weak Typing" means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, "2") == "345".) (If you think you want "strict typing", this is probably what you mean.)

Doesn't weak typing mean that the language implicitly converts types for use according to a set of rules? The opposite of this being strong typing, which means the language does not perform implicit conversions.

"Weak" here really means weaker than the "Strong" above, but stronger than "none". Right now PHP has no typing whatsoever. "weak typing" WOULD be typing, but it is flexible, optional, and aggressively uses implicit conversions. For comparison, by these definitions C++ is halfway between "weak typing" and "strong typing" (by virtue of operator overloads, overloaded functions, and cast operators.)

This "Weak typing" will give you what you want, and it can work. Most importantly, it is *not* the thing that goes bump in the night for most strong typing opponents, which means it is probably possible to gather sufficient support for this. This discussion is focused on developing a rock solid proposal for "weak typing".

- "No Scalar Typing" should be used to indicate the current system (where there is no provision for hinting at scalar types.)

And, curious about the "No Scalar Typing"?

This is PHP right now. The language has no provision whatsoever for scalar types. Function parameters can be hinted as an array or as a specific class/interface, but otherwise they are assumed to be absolutely anything. I know that for people with a lot of experience in a strongly typed language this sounds like what they would normally call "Weak Typing", but it's a 3rd level. "Weak Typing" under these definitions is a lot stronger than what you would call "weak", but it's much weaker than what strong typing opponents would call "strong".

It's going to take some time to get used to the semantics, but if you want any typing enhancements you're going to have to speak the language of the people you want to convince. The communication disconnect here has been sinking this proposal for a decade.

John Crenshaw
Priacta, Inc.
John Crenshaw
RE: [PHP-DEV] Scalar type hinting
February 28, 2012 10:11PM
Yeah, I proposed this the other day. We need to go through the hundreds of historical emails on the subject and consolidate all the information into a central document outlining all the information that has been developed over the years. Lots of benefits to this. If multiple people want to participate in this process we can probably partition it by date ranges.

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: Anthony Ferrara [mailto:[email protected]]
Sent: Tuesday, February 28, 2012 3:15 PM
To: Kris Craig
Cc: internals@lists.php.net; Arvids Godjuks; Michael Morris; Lazare Inepologlou
Subject: Re: [PHP-DEV] Scalar type hinting

Can I make a suggestion? Instead of an rfc, can we collate the existing discussion into an easier to digest format (historical as well). Summarize the conversations and existing rfcs with the discussion around them (including the pros/cons and problems). That way we have a point of reference and comparison with which to base the rfc on, and a way to judge and rate the rfc...

Anthony
On Feb 28, 2012 3:09 PM, "Kris Craig" <[email protected]> wrote:

> @Michael Would you be willing to delay that? Rather than create a
> bunch of new RFC's, I was thinking it might be better if all
> interested parties came together on some other communication medium
> and worked on a single, collaborative RFC instead.
>
> --Kris
>
>
> On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris
> <[email protected]
> >wrote:
>
> > Thank you.
> >
> > Now I'm going to go work up a detailed RFC for what I posted earlier
> > with some additional clarification as to when errors should and
> > shouldn't be thrown.
> >
> > On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw
> > <[email protected]
> >
> > wrote:
> > > OK everyone, it seems that some people have forgotten or missed
> > > the
> > original agreement that this thread started with. There is a
> communication
> > disconnect ("strict typing" means horribly different things to
> > different people right now). Please read through and understand the
> > following terminology before continuing to post on this thread.
> > We've agreed to the following terms:
> > >
> > > - "Strict Typing" means the super strict old C style typing *with
> > > no
> > implicit conversions*. (If you really think this is what you want,
> > you
> are
> > probably mistaken. Look through prior discussions on this topic.
> > This
> fails
> > for numerous reasons, including the fact that almost every input to
> > PHP
> is
> > a string.)
> > > - "Weak Typing" means types in the same sense that the PHP
> documentation
> > uses types (for example, the docs indicate substr(string, integer),
> > and substr(12345, "2") == "345".) (If you think you want "strict
> > typing",
> this
> > is probably what you mean.)
> > > - "No Scalar Typing" should be used to indicate the current system
> > (where there is no provision for hinting at scalar types.)
> > >
> > > In addition, if someone potentially new expresses support for
> > > "Strict
> > Typing", please assume that they really mean weak typing unless
> > proven otherwise (this is by far the more likely intent.) Don't get
> > mean,
> politely
> > clarify terminology so that everyone can be on the same page. If
> > someone still insists that they want "Strict Typing" (as defined
> > above), point
> them
> > to the prior discussions on the topic which explain exactly what the
> > problems with this are.
> > >
> > > John Crenshaw
> > > Priacta, Inc.
> >
> > --
> > 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
Sorry, only registered users may post in this forum.

Click here to login