Hi John,
I like this idea, and along those lines, I would suggest that
interfaces could also benefit from this.Currently, you can write something like:
interface I { public int $x { get; } } abstract class C implements I {} class CC extends C {}//Fatal error: Class CC contains 1 abstract method and must therefore
be declared abstract or implement the remaining method (I::$x::get) in
/in/U49c0 on line 9The abstract class C does not by itself meet the requirements of the
interface I, but that's okay, because it's abstract. Conformance is
required by its concrete subclasses (which in this case errors because
it's missing).What's missing is for interfaces to be able to have static property
requirements (and constants, and readonly also). So we could fill in a
gap with interfaces as well.
I initially didn't contemplate support for abstract class constants for
interfaces as I hadn't encountered a situation where having it on an
interface would be better than on a base class or trait.
Now that you have brought it up I can envision an interface
FieldChecker with a constant MESSAGE that would expected to be
there. In this case it's the fact that the message is accessible
statically, rather than it being able to be accessed by a method, that
makes it useful.
Given that this RFC proposal would add support for class constant
declaration, I don't see a problem on adding constants to interfaces.
In this case, class constant declaration would look something like:
interface I {
public const string CONSTANT_NAME;
...
}
abstract class C {
abstract public const string CONSTANT_NAME;
...
}
trait T {
abstract public const string CONSTANT_NAME;
...
}
What I do find rather curious is that interfaces don't already have any
support for static properties. Is there a reason for this?
If no one opposes, I'll be include support for class constant
declaration in interfaces to the RFC.
That said, I'd appreciate to have more feedback from the rest of the
internals.
Thank you for yours.
Sincerely,
Eloi Montañés.