Optional scalar type hinting

I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?

The other thing to note about type hinting is that it could result in faster code.
The value is checked and if needed converted (eg string -> integer) when the
function is called; it then need not be converted again when it is used in
the function. This will presumably be a win if the value is used more than once.

--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h

Yes it seems PHP will omit E_WARNING if you omit an argument.

(Had to actually check.)

Not a bad choice for an error and probably also easier to manage when you are
dealing with complicated error handling in large applications.

I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the
simple fact that they are ignore by a major portion of PHP developers and to
use them would prompt a high risk of people writing bad code.

Also, now that you mentioned abstract classes, type hinting might also be
useful with interfaces.

Tomi Kaistila
PHP Developer

On Thursday 03 January 2008 19:21:21 you wrote:

I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?

And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a parent class that must
return a certain type.

class a {
abstract public function getNumber() returns int ;
}
class b extends a {
public function getNumber() {
return rand() * 3463 ;
}
}
class c extends a {
public function getNumber() {
return 'I'm going to mess everything up by returning a string.' ; //
Would cause error with type hinting.
}
}

Hello everyone

I figured I would bring my opinion in to support of Sam's request for a
more complete type hinting feature. Namely I am interested in the support
for hinting scalar types on function and method arguments and I am sure
it is safe for me to say that I speak for a lot of people. Most people
that I know find the current type hinting, while useful, ridiculous
because it looks like the job was left unfinished for whatever abstract
reason.

In my opinion type hinting should definitely be allowed for scalar
values. As for return types, I am not so sure. So far I have found no use
for such a feature in my own code, so I won't comment on it. If it is
added, I welcome it for those who find it useful but if it is not added I
will not loose sleep over it.

I was thinking at something along the lines of objects also for
instance: $i = new Integer(33);

After my own experiments with the subject I concur that while it can be
made to work, it is not only a bad idea (for the reasons mentioned
earlier) it is also redundant and just unnecessary. There is a lot better
way to accomplish the same and that by allowing scalar values to be
hinted. It is simpler, cleaner, and easier to implement.

What if type hinting just generated an E_NOTICE. Nothing more for the
time being.

Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since
if I write a piece of code that hints that the argument for a-whatever
method needs to be an integer it seems useless if the user of my library
can avoid the issue just by supressing lesser errors and those who do not
need to write extensive error handling code to respond to this sort of
error (if they indeed deem it necessary to do so).

While hinting is, and should remain, optional, when it is used it should
be enforced. After all the user of my library has the option to dump it
and go for another library that does not force types. That is the beauty
of having options.

Tomi Kaistila
PHP Developer

It really doesn't fit in very well with PHP's loosely typed nature which
is one of the main reasons it has been so easy to use.
I think this is one of the cornerstones that two sides disagree the most on.
People are afraid that PHP would turn into a strong-typed language by
allowing type hinting for scalar values. I do not think this would be the
case. You would still have all the freedom that you have no with PHP, since
PHP's type juggling is still in effect.

The only thing that would change is that the validation of the data that is
passed into functions would be somewhat automated, but since the validation
occurs with or without type hinting the result is still the same. If data is
incorrent, an error occurs whether it is an exception, a false return type,
or a triggered error. The behaviour of the program does not change with type
hinting.

Even this thread shows that there's no alignment between people on what
it should actually do.
This is true, but contributed to it is that so far we have spent more time and
energy on the silly debate whether or not type hinting is a useful feature.
There is enough technical proof to suggest that it is in fact a useful
feature.

What I would like to see is actual discussion on how it should behave and see
if a concensus can be derived.

Saying that it won't confuse newbies is also wrong. PHP is so popular
because it's so easy for people to pick up. Part of this also includes
ability to look at other people's code, understand it, copy-on-write
(e.g. a Wordpress plug-in).
This is an argument that I honestly do not understand. Type hinting is already
here. It exists in PHP. How can the concept be abandoned on the bases that it
would confuse new users, if the concept has already been approved and
implemented?

Tomi Kaistila
PHP Developer

We've discussed scalar type hinting many times in the past and decided
against it.
It really doesn't fit in very well with PHP's loosely typed nature which
is one of the main reasons it has been so easy to use. The only reason
why it works with classes and arrays is because those are unambiguous
constructs.

It doesn't fit. This is not a technical argument, this is your opinion
on the way PHP should be. That's the problem here.

Even this thread shows that there's no alignment between people on what
it should actually do. This is due to the lose nature of PHP. For
example, HTTP vars come in as strings. So if you have
http://localhost/?n=1 in your URL there are some in this thread which
would expect it to be successfully juggled by an "int" type hint even
though it actually comes in as a string; and some who want it to be
ultra-strict and if the PHP type isn't an integer it should emit an
error. What happens when you pass an object with a __toString() method
to a function expecting a "string"? I think it should work and convert.
I am sure some here disagree. This is exactly the problem!

We keep saying that scalar type hinting is not intended to be used for
input. Even so, if you really wanted to you could run your input through
a very simple function and convert each variable into the appropriate
type.

function typeConvert($variable) {
if (is_array($variable)) {
foreach ($variable as $k => $v) {
$variable[$k] = typeConvert($v) ;
}
}
else if (is_object($variable)) {
foreach ($variable as $k => $v) {
$variable -> $k = typeConvert($v) ;
}
}
else {
if (is_numeric($variable) and substr($variable, 0, 1) !== '0') {
if (substr_count($variable, '.')) {
$variable = (float) $variable ;
}
else {
$variable = (int) $variable ;
}
}
}

return $variable ;

}

Saying that it won't confuse newbies is also wrong. PHP is so popular
because it's so easy for people to pick up. Part of this also includes
ability to look at other people's code, understand it, copy-on-write
(e.g. a Wordpress plug-in). The more features in PHP the harder it'll be
for developers to deal with. Yes, we bit the bullet for namespaces
because there were strong reasons in favor of it, we as a community had
it on our wishlist for a long time and a lot of work went into it. And
even when we did it we had to find a way to make it work for PHP. In
this case, with the lose typing of PHP creating a consistent model which
will be apparent to people without many questions is a big issue.

I've said this numerous times too. How hard is it to understand? If
someone can't understand this simple concept they are sure as hell not
going to understand object oriented or anything.

Plus the fact that this is actually easier to understand than
array/object type hints.

Also, for those who say that when this feature is not used it doesn't
have a performance impact that is also a problematic statement. If it
exists people will use it. Most people using PHP don't understand (and
shouldn't have to understand) how the language is implemented. It may
very well be that even if we could agree on the semantics we'll see all
sorts of developers "decorate" their code with type hints (because they
think it'll help readability) who may down the road find themselves in a
surprise when it comes to performance.

Well that's their decision. I could use functions and not use a single
class in my applications, and they would be faster. I sacrifice a little
performance in order to make my code better.

Last, just because something can be implemented and a patch exists
doesn't mean it should be in PHP. There are lots of things I can
implement for PHP which shouldn't be in PHP. Also don't under estimate
what happens when you get bloatware and over time how much harder it
becomes to maintain and also how it does eventually end up slowing
things down (over time there are more branches, more code a.k.a more
cache misses, etc...)

You are right here. But define bloatware. Type hinting is already in
PHP. All I want to do is add a couple of types to this already
implemented feature. My patch is pretty small.

We have what I think is a very exciting PHP version coming up with 5.3.
The featureset has been agreed upon. It'd be great if all the
contributing energy in this thread could be channeled towards playing
around with 5.3 esp. the new i18n extension, namespaces, help with
migration/incompatibility notes and garbage collector benchmarks. We are
now at the stage where we really need the code base to mature with
feedback from users. The more you can invest in that the better.

Good point, namespaces need to be tested and brought to a production
state, and i18n looks pretty interesting.

Ouch, sorry for the long email! :'(

Andi

P.S.- The runtime piece of this patch also looks wrong. I didn't dive
deep but those if() statements don't look too friendly.

It's worked for me fine for a couple of months. The if statements in
zend_compile.c are pretty confusing (as far as the brace indentation
goes).

I just like PHP enough that rather than switch languages, I would like
to attempt to make PHP better. I've only been working with the PHP
source since November and I'm 19

Right, that'd explain it. It's just that usually people do a bit of PHP
development (websites, applications, whatever) or throw out a couple of
classes, or something that Google can find anyways, before they start
telling the core PHP dev team they're doing it all wrong.

Time out. I didn't say anyone was "doing it all wrong". And I've been
developing in PHP for about 4 years. I am Zend certified and I have a
full time job developing in PHP with people twice my age and years of
experience. Not at all bragging, but I am far from the beginner who's
speaking what he doesn't know. Just because my code isn't on google
doesn't mean I haven't done any. If you want to see some stuff I've done
just let me know I will gladly send it to you.

Plus the fact that I'm obviously not stupid and I have some idea what
I'm doing if I am writing patches for the PHP core with no prior
experience.

so I haven't been around for many prior

contributions to PHP; that's probably why you haven't heard of me. I
started messing with the source and about a week later I had the type
hinting and superglobal patches done, and I joined internals.

No, you subscribed to the internals mailing list.

Ok, wording mistake.

I completely understand the disadvantages to multiple inheritance so
I've kind of dropped that, I support custom superglobals but I can
understand why they are unwanted, but scalar type hinting I think should
be in PHP. I have written all 3 of these patches but this is the one I'm
pushing for mostly. I'm using the superglobal patch for my own
development, and I have multiple inheritance working, but I don't want
to have to rewrite the patch every time php changes.

So far, fair enough.

And these reasons you're talking about that Stas brought up, I don't see
any reasons besides the fact that it may confuse newcomers and it's too
"javaish".

'It may confuse newcomers' is a big issue in PHP. Ease of takeup is the
mainspring of the language's design. The other point Stas made that you
appear to have missed is that loose typing is very much a PHP feature. It's
one of the things that helps make the language easy for newcomers, and it
also means the language is more forgiving than others. OO is a different
matter because you get different types of objects. You don't get different
types of strings, integers or floats, or at least, not to the same degree.
People using PHP shouldn't have to know about those differences unless they
really need to.

Ok then. This is understood, that's why newcomers shouldn't use type
hinting. Are you saying we should hold back new features because they
might confuse beginners?

I used PHP for quite a while before using any object oriented stuff.
When I was ready, I started doing object oriented programming.

Also, I didn't say we should throw away loose typing. This is not at all
strict typing. This is optionally type hinting specified function
arguments. There is a big difference.

Performance is not an issue here, especially for those who

don't use type hinting. For those who don't want to use it they don't
have to because it's optional.

It's optional, sure, but it's one more thing that every newbie will need to
be aware of before s/he can call himself a PHP developer. Every one of those
optional features that is added to the language is another barrier against
takeup.

How complicated is it? Is it any worse than array type hinting? Should
we sacrifice functionality in order to make it as easy as possible to
master PHP?

Programming is hard. If you have enough intelligence to call yourself a
PHP Developer then you can surely understand the difference between an
integer and a string.

Any other arguments can be countered by the fact that if type hinting is
not proper in the situation, don't use it. If you want to, then use it.
Everybody wins. Plus the majority on here seems to agree with me.

Type hinting is already in PHP. It's been in PHP. Why not add a couple
of useful types? I don't see any debate here.
You, a handful of list lurkers, Jochem hanging in there for his
one-man-crusade (he wants to formalize PHP core development so much that
nobody will do it for pleasure ever again), Derick inexplicably backing you.
Nobody else even bothering to argue because Stas seems to be doing the job
fairly well all by himself right now. Johannes quite rightly won't introduce
type hinting for scalars without a mandate, and there doesn't appear to be
one right now. If it is accepted it'll most likely be in PHP 6 not 5.3
anyway, because 5.3's features were agreed (and limited) a couple of months
ago.

Ok, if you say so. But I see many PHP developers/users pushing for type
hinting. Even if I was a naive list lurking PHP beginner who has only
written a couple of classes, I am not necessarily wrong because of it.

I just like PHP enough that rather than switch languages, I would like
to attempt to make PHP better. I've only been working with the PHP
source since November and I'm 19

Right, that'd explain it. It's just that usually people do a bit of PHP
development (websites, applications, whatever) or throw out a couple of
classes, or something that Google can find anyways, before they start
telling the core PHP dev team they're doing it all wrong.

I do have one site live - www.ubuntuhcl.org. I made this quite a while
ago, not the best coding methods because this was when I had much less
experience but a fully functional site I made form scratch.