Do You Think That PHP Would Benefit from Static Typing?

[Jake Arkinstall]

PHP is currently dynamically-typed. You can set a variable as one thing and it can be changed to something else and go through operations suited for other variable types (i.e. adding 5 to "3" = 8).

So, do you think PHP would be better with static typing? This is where you declare variables first.

I'm talking of something like:

<?php
String $var = "hello";
Int $num = Integer.parseInt($_GET['number']);
Var $something; //can equal anything.
?>

[croatiankid]

Is there any benefit to dynamic typing other than that it could help you spot errors early on?

[Jake Arkinstall]

Sure: Security, stability, speed.

For PHP to process a variable I beleive it's all stored in string format, until a specialised need arrises (math, for example). This means that 5 and "5" are the same with ==, because the number is converted to a string (not the other way round). This requires processing - meaning it is slower than it needs to be.

On top of this, I would like to state what I want in a function, i.e:

<?php
function output(String $var) //....

Or, even better, type the function too:

<?php
void output(String $var) //...
String escape(String $unescape) //...

[sweatje]

There are already statically typed languages available, why not choose that rather than modify a dynamically typed one?

[Czaries]

<?php
String $var = "hello";
Int $num = Integer.parseInt($_GET['number']);
Var $something; //can equal anything.
?>

That looks way too much like Java. PHP is dynamically typed for a reason, and I've come to appreciate certain aspects of it's dynamically-typed nature. If anything, PHP should go more towards a full OO language by automatically creating the necessary objects by declared value type implicitly, like Ruby and Python do - something like this:

<?php
$var = "hello"; // automatic string object
$num = 1234; // automatic integer object
$regex = "/(.*)/i"; // automatic regex object
?>

And then all the PHP functions would have to be modified to accept the new base object type as well, like:

<?php
$sub = substr($var, 0, 2); // equals "he"

// Also new syntax is provided for the new object types
$sub = $var->substr(0, 2); // equals "he"
?>

So at least to me, that would be the perfect way to take PHP to the OO-level for those who want it, and keep it looking like flat dynamic variables for those who don't.

[Jake Arkinstall]

^ I agree

Yeah, it is very Java - a language I've grown to like alot however it isn't as suitable for the web as PHP.

[chestertondevelopment]

The only thing I'd like that's related to static typing is the ability to declare what a method should return in an interface. At the moment we can enforce what is passed to a method but if we could enforce what it should return it would make interfaces much more usable and strict. I don't know about syntax and I think there was talk about this on internals at some point but something like the following would be good:

interface Foo {
    public ReturnObject function bar(PassedObject $obj);
    public DifferentReturnObject function baz();
} 

[kyberfabrikken]

Bolting a static type-system on top of a dynamically typed language seems like a bad idea to me. If anything, I think that PHP has already venture too much in that direction. Statically declared interfaces just seems a bit alien to the rest of the PHP language. Something like this proposal would have been more natural.

[chestertondevelopment]

Bolting a static type-system on top of a dynamically typed language seems like a bad idea to me. If anything, I think that PHP has already venture too much in that direction. Statically declared interfaces just seems a bit alien to the rest of the PHP language. Something like this proposal would have been more natural.

Interfaces in general could be seen as quite alien compared to the rest of the PHP language. I'm definitely not for the proposal put forward by arkinstall, if you want Java, use Java. It seems a natural progression to enforcing classes in a parameter and as interfaces are meant to enforce a particular way of working and I just think this would help.

I really don't like that proposal tbh, it's not very obvious what is happening but I do prefer the syntax. For PHP something like the following would perhaps be better then.

interface Foo {
    public function bar($baz): ReturnObject;
} 

It's all just an opinion obviously but it's something I'd like. I don't think it makes it too Java-y as long as it stays in interfaces and we can't start declaring what a class method should return. Like I said it feels like a natural progression in interfaces.

[Czaries]

I really don't like that proposal tbh, it's not very obvious what is happening but I do prefer the syntax. For PHP something like the following would perhaps be better then.

interface Foo {
    public function bar($baz): ReturnObject;
} 

Wow... When I read your first post I immediately pictured the exact same syntax you just wrote above for PHP instead, where the expected return object comes after the function declaration (or prototype) instead of before it like other languages. Hey, you know what they say about great minds...

Also, I don't really agree with the linked proposal either. The syntax just doesn't look right for PHP - there's something about it, I'm not sure.

[kyberfabrikken]

Also, I don't really agree with the linked proposal either. The syntax just doesn't look right for PHP - there's something about it, I'm not sure.

It think you missed my point - both of you (Which then suggests that I wasn't being clear enough). I weren't suggesting to use that particular syntax. It's the idea that you don't explicitly declare a class to implement an interface, but rather let the interpreter compare the signature in runtime. So, in a PHP-ish syntax, it might look like this:

interface Fooable {
  function foo($number);
}

class MyClassWhichExpectsAFooable {
  function doStuff(Fooable $fooable) {
    $fooable->foo(42);
  }
}

class SomeFoo {
  function foo($number) {
    echo "foo: " . $number;
  }
} 

Note that even though SomeFoo doesn't explicitly implement Fooable, it satisfies the signature, and thus would pass into doStuff.

[datune]

It think you missed my point - both of you (Which then suggests that I wasn't being clear enough). I weren't suggesting to use that particular syntax. It's the idea that you don't explicitly declare a class to implement an interface, but rather let the interpreter compare the signature in runtime. So, in a PHP-ish syntax, it might look like this:

interface Fooable {
  function foo($number);
}
 
class MyClassWhichExpectsAFooable {
  function doStuff(Fooable $fooable) {
    $fooable->foo(42);
  }
}
 
class SomeFoo {
  function foo($number) {
    echo "foo: " . $number;
  }
} 

Note that even though SomeFoo doesn't explicitly implement Fooable, it satisfies the signature, and thus would pass into doStuff.

Hmm... I wonder then how the interpreter should handle the following:

interface Fooable {
  function foo($number);
}
interface Barable {
  function foo($number);
}
 
class MyClassWhichExpectsAFooable {
  function doStuff(Fooable $fooable) {
    $fooable->foo(42);
  }
}
class MyClassWhichExpectsABarable {
  function doStuff(Barable $barable) {
    $barable->foo(42);
  }
}
 
class SomeFoo {
  function foo($number) {
    echo "foo: " . $number;
  }
} 

See what I mean?

[chestertondevelopment]

It think you missed my point - both of you (Which then suggests that I wasn't being clear enough). I weren't suggesting to use that particular syntax. It's the idea that you don't explicitly declare a class to implement an interface, but rather let the interpreter compare the signature in runtime. So, in a PHP-ish syntax, it might look like this:

interface Fooable {
  function foo($number);
}

class MyClassWhichExpectsAFooable {
  function doStuff(Fooable $fooable) {
    $fooable->foo(42);
  }
}

class SomeFoo {
  function foo($number) {
    echo "foo: " . $number;
  }
} 

Note that even though SomeFoo doesn't explicitly implement Fooable, it satisfies the signature, and thus would pass into doStuff.

It's an interesting idea definitely, wonder how much load this would put on the interpreter though. I don't see how that affects whether the static-typing on return values in interfaces is a good idea, perhaps I'm missing something? Sorry if I'm being dumb

[CoderMaya]

Yeah first of all TypeHinting does exist in PHP and it doesn't let you get anything else than what you ask for in the function decleration.

What I would like the most about PHP is not only automatic object creation like

$str = "asdasd" // Automatically creates string object 

But I would also like to overload those automatic creations. For instance, I'd like to decide what kind of object is created when a string is typed.
This will give much more power to PHP as a framework-potential language. You could actually make PHP to be what ever you want.

Also I would like to get rid of the annoying -> operator in objects. Why the hell type two letters to get into and object, when one of them mostly requires the use of shift.

And I never like "this" either. I really liked what Ruby offers. Simply @var to access vars inside the current object, and we could have $ for local vars.

Why not "." like in most languages (they do it for a reason!). So what if it's compiled in C (or C++), if you have the power to create a new dynamic language, why not make it better than old languages instead of sticking to weird roots.

Why not replace the .= operator with simply += (since we'll be having automatic string object creation it's gonna be obvious that we want to add something to a string, like - a string!)

And also it could be a nice idea to add properties instead of creating a damn method for simply retrieving one member variable after a simple calculation.

And also it could be a good idea to remove the "function" keyword from class methods. Who needs it there? We can do just fine without it.

My offer:

class Employee
{
protected $name = 'John Smith';
protected $monthlySalary = 5000;
public yearlyWage
{
get { return @monthlySalary * 12}
set { @monthlySalary = $value / 12 }
}

public sayName()
{
echo @name;
}
}

$emp = new Employee;

echo $emp.yearlyWage;

$emp.sayName(); 

And oh-my-god. I just despise the :: operator. It's not like in C++ anyway where variables don't have the $ prefix. When we reach for a static class name and not an object there's no way we'll be accessing something else except THAT class. There's no mistaking it for an object, because an object has to have a $ prefix.

So why, oh why, have double colons to access static members. Not to mention the new namespaces feature in PHP 5.3 that doesn't even support something such as "using" to shorten the call for certain classes.

So I really can't see myself going like this in a framework I'd build:

$var = new Framework::Category::SubCategory::Class();

everytime I want to create an instance of Class.

Oh an another thing I would really enjoy is the option to create different extension files for PHP files that don't contain HTML or such.

So that I wouldn't have to start every class file with <?php like some script kiddie.

PHP is going the wrong way instead of the right one.

I do not expect to make any use of the namespacing feature in PHP 5.3. It's ridiculous.

And PHP has so much potential.

[CoderMaya]

It's an interesting idea definitely, wonder how much load this would put on the interpreter though. I don't see how that affects whether the static-typing on return values in interfaces is a good idea, perhaps I'm missing something? Sorry if I'm being dumb

And I actually don't get your point.

The interpreter doesn't look only for variable names in classes that implement interfaces. It looks for the signature of that interface. It KNOWS which interfaces your classes implement. It doesn't "guess" it by the variable name.

Or maybe I missed your point.

[chestertondevelopment]

I meant kyberfabrikken signatures idea. Every time it checked it would have to check whether the class conformed to that signature.

And oh-my-god. I just despise the :: operator. It's not like in C++ anyway where variables don't have the $ prefix. When we reach for a static class name and not an object there's no way we'll be accessing something else except THAT class. There's no mistaking it for an object, because an object has to have a $ prefix.

Not true. You could theoretically have a constant as an object, e.g.

define('MyObject', new MyObject);
MyObject->method(); 

At the moment it would call the method dynamically. But if say we had it so that static method calls used '->', it could refer to either the static call or the call against the constant. You see? Also having ::, for me, makes it more obvious when something is called statically.

Why not "." like in most languages (they do it for a reason!)

Because it's used for string concatenation. So $class.method(), that would concatenate the class variable and whatever the function called 'method' returned, there would be no way to tell.

Why not replace the .= operator with simply += (since we'll be having automatic string object creation it's gonna be obvious that we want to add something to a string, like - a string!)

That's the whole point of a dynamically-typed language. Say you had two strings, '3' and '5'. Now they're strings because you got them from a form and haven't type casted them yet, you want to add them together to get 8 so you use +=, but if we had it your way then it would create 35, which would be wrong. += allows you to dynamically cast the strings to integers because that is what it is expecting. Even if it would be a good idea, which I don't think it is, it would be such a fundamental change to the language that it would break existing sites.

[CoderMaya]

Nice but you're ignoring what I'm offering.

I'm offering that any object can always be put into a $variable.

so if we did for example

$string = "1";

$stringTwo = "2";

and wanted to add them we would do

$result = $string.int() + stringTwo.int() // $result would get an Integer object.

And taht would automatically obviously allow the use of "." for accessing members.

the "." operator sucks anyway because it's so bad performance wise.

Did you know that when you do this

$string = "str";
$string .= "str";
$string .= "str";
$string .= "str"; 

You're actually filling --4-- new 16byte memory cells. That's 48 bytes - purely - wasted.
Yes. Garbage collection doesn't happen immediately and when using the "." operator you're basically shitting yourself, because you're unreferencing and creating new strings every time.

And by the way. You can not make a constant an object. That goes against the concept of a constant.

Don't take my word for it, though. Try it.

[chestertondevelopment]

And by the way. You can not make a constant an object. That goes against the concept of a constant.

My mistake, could have swore I saw someone doing that once.

the "." operator sucks anyway because it's so bad performance wise.

It may suck, but by changing to += I don't see how it helps performance.

That's 48 bytes - purely - wasted.

48 whole bytes! I'm all for optimization but I doubt that will matter too much and they're ways around that.

What you are basically describing, again, is Java, with type-casting etc. PHP is a dynamic language and if you want Java, then use Java.

$result = $string.int() + stringTwo.int() // $result would get an Integer object.

Why? When the following works fine?

$result = $string + $stringTwo; 

Anyway this is going completely off topic and the syntax is so drastic it would never happen as it would break every PHP script on the net.

[CoderMaya]

My mistake, could have swore I saw someone doing that once.

It may suck, but by changing to += I don't see how it helps performance.

48 whole bytes! I'm all for optimization but I doubt that will matter too much and they're ways around that.

What you are basically describing, again, is Java, with type-casting etc. PHP is a dynamic language and if you want Java, then use Java.Why? When the following works fine?

$result = $string + $stringTwo; 

Anyway this is going completely off topic and the syntax is so drastic it would never happen as it would break every PHP script on the net.

But at least it would give us access to use "." for accessing members, right?

And we're not describing Java. Come on. Incorporating some concepts that Java (for good reasons) incorporated into its language might be a good idea. It does not mean we're gonna start using Swing controls or strongly typed variables.

All I'm asking for is an improvement. The actual changes I'm asking for are simply because there's no good reason not to have them.

[chestertondevelopment]

But at least it would give us access to use "." for accessing members, right?

Sure. Personally I don't mind -> and from an aesthetic point of view I think $class->method(), looks better than $class.method(); but that's a completely personal preference. I can't remember what language it is (perl?) but -> is not unique to just PHP.

The actual changes I'm asking for are simply because there's no good reason not to have them.

I'd argue simplicity and keeping the low barrier to entry that makes PHP so popular (whether for good or bad) are reasons and just because there's no good reason not to have them, it doesn't mean there is any good reason too have them.

And we're not describing Java

True, but it's going down that route and personally I believe PHP is close to going down that route too much as it is. Sure, PHP can learn some things from Java, every language can, but from my point of view it's close to taking PHP from a dynamic language to a static language.

[kyberfabrikken]

I don't see how that affects whether the static-typing on return values in interfaces is a good idea, perhaps I'm missing something? Sorry if I'm being dumb

Not at all. I didn't bring it up as a comment on return types. It was merely meant as a comment on the current state of PHP's class system.

Whether return types are a good idea? I'm not sure, to be frank. I believe that typehints on input parameter may be fundamentally different than typehints on return values. Input types can be used to ensure that input is sane, which is a common and useful practise. Return types don't add any extra safety as far as I can see. They are purely documentation; Unless you also add strong typing, and that would be a major change to the language.

Hmm... I wonder then how the interpreter should handle the following:
...
See what I mean?

No conflict there. An instance of SomeFoo is both a Fooable and a Barable.

I meant kyberfabrikken signatures idea. Every time it checked it would have to check whether the class conformed to that signature.

I don't think performance would be a problem. The interpreter could cache the lookup per class/interface. Since they are statically defined, they won't change during runtime.

[Czaries]

All I'm asking for is an improvement. The actual changes I'm asking for are simply because there's no good reason not to have them.

Actually, the changes you're asking for are very drastic and would affect every single script ever made with PHP since they would change the core syntax to something else. Your changes are way too drastic, and will never happen. That's the single BEST reason to not have them (and the only one needed).

The guys on the internal mailing lists have a strong mindset for what is and what is not the "php way". Any suggestion they feel is not the "php way" will get promptly rejected, and changing the core syntax would most definitely fall in that category, as would any Java-like syntax like "$result = $string.int() + stringTwo.int()" when a simple "$result = $string + $stringTwo" will do the same thing and works great already.

There are always going to be things you personally like and dislike about any language. There is a point where you have to realize what is feasible and at least somewhat likely to be considered, and what is just flat out asking PHP to be more like some other language you happen to like better. Please keep it realistic!

[chestertondevelopment]

I don't think performance would be a problem. The interpreter could cache the lookup per class/interface. Since they are statically defined, they won't change during runtime.

Yeah I thought that after I said it, it could just cache whether it satisfies the interface after the first time. It could even help performance as it would not have to parse the interface/signature until it is needed whereas currently it would have to parse the interface initially to check the class conforms. Especially in frameworks such as ZF where interfaces are usually a separate file.

Not at all. I didn't bring it up as a comment on return types. It was merely meant as a comment on the current state of PHP's class system.

Ah.. sorry about that, I was being dumb then

Whether return types are a good idea? I'm not sure, to be frank. I believe that typehints on input parameter may be fundamentally different than typehints on return values. Input types can be used to ensure that input is sane, which is a common and useful practise. Return types don't add any extra safety as far as I can see. They are purely documentation; Unless you also add strong typing, and that would be a major change to the language.

I suppose it's the difference between:

$foo = $bar->baz();
if ($foo instanceof MyClass) {
    $foo->doSomething();
} else {
    throw new Exception('Return value must be instance of MyClass');
} 

And knowing that $foo is an instance of MyClass because the interface ensures so, so we would have.

$foo = $bar->baz();
$foo->doSomething(); 

More concise, and it's also obvious from looking at the interface declaration that it should return an instance of MyClass, thus helping code readability and makes the interface more self-documenting.

[CoderMaya]

Actually, the changes you're asking for are very drastic and would affect every single script ever made with PHP since they would change the core syntax to something else. Your changes are way too drastic, and will never happen. That's the single BEST reason to not have them (and the only one needed).

The guys on the internal mailing lists have a strong mindset for what is and what is not the "php way". Any suggestion they feel is not the "php way" will get promptly rejected, and changing the core syntax would most definitely fall in that category, as would any Java-like syntax like "$result = $string.int() + stringTwo.int()" when a simple "$result = $string + $stringTwo" will do the same thing and works great already.

There are always going to be things you personally like and dislike about any language. There is a point where you have to realize what is feasible and at least somewhat likely to be considered, and what is just flat out asking PHP to be more like some other language you happen to like better. Please keep it realistic!

Yes, well, that's a really good point.

I think ultimately what I was talking about is a fabulous modification of PHP into another language. Since obviously PHP is meant as a simple web-designer language, with extra stuff for professional developers.

What bothers me, though, is that PHP has so much potential next to other languages, and it can be so much better for actually much simpler use (considering we have a thousand people willing to create revolutionary frameworks with its great flexibility - which I'm offering to expand even further).

As a guy who likes to develop neat frameworks and deal with objects pretty much in 99.9% of my code, I hate the -> operator. I always accidently type _> or -. and it.. irritates me.
Maybe it's an idea to map some key to type "->" hehe.
Also, dealing with objects all the time, I can't ignore all the possibilities that would make this fantastic dynamically-typed language even more suitable for object oriented designs.

So what I would like to see is an offical mod for PHP for extra demanding developers.

Of course that would never happen.

But dreaming is fun, ain't it?

[Czaries]

I think ultimately what I was talking about is a fabulous modification of PHP into another language.

Well honestly, PHP actually has made a few baby steps in the direction you want. If you look at the new php5 syntax for merging to arrays together, it looks like this:

$newArray = array('foo', 'bar') + array('baz', 'xyz'); 

Which I found quite odd considering the concatenation character for PHP is the dot (.), making the syntax different for concatenating array variable types different than others. So, PHP might have the capability to do something like this in the future after all, where you could use either the dot (.) or the plus(+) sign for concatenation. It's at least something to look forward to .

As a guy who likes to develop neat frameworks and deal with objects pretty much in 99.9% of my code, I hate the -> operator. I always accidently type _> or -. and it.. irritates me.

Same here... I have never liked it, and myself would much prefer the dot (.) operator for working with classes as well, but it's something I've learned to live with about PHP.

Also, dealing with objects all the time, I can't ignore all the possibilities that would make this fantastic dynamically-typed language even more suitable for object oriented designs.

Definitely don't ignore the possibilities of what PHP could be - that's not what I'm saying at all. I'm just saying that when do you suggest the new features or functionality, suggest it in such a way that it could be more seriously considered in future releases (not breaking backwards compatibility, not changing the syntax too much, etc). I think you get the point .