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.
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; ... }
Note that interfaces already support defined constants on them, so if you want to support abstract constants you may need an abstract keyword anyway. Depends on what the parser will let you do.
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.
We thought about it when building interface property support as part of property hooks. We didn't do it for two main reasons.
-
The use cases are pretty slim, as you ought to be using object properties 95% of the time. In the rare case that you are using a static property as a metadata declaration mechanism, we already have attributes which are more powerful anyway.
-
Static properties are way harder to deal with in the engine, because reasons, and we didn't want to spend the effort on something so niche.
Even if you're OK with #1, you'll still run into #2, I imagine. (I don't recall details, but Ilija may.)
--Larry Garfield