Annoucing PHP 5.4 Alpha 1

They aren't hints. It is strict typing and in its current form I would
ask you guys not to call the 5.4 release PHP. Because it won't be.

Fully agreed.

I'd suggest "NoPHP".  "AntiPHP" might also work.

- Sascha

Victor Bolshov wrote:

Having two similar syntaxes that work differently - would make the
situation even worse that it is now - I beleive. And I totally agree
with Rasmus - strict typed language mustnt be called PHP. (Just a poor
user's notice to all of you internals' geeks out there)

2010/8/11 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

1. right now we have strict type checks for classes and arrays in the
   form of "classname" or "array"
   Because classes and arrays were never intechangeable types and there was
   never implicit or explicit conversion between SplRecursiveTreeIterator and
   Zend_Pdf_Generator - it doesn't even make sense to suggest it. There always
   was conversion between int and string or int and bool. These two things are
   completely different.

2. the strict scalary type hint patch reuses this same syntax in the
   form of<type-name> to do the same thing in function arguments
   It's not a good thing. As I mentioned, primitive types and classes are very
   different in their use cases and established patterns in PHP. Primitive
   types are largely interchangeable, classes are not. (As for arrays, arrays
   really should be a class by their usage patterns etc. but for historic
   reasons... you know)

3. we have casting type hints in the rest of the code in the form of
   "(int)".
   Just to make it simpler and less confusing, of course. It's nothing like
   language having two features that look almost exactly the same but work in
   different way, and using plenty of ()s is an added bonus for all Lisp fans
   out there.

Some people don't like strict typehints, but the syntax as it currently
is regarding type hints is consistent. Now, to allow both strict and
casting hints, the logical step seems to be, to give the weak typehint
advocates their tool as well:
Calling something that works completely differently from all the established
patterns of PHP - like internal functions, etc. - "consistent" requires
totally new definition of this word.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--

Why do you think the two syntax's would be more complex!? IMO it is very
clear what each would do.

The "strict type hinting", foo(int $var), is the same as the current
"type hinting" for classes and arrays. It's required to be of that type,
plain and simple.

The "weak type hinting", foo((int) $var), is the same as casting any
other var, plain and simple. It will try to be casted to the specified
type, with an error if it can't.

I'm willing to bet that if you bring this to the end users they will
agree that it's easy to understand. Why try to figure out a new syntax
for something that already exists!?

Now, changing the current implementation to "weak type hinting" would be
more confusing. Because the current syntax used for type hinting
classes/arrays is strict. If changed, you would need to specify that
scaler types are weak but classnames are strict and now you have a WTH
moment.

Not sure how much my opinion matters here though because I'm just an end
user of PHP. IMO some of these debates should be brought to the end
users. Who uses PHP in the end? The users. (And yes, I know the devs
here do to..) What is one thing most companies go by? The customers come
first. This "we know best" attitude here is gone way to far. Please
don't just leave this here, because you'll hear it from the users in the
end anyway. A good community is one who communicates. Thanks

Hi!

Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current

No it is not. There's no functions that produce errors when fed 1
instead of boolean "true" - all internal functions convert.

typehints do not apply any kind of conversion, so treating scalar
hints the same way is consistent with the current mechanism.

Current hints do not apply conversion because conversion does not exist.
There can be no conversion between different classes.

Reusing the typecasting syntax for typecasting "hints" makes them more
familiar to the users, and it is less ambiguous than a typehint that
sometimes also typecasts. Plus, it allows for both "strict"

That's exactly how internal functions worked in PHP for 10 years -
"sometimes" (meaning when the type is wrong) typecast. That's how the
rest of the language worked for 10 years in situations like $a = $b+1.
How it's "ambiguous" - what are two options that you are confused
between and can't choose?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Yes, I understand the point of his post. But as you know - the perfect
world and the real world rearly meat together.
Just read the prevoius themes - majority was on the typecasting hints
for the primitive types. We even layed the rules quite in detail.
The thing is it will be pain in the ass to use strict typing just
because the data comes in string representation from almost everywhere
(PDO with mysqlnd makes a step to the right types from the database,
but that's more an exception than a rule for now). I just don't think
that there will be any sizeable codebase using the strict typing
because one way or other the authors will just get fedup with
converting data back and forth.
Not to mention it just breaks the logic of the language. As Stas just
wrote, people know from day one that if you feed "1" to a function
expecting int, it will work just fine. In fact, the whole language and
all internal functions work that way. The strict types will just break
that pattern. Most of times when using some API I don't give a damn
about what I get from the HTTP. I just do the blody $page =
isset($_GET['page']) ? (int)$_GET['page'] : 0; to get an int. If user
tries to do something by tampering with page params - he can do that
as long as he want's.
What that means, when strict typing is used, most of us will just do
the blody conversion, because we don't wan't to get a fatal error,
even if that's catchable.
Converting hint will give us a warning, convert the value and off we
go - log a warning, do the stuff so the user is happy. We see the
error in the logs, check it, apply a fix and done with it.

It's one thing if "12blabla" makes into 12 int (sure I want to get a
warning in the logs) or 1 becomes 1.0 for float (totally safe and
sound). It would be good to see say 5 convert to true for bool - it's
totally fine (again log an error/warning, this should be fixed).
And it's totally different when we expect an array or an object of
some type as a param. The handling of these structures just totally
differes. To work with them you use different syntax, different
aproaches. You can't substitute an array with something, same with
objects. They should fit perfectly.

It's not the reason to implement primitive type hinting like array and
object type hints just because arrays and objects are done that way.
Objects and arrays have a specific use syntax with special language
constructs. If I expect an array - it should be an array or I will get
a fatal error when trying to access an index for an int give, or try
to access a method for the wrong object. But you can easilly expect a
string and get an int instead, silently convert it to string and work
as expected.

Remember the main PHP principle? KISS. So keep it, blody hell, simple!
Let the type hints to cast types when it's possible for primitive
types! Personally I don't want to remember that there are two ways of
defining a type hint and dig for bugs when others ment strict type
hint, but wrote a typecasting one and forgot to make some checks
before passing the argument relying on the hint.

2010/8/11 Josh Davis phpwnd@gmail.com:

Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
typehints do not apply any kind of conversion, so treating scalar
hints the same way is consistent with the current mechanism.

Reusing the typecasting syntax for typecasting "hints" makes them more
familiar to the users, and it is less ambiguous than a typehint that
sometimes also typecasts. Plus, it allows for both "strict"
typechecking and the more relaxed typecasting thing instead of forcing
one. And all of that with a syntax that feels familiar.

That, I believe, was his point.

-JD

Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
typehints do not apply any kind of conversion, so treating scalar
hints the same way is consistent with the current mechanism.

It's only consistent in the function declarations but completely
inconsistent with how the rest of the language works.

+1. Strict typing will only prevent PHP from being itself, while not
providing the advantages of a real statically types language (as Stas
Malyshev has mentioned in another thread of discussion).

2010/8/11 Arvids Godjuks arvids.godjuks@gmail.com:

Completly agree with Zeev, most russian comunity is for the weak type
hinting. Many would like strict, but most of the pro strict type
hinters understand that PHP and strict type hinting not match and vote
for type hints with auto converting.

--

--
С уважением,
Виктор

Facts:

There are two facts that matter right now, imo:

• There is no 5.4 or whatever other version as of now.
• There is no RM either.

I don't know why nobody cares (well I do ;), but this is totally
insane. Do we ever learn? PHP6, the last 5.4 horrible episode, etc.
And as we clearly see today, we are not ready.

+1

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

That's not the issue on the table now.

We need to remove strict typing from trunk before we release anything
'official' from php.net, and the sooner the better. It's clearly not
something there's consensus over, almost the opposite.

We should discuss the merits of auto-converting type hints separately

• and if we decide not to have it that's fine. It has nothing to do
  with the fact there's almost consensus not to have strict typing in PHP.

Zeev

At 13:52 11/08/2010, Ilia Alshanetsky wrote:

I think that weak type-hinting defeats the whole purpose of the
feature and I would rather not have it than have a non-obvious
implementation.

-1

At 01:47 11/08/2010, Stas Malyshev wrote:

Hi!

For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.

I agree completely. The fact that obvious absence of consensus is ignored
and we are releasing feature that clearly has no consensus behind it as a
part of an official release - when we have killed much lesser things for
much lesser reasons - I think it is a very bad development.

I agree completely too.

We've also had quite a lengthy discussion on this topic, and there was more
support for 'weak' typing then there was for strict typing.

The response to Johannes's blog also don't leave much room for speculation
regarding what the community at large thinks.

Facts:

• When we introduced type hints, one of the 'conditions' were that we'll
  never, ever have type hints for scalars - for many different reasons - the
  strongest of which it simply doesn't fit PHP's theme.
• We managed to come up with an alternative solution, in the form of
  auto-converting type hints for scalars, which does in fact fit PHP's theme
  perfectly.
• I suggested we actually take the opportunity to slightly modify PHP's
  conversion rules in esoteric cases, where our historical decision is
  probably not the right one (e.g., silently converting "abc" into 0 in case
  of integer context - instead emit a new E_TYPE warning that would be off by
  default).

My view in terms of preferences:
#1 - Auto-converting type hints + minor changes to PHP's conversion rules
#2 - Auto-converting type hints
#3 - Doing nothing
#inf - Introducing strict typing into PHP (current trunk status)

As Stas said - there's clearly anything but consensus around strict typing,
so our 'default' in case we can't reach agreement is #3 - the status quo.
As everyone told me when this feature was committed to trunk - "it doesn't
mean anything, it's just trunk". Let's stand behind that statement and
revert it.

Strict typing should go away before any 'official' package comes out of
php.net.

Zeev

2010/8/11 Ilia Alshanetsky ilia@prohost.org:

I think that weak type-hinting defeats the whole purpose of the
feature and I would rather not have it than have a non-obvious
implementation.

-1

I would like to point out an argument, posted in the "Typehints (was
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)" thread by Jonathan
Bond-Caron, quoting:
"It's only consistent in the function declarations but completely
inconsistent with how the rest of the language works."

He took the words out of my mouth.

The auto-convert feature only touches the idea that 1 => "1", "1" => 1
conversions should take place automatically. In the case of "abcd" =>
0 we emit an error message. As it was mentioned in the RFC, the idea
is not only to make type hint's this way, but also to change the
language conversion rules acordingly to match the type hinting
auto-conversion rules. That way the conversion rules are made more
strict and type hints get some freedom instead of going into E_FATAL
everytime a developer misses string to int (and other similiar)
conversion in the code before passing data to objects/functions/API.
The conversions don't just go completly silent if inapropriate value
is passed to the function/method witch can't be converted
transparently to the required type. It gives you the error message and
it's your choise to ignore it or fix it. Strict type hintng will just
bring tons of code that does:
settype('integer', $total);
settype('integer', $per_page);
settype('integer', $page);
pager($page, $total, $per_page);

It will have to be written to make sure the variables have the right
type. Especially $page, witch usually comes via $_GET. Instead of just
checking for is_numeric now we have also to convert the type.

I just have an empression that you don't write much PHP code or you
work on very big and highly sophisticated projects, where the
situation is different. You leaving out the majority of PHP code
written for the middle and small scale projects, witch usually done by
far more simplier tools, sometimes even just using the plain old PHP
without a framework (and yes, sometimes it's just faster that way!).

I wouldn't mind living with neither but I think it's two separate discussions.

-----Original Message-----
From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Wednesday, August 11, 2010 3:52 AM
To: Zeev Suraski
Cc: Stas Malyshev; Johannes Schlüter; Kalle Sommer Nielsen; Internals;
Derick Rethans
Subject: Re: [PHP-DEV] Strict typing (was: Typehints)

I think that weak type-hinting defeats the whole purpose of the feature and I
would rather not have it than have a non-obvious implementation.

-1

At 01:47 11/08/2010, Stas Malyshev wrote:

Hi!

For the record: I consider the current implementation as (one of)
the biggest mistakes in the last ten years.

I agree completely. The fact that obvious absence of consensus is
ignored and we are releasing feature that clearly has no consensus
behind it as a part of an official release - when we have killed much
lesser things for much lesser reasons - I think it is a very bad development.

I agree completely too.

We've also had quite a lengthy discussion on this topic, and there was
more support for 'weak' typing then there was for strict typing.

The response to Johannes's blog also don't leave much room for
speculation regarding what the community at large thinks.

Facts:

• When we introduced type hints, one of the 'conditions' were that
  we'll never, ever have type hints for scalars - for many different
  reasons - the strongest of which it simply doesn't fit PHP's theme.
• We managed to come up with an alternative solution, in the form of
  auto-converting type hints for scalars, which does in fact fit PHP's
  theme perfectly.
• I suggested we actually take the opportunity to slightly modify
  PHP's conversion rules in esoteric cases, where our historical
  decision is probably not the right one (e.g., silently converting
  "abc" into 0 in case of integer context - instead emit a new E_TYPE
  warning that would be off by default).

My view in terms of preferences:
#1 - Auto-converting type hints + minor changes to PHP's conversion
rules
#2 - Auto-converting type hints
#3 - Doing nothing
#inf - Introducing strict typing into PHP (current trunk status)

As Stas said - there's clearly anything but consensus around strict
typing, so our 'default' in case we can't reach agreement is #3 - the status
quo.
 As everyone told me when this feature was committed to trunk - "it
doesn't mean anything, it's just trunk".  Let's stand behind that
statement and revert it.

Strict typing should go away before any 'official' package comes out
of php.net.

Zeev

--
To unsubscribe,
visit: http://www.php.net/unsub.php

--
To unsubscribe, visit:
http://www.php.net/unsub.php