What features do you want to see in PHP6

[dagfinn]

@BerislavLopac

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.

I’m not sure I understand what you mean. Terms like private, public and protected seem to have a well-defined, albeit somewhat general meaning. Final, on the other hand, is ambiguous.

[michel]

@jayboots

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 said. Nevertheless wouldn’t it be convenient if you could pass a string if you’re not using custom exceptions? Maybe an Exception instance could be created internally and have the string assigned as its message.

throw 'Message'

instead of

throw new Exception('Message')

[jayboots]

@michel

…wouldn’t it be convenient if you could pass a string if you’re not using custom exceptions? Maybe an Exception instance could be created internally and have the string assigned as its message.

throw 'Message'

instead of

throw new Exception('Message')

Hmm. Well, it is not at all clear to me why you would want to do the former. Maybe your intention is to simply log some condition’s outcome? Besides, I don’t see how much more convenient it really is – the latter is just 15 more characters to type (less with a good IDE) and gives the handler much more information to work with.

I guess this is getting OT, so I’ll wrap it there. Cheers.

[BerislavLopac]

@dagfinn

I’m not sure I understand what you mean. Terms like private, public and protected seem to have a well-defined, albeit somewhat general meaning. Final, on the other hand, is ambiguous.

The issue with access modifiers (private, public, protected and package in Java) is that they’re handling two different things which are not related.

One thing is controlling which objects may see and call properties (attributes and methods). Generally, public means that anyone may access a property, while private restricts access to the owning object only.

The other thing is controlling whether a property gets inherited by a subclass. In this role, public means that it does, while private means that it doesn’t.

This double role of these keywords necessitated the additional keyword “protected”, which means that it is accessible as if it was private, but it inherits as if it was public.

My issue with this system is twofold:

a) I see absolutely no reason, except for the paranoia of incompetent programmers, why would a property not be inherited at all times? A class is a representative of a type, and a type is defined by the properties it displays; so if a type has some property, it’s only natural that its subtype does it as well; if it doesn’t, it’s the subtype’s responsibility to define its properties, and not the parent’s. IOW, the second role of these keywords is totally superfluous and should, ideally, be completely removed.

b) If the above would be true, a property could have only two states: visible to all (public) and visible only to the object itself (private). This means that one of this keywords is not needed, since we could determine a default state by the lack of a keyword – and IMO the default should be private and the keyword public, as public properties define our object’s interface.

An extra step could be taken by restricting the public keyword to methods only – attributes should be private and never public; if you need an attribute, use a method. Or even better, we could eliminate the attributes completely and turn them into dynamic properties defined as methods; but that might be stretching it a bit.

[jayboots]

As for the private / protected debate: private members are indeed inherited to a certain extent in that a child class can not redeclare those member names. What this says is that the defining class is insisting on that name for its own internal use. In this way it protects itself from children classes that may otherwise abuse that member. OTOH, protected members allow child classes to do what they will. So, the argument that a type contains members that are always visible is a misnomer – there are times when a type may want to restrict its internal mechanism so that even subclasses can not access it. This, undoubtedly, will disturb those who favor a purely dynamic style of coding since for those sorts of codes, everything is usually kept entirely open without any concern for “safety”, which itself is considered a hindrance. Personally I think we can live with only two access levels in PHP but at the same time, it doesn’t bother me at all that there are 3 levels.

[McGruff]

@jayboots

What this says is that the defining class is insisting on that name for its own internal use.

I wonder if that could be a smell suggesting an inheritance hierarchy should be broken up?

[Czaries]

All I really want to see is:

• Full Unicode support (needed especially in the string manipulation functions)
• Array shorthand syntax $a = {1, 2, 3};
• Support for functions and constants in declarations, like below:

function myFunction($option1 = 0, $option2 = OPT2_DEFAULT, $option3 = getOpt3Default())
{
    // etc...
}

class xyz
{
    public $option1 = 0;
    public $option2 = OPT2_DEFAULT;
    public $option3 = getOpt3Default();

    // etc...

}

[dagfinn]

@BerislavLopac

a) I see absolutely no reason, except for the paranoia of incompetent programmers, why would a property not be inherited at all times?A class is a representative of a type, and a type is defined by the properties it displays; so if a type has some property,

Pragmatically speaking, the bigger problem is that parent and child classes are tightly coupled. I’m not sure, but I’m inclined to see this behavior as an attempt to alleviate that problem. It’s probably not a successful attempt; it’s better to find alternatives to implementation inheritance.

[dagfinn]

@BerislavLopac

a) I see absolutely no reason, except for the paranoia of incompetent programmers, why would a property not be inherited at all times?A class is a representative of a type, and a type is defined by the properties it displays; so if a type has some property,

This is an interesting idea I’ve never thought through. My initial reaction is this: Pragmatically speaking, the bigger problem is that parent and child classes are tightly coupled. I’m not sure, but I’m inclined to see the behavior of private properties as an attempt to alleviate that problem. It’s probably not a very successful attempt; it’s better to find alternatives to implementation inheritance.

[33degrees]

@Czaries

• Support for functions and constants in declarations, like below:

You can already use constants, and I’m not sure being able to use functions is truly required, since you can easily work around it.

[michel]

@jayboots

Hmm. Well, it is not at all clear to me why you would want to do the former. Maybe your intention is to simply log some condition’s outcome?

Throw an Exception instance, just have internals take care of instantiation.

@jayboots

Besides, I don’t see how much more convenient it really is

Same reason shorthand notation exists in for example JavaScript, Python and CSS: brevity. I guess it’s a matter of taste.

[Chris_Corbyn]

@33degrees

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.

Sorry, just had to point something out here, albeit, something IE kindly haven’t implemented:

@"Mozilla Dev"

Multiple catch Blocks
A single try statement can contain multiple conditional catch blocks, each of which handles a specific type of exception. In this case, the appropriate conditional catch block is entered only when the exception specified for that block is thrown. You can also include an optional catch-all catch block for all unspecified exceptions as the final catch block in the statement.

For example, the following function invokes three other functions (declared elsewhere), which validate its arguments. If a validation function determines that the component that it is checking is invalid, it returns 0, causing the caller to throw a particular exception.

function getCustInfo(name, id, email)
{
   var n, i, e;

   if (!validate_name(name))
       throw "InvalidNameException"
   else
       n = name;
       if (!validate_id(id))
          throw "InvalidIdException"
       else
          i = id;
       if (!validate_email(email))
          throw "InvalidEmailException"
       else
          e = email;
       cust = (n + " " + i + " " + e);
       return (cust);
}

The conditional catch blocks route control to the appropriate exception handler.

try {
// function could throw three exceptions
   getCustInfo("Lee", 1234, "lee@netscape.com")
}

catch (e if e == "InvalidNameException") {
// call handler for invalid names
   bad_name_handler(e)
}

catch (e if e == "InvalidIdException") {
// call handler for invalid ids
   bad_id_handler(e)
}

catch (e if e == "InvalidEmailException") {
// call handler for invalid email addresses
   bad_email_handler(e)
}

catch (e){
// don't know what to do, but log it
   logError(e)
}

[datune]

Unicode support!

Everything else can wait for PHP7 imho.

[jozef]

I am starting using PHP 5.3 in real project. I have found some missing features in PHP 5.3

• full Unicode support in core
• namespace visibility
  bugs.php.net/bug.php?id=45681

[kyberfabrikken]

You do realise that this thread is 3 years old, right?