What features do you want to see in PHP6

Ah no sorry I misunderstood. I thought McG was referring to throwing subclasses like you can in other languages. Well it’s fairly obvious the class needs to be derived from Exception otherwise it could have the wrong interface.

kyberfabrikken, you do know you can array cast a stdClass and object cast an array?

Yeah, but that’ll create a new object.

Then Exception should be an interface, and not a class. They shouldn’t have blindly copied Java, which has Exception class simply because it was introduced before interfaces.

Errr… then you would have to implement an exception (quite a few lines) before you could throw one.

c’mon … They could require the object to implement IException, but provide a default Exception, which implements the interface. Then people could use the default Exception for most cases, but be free to not do it.

Or they could do like javascript and simply allow you to throw anything, and then leave it for the catch block to deal with whatever arrived. If they kept the typehint in catch(), you would even have backward compatibility with PHP5.

Yeah, I guess I didn’t like the comment about blindly copying Java because I really don’t see anything wrong with Exception the way it is. The best way to improve it, if that really is necessary, is as you suggested kyberfabrikken.

That’s what I was getting at. Extending Exception means writing a new class. Even implementing an interface imposes a burden.

As long as I can just ignore it I’m happy. But how long will it be before a plain:


function foo() {
}

becomes an E_STRICT error…?

I should say a well-defined class interface is very important it’s just that I don’t believe it needs to be enforced.

The problem with visibility, at least as it’s implemented in Java, is that tries to govern two separate things, and does either job pretty badly.

On one hand, it defines which property may be accessed by which objects, and on the other it also defines which properties are inherited by subclasses. First of all, let me note that limitations on inheritance are nonsense, as they go against the basic “is a” principle of inheritance.

And second, I see any property as being either accessible only by the object it belongs to (private), or being accesible by any object, regardless of its descent or package. Even more, any attribute should be private and nothing but private – only methods could be made public, creating the object’s interface.

I find that visibility restrictions are somewhat useful if you don’t make too much fuss about them, but visibility in PHP is less useful than in Java since Java has package visibility.

Package visibility is an entirely different thing from property access. Thanks for reminding me, that’s a third thing Java’s trying to roll into a single feature.

Ironically the majority of features listed already exist in other languages…
Changing to PHP 6 will most likely break so much you may as well change languages too = )

Unicode
Namespaces
Multiple Inheritance (no I don’t want a flame war on interfaces can replace …)
Inner functions

That’s pretty much all I need

> perhaps made optional, but not removed.

At the moment it’s optional, and from what I can tell, class and property visibility will continue to remain an option to the developer; The great thing about PHP is that you can do the same thing a dozen different ways, and there isn’t anything to get in your way.

Much so visibility is much like that as well; I have not yet read anywhere that this feature is going to be made mandatory, for any version of PHP now or further down the road :slight_smile:

I agree with many statements mentioned here, but this one the most of all. Current standard library is too incosistent.

There’s a reason for this though. Yes, javascript lets you throw any type of object as an exception, but that’s mainly because there aren’t any classes or interfaces, so there’d be no other way to do it anyway. The downside of this is that, unlike php, you can only have a single catch statement; you can’t have multiple catch statements for different types of errors, which means you have to add if statements and instanceof operators, which is messy.

Besides, an exception is an object that represents an error message, nothing more, so it makes sense for it to be a subclass of Exception. Having it be an interface means you could write an object that is more than just an exception, which deviates from the intention of exceptions. This could be convenient, but it could lead to some very messy code, as it could be easily abused. If you find yourself needing to pass $this, you could simply add it as a property of your custom exception, so you could throw new MyExpection(‘an error’, 1, $this).

I understand the additional burden that extending a class or implementing an interface creates, but the concept of exceptions requires it, IMO.

As for new features, i’d like to see, my humble list would be.

  • Unicode support
  • A proper property mechanism
  • Non scalar constants
  • Shorthand for creating arrays: $arr = [1, 2, 3]
  • Namespaces (but I’m not holding my breath for anything genuinely useful)
  • Moving the built-in functions into individual namespaces and cleaning up naming

I could go on, but I’m more likely to move to another language than see things like blocks and open classes.

Or, if the fatal error was turned off in catch(), hints could allow catchers to choose whether to accept a thrown object. I’ve no idea if the php internals would make that problematic to do.

Besides, an exception is an object that represents an error message, nothing more

That’s exactly why I don’t like the implementation. Why create an object just to pass a string around? OK there’s some extra information in there as well as the error string but what I really want to do is interrogate the failing object directly rather than pull stuff out, wrap it up in an exception class, and then drag it all out again in the catcher - cuts out the middle man.

FWIW: Give me namespaces, add unicode, add an opcode cache, add sandboxing and whitelisting and remove any of the new PHP5 E_* idioms (such as E_STRICT).

Why create an object just to pass a string around? OK there’s some extra information in there as well as the error string but what I really want to do is interrogate the failing object directly rather than pull stuff out, wrap it up in an exception class, and then drag it all out again in the catcher - cuts out the middle man.

I think there is a reason that it is called “throwing an exception” and not “throwing the offending object”. Objects represent state and an exception is a contextual state-transfer. Throwing any old object is … well, it is a strange sort of “casted goto” and I suspect that people who want it might want to use exception handling to deal with standard program logic rather than exceptional concerns. Anyways, the offending condition may not arise from an object itself.

Further, an exception object is not merely a string representation – it is an abstracted way to manage errors. Now lets consider a real problem. Say you have a consistency check that occur in various types of objects, not all derived from the same object. You want your error handling to deal uniformly across all objects for that sort of incident. Do you re-implement that handling in each base class? I think not. You abstract it as a general exception type (ECrossCuttingConcernX) and you throw that from each of the objects. As a bonus, you can decorate that exception type, change the base class definition or even inject behaviors as required. You can’t do that with a string and it becomes messy quickly without a standardized and abstracted mechanism (ie. the exception class).

Well, that’s the way I see it anyways.

Personally, next to Unicode support, overloading is certainly a must-have.