Add #[NamedParameterAlias] attribute

[beberlei]

The sooner we add this functionality to allow a second alias name of a parameter when using the new "named parameters" feature, the better, because open source libraries will only be able to use this across versions when their minimum version includes this feature.

In the long term, open source code (closed source as well) will want the ability to a.) build APIs using named params b.) have the flexibility to refactor parameter names.

Addressing this need with an attribute would in my opinion be a good idea, because it requires very little code and only affects the code path of named params in a single isolated place.

RFC: https://wiki.php.net/rfc/named_parameter_alias_attribute

[TysonAndre]

It seems like useful functionality to have; the additional error handling and handling of edge cases should be possible to add.

[TysonAndre]

Suggested change

	zend_error_noreturn(E_ERROR, "NameAlias::__construct(): Argument #1 ($alias) is required");
	zend_error_noreturn(E_ERROR, "NamedParameterAlias::__construct(): Argument #1 ($alias) is required");

[TysonAndre]

There should be more tests and checks in the implementation, e.g.

1. Should invalid identifiers such as NamedParameterAlias("some-name") throw or be silently forbidden for invalid variadic arguments?
2. Should php warn/throw if using an alias for a parameter name that was already used? (test(#[NamedParameterAlias("bar")] $foo = null, $bar = null))
3. Handling supporting more than one alias?

[TysonAndre]

A complete implementation of this would support

1. Supporting or forbidding multiple NamedParameterAlias values on a single parameter (EDIT: The RFC mentions that's still undecided, but my preference would be repeatable)
2. Error checking - (1) check if there is at least one argument, (2) check if the type is a string, (3) possibly attempt to evaluate the argument if the type is IS_CONSTANT_AST and check for EG(exception) and return -1
3. It may be useful to add some sort of bit flag to the function when compiling to indicate that there are parameter aliases to avoid the need to loop in cases EXPECTED(*cache_slot == fbc) doesn't always return early for, such as dynamic calls or polymorphism.

Also, it may be more efficient for the common case to loop over all arguments first and check arg_info->name, and only try to load the attributes in a separate loop if the first attempt failed (efficient for non-variadic functions, but not for variadic functions)

[TysonAndre]

It looks like it'd be a bit more efficient to do this outside of this loop and find the parameters where attr->offset > 0 to avoid quadratic runtime - e.g. if there was a function with 20 parameters with attributes, it'd loop over all 20 of them just to find the ones at position i, performing 400 operations

The index to use would be attr->offset - 1

static zend_attribute *get_attribute_str(HashTable *attributes, const char *str, size_t len, uint32_t offset)
{
	if (attributes) {
		zend_attribute *attr;

		ZEND_HASH_FOREACH_PTR(attributes, attr) {
			if (attr->offset == offset && ZSTR_LEN(attr->lcname) == len) {
				if (0 == memcmp(ZSTR_VAL(attr->lcname), str, len)) {
					return attr;
				}
			}
		} ZEND_HASH_FOREACH_END();
	}

	return NULL;
}

ZEND_API zend_attribute *zend_get_parameter_attribute(HashTable *attributes, zend_string *lcname, uint32_t offset)
{
	return get_attribute(attributes, lcname, offset + 1);
}

[tuqqu]

what do you think of renaming it to just #[ParamAlias]?

[iluuu1994]

@beberlei Are you still planning on pursuing this RFC?

[beberlei]

@iluuu1994 realistically i do not have time at the moment, do you want to take over?

[iluuu1994]

Not personally. I'm closing stale PRs. And since named params have been introduced we've had little feedback about needing this feature so I'm not sure it's even necessary.

Can this PR and RFC be closed?