Rebase

[thekid]

Scope of Change

In PHP 7, type hinting has introduced "string", "int", "double", "bool", "object", "resource" etc. as type names. Since PHP's class names are case-insensitive, and to prevent ambiguity, classes are not allowed to be named like this, neither in global scope nor inside a namespace. The XP Framework will need to adapt to this change.

Rationale

Functionality

The conflicting classes are:

The core class null

Inside lang.base.php, there's a class "null" which is used for the "safe" fatal error which raises exceptions. Since PHP 7 has recoverable errors for this and there's also the null coalesce operator ??, we suggest to remove this functionality entirely.

Our base class lang.Object

All of the XP Framework's classes are guaranteed to implement the lang.Generic interface so we can easily type-hint we're expecting any XP object here on the one side, and at the same time rely on things like hashCode(), equals(), getClass() and toString(). This can easily be done by extending the base class lang.Object.

Here are the options:

• Rename base class to something different, e.g. lang.Val.. People would simply rewrite their extends statement by global search/replace (we could provide a tool for this). Including class aliasing to provide forward-compatibility, this is probably the less obtrusive change,
• Remove base class and provide a trait lang.Val. Same as above, though class X extends Object { ... } would be replaced by class X implements Generic { use Val; ...}. This might have a bad effect memory-wise due to trait's inner working.
• Rewrite methods to core functions and __compare()/__hashcode()/...-style callback magic inside classes for overwriting. This is the PHP-way, and would also raise interop with other frameworks, but have a negative performance impact (method_exists vs. instanceof).
• Add a lang.Value interface with toString(), hashCode() and compareTo() methods. The latter supersedes equals(). See https://wiki.php.net/rfc/comparable

Type wrappers

There are various problems with the lang.types package:

package lang.types {

  // These directly clash
  public class lang.types.Float
  public class lang.types.String

  // These are aliases and might be problematic in the future
  public class lang.types.Double
  public class lang.types.Integer
  public class lang.types.Boolean

  // These are "safe" for the moment:
  public abstract class lang.types.Number
  public class lang.types.ArrayList
  public class lang.types.ArrayMap
  public class lang.types.Byte
  public class lang.types.Bytes
  public class lang.types.Character
  public class lang.types.Long
  public class lang.types.Short
}

Following RFC #296 the entire type wrapper package will be extracted. An alternate package if necessary can chose to come up with e.g. prefixed or suffixed names (e.g. "FloatNum") and a changed API (like "StringBuffer", which is no longer immutable).

Security considerations

Speed impact

Dependencies

Related documents

• https://wiki.php.net/rfc/reserve_more_types_in_php_7
• https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
• https://twitter.com/bovigo/status/580483273740169218

[thekid]

The case for a baseless framework

Exceptions

PHP7 brings lots of "non-XP-classes" to the user front, e.g. TypeException for argument mismatches and EngineExceptions for a variety of situations including return type hint violations. We will need to catch Exceptions more often. See also https://wiki.php.net/rfc/engine_exceptions_for_php7

Interop

Other frameworks either don't have a base class or don't share ours anyway. In more and more situations will we encounter cases where we can't rely on toString(), hashCode(), equals() and getClass() or type() (its proposed replacement in XP7) being available.

Usage

A quick reality check revealed we don't use the Generic class as typehint / check for it via instanceof in many places. This would mean we could realistically consider removing the base class altogether.

Checking for toString(), hashCode(), equals()

One possibility would be simply to check for the method's existence:

-if ($value instanceof Generic) return $value->toString();
+if (method_exists($value, 'toString')) return $value->toString();

Another possibility would be to introduce interfaces for the above, e.g, Representable and Comparable.

Calling getClass()

This could be replaced by the global typeof() function which already exists:

-$type= $val->type();
+$type= typeof($val);

Upside is it also works for primitives, e.g. if $val is a string or an array. For getClassName() (commonly used in toString() implementations), we'd use nameof($this).

Defaults

We do lose the default implementation by not extending, but toString() for example rarely produces anything much better than a var_dump() most of the time anyway, equals() is just as good as ===. It's a bit tougher with hashCode() but we could think about this.

It already works

Try removing extends Object from one of your classes. There are good chances it simply works.

Missing methods

For the case that a method doesn't exist, we can now also rely on PHP throwing an exception; so we don't need lang.Object's __call and __callStatic any more.

Pain point: Extension methods

This feature will no longer work, alas. Could have a bright future serving BC/FC break prevention, but not heavily used due to their performance problems.

We could reintroduce them on a library basis, here are some ideas

[thekid]

If php/php-src#1282 gets merged, we can also get rid of lang.Throwable, lang.Error and lang.XPException. They'd be built right in.