PHP wishlist: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
No edit summary
Line 3: Line 3:


==Trait wishlist==
==Trait wishlist==
* [https://toot.cat/@woozle/106783305731555278 Combine {{f/code|trait}}s and {f/code|interface}}s] -- they're basically subsets of the same thing.
* Where class A uses trait B, where both define function C(), A::C() should be able to call parent::C() to refer to B::C() if it exists.
* Where class A uses trait B, where both define function C(), A::C() should be able to call parent::C() to refer to B::C() if it exists.
* You should be able to define function parameters as traits, the same way you can do for classes or interfaces.
* You should be able to define function parameters as traits, the same way you can do for classes or interfaces. (This would also be solved by combining traits and interfaces.)
* [[/trait implements]]: Traits should be able to <code>implement</code> one or more interfaces, the way classes can.
* [[/trait implements]]: Traits should be able to <code>implement</code> one or more interfaces, the way classes can.
more.
more.
* When using a trait, it should be possible to add a prefix to all of the member variables and functions -- so that you could use a trait in multiple ways.
* When using a trait, it should be possible to add a prefix to all of the member variables and functions -- so that you could use a trait in multiple ways.
** Example: a trait which is a wrapper for a member-variable object -- if you needed two such objects with different names, you wouldn't have to re-write the access shortcuts for each one.
** Example: a trait which is a wrapper for a member-variable object -- if you needed two such objects with different names, you wouldn't have to re-write the access shortcuts for each one.
** This hypothetical feature, as far as I know, the only reason to keep traits and interfaces as separate things.


==<code>first</code> keyword==
==<code>first</code> keyword==

Revision as of 14:42, 19 August 2021

These are features I wish PHP would add. As far as I know, they are not available on PHP 8, though I have only used up through 7.4 as of this writing.

Trait wishlist

  • Combine traits and {f/code|interface}}s -- they're basically subsets of the same thing.
  • Where class A uses trait B, where both define function C(), A::C() should be able to call parent::C() to refer to B::C() if it exists.
  • You should be able to define function parameters as traits, the same way you can do for classes or interfaces. (This would also be solved by combining traits and interfaces.)
  • /trait implements: Traits should be able to implement one or more interfaces, the way classes can.

more.

  • When using a trait, it should be possible to add a prefix to all of the member variables and functions -- so that you could use a trait in multiple ways.
    • Example: a trait which is a wrapper for a member-variable object -- if you needed two such objects with different names, you wouldn't have to re-write the access shortcuts for each one.
    • This hypothetical feature, as far as I know, the only reason to keep traits and interfaces as separate things.

first keyword

There needs to be a companion to the final keyword in #PHP.

Background: The "final" keyword indicates that a method cannot be overridden in a child class.

Wish: There needs to be a "first" keyword to prevent accidentally creating a method ancestor which might get completely bypassed because a descendant doesn't call parent::[method] because it doesn't expect one to exist.

Either that, or a way to allow calls to parent::[method]() even when there's no method ancestor.

The virtual fx chaining idea below would also address this problem, though I'm not sure it's as good a solution.

post: 2021-05-31 @TootCat

Virtual fx chaining

Current Behavior

If you have class B which extends class A and they both define function C(), and you call C() in an object of class B, you just get B::C(). The class-structure may be designed, however, in such a way that it's necessary to also run code in the parent class, where B is adding functionality rather than replacing it.

The standard way of accomplishing this is for B::C() to call parent::C() at some point. However it can often be difficult to know whether there is a parent C(), especially where B isn't immediately descended from A (e.g. B extends A3 which extends A2 which extends A1 which extends A) or where there are traits being introduced at any point.

The best way I've found for dealing with that is for the class structure to define a stub C() which does nothing (function C() {}), and to have a rule that all other implementations of C() must call parent::C(). This, however, requires remembering the rule, and also seems a little wasteful in that there may be a lot of calls to an empty function that is really just a placeholder.

Proposal

To fix this, I propose a set of keywords for use in function definitions. This keyword will set the default behavior of offspring functions, and overrides any default if used in offspring functions. Using A, B, and C() as above, this is what will happen if C() is called in an object of class B:

  • replace (or instead): B::C() replaces A::C(), so only B::C() will execute.
    • This is the current behavior.
  • before: A::C() will execute, then B::C().
  • after: B::C() will execute, followed automatically by A::C().