Fleshgrinder wrote:

Hi,

Andrey Andreev wrote:

The question is rather "is this value a string?", only with the added
assumption that __toString() objects are treated as "string objects"
and thus fulfill the condition (another reason why I went for an
is_string() parameter).

This is a faulty assumption. The presence of __toString() doesn't mean
the object is a string, or intended to be used like one.

What is it then in your book?

It means the object can be converted to a string. But such a conversion
may entail a loss of information and not be equivalent to the object
itself. It might be a “human-readable” form, for instance.

Sure, and? The to-be-called function does not require that all
information must be preserved, it requires that the to-be-passed
argument is convertible into a string. Most probably because it wants to
perform some actions on the string value, but the reasons are not of
interest.

As a matter of fact, any function that requests a string only asks for a
string and is not aware of its contents, hence, it is also not aware of
whether the to-be-passed argument might suffer from loss of information.

The same is true for instance if we pass a traversable of some sort to a
function that requires an iterable. We loose information! The only
difference here would be that we can use feature detection to gather
that information again, whereas in the Stringable implementation I
envision we cannot. This is because I would convert the object to a
primitive string before handing it in to the to-be-called function.

This is a controlled conversion, from the sender and receiver side which
is very handy in many situations.

That being said, it is just sugar topping, and not having it is not a
deal breaker either (since explicit casts or dedicated toString
methods are always there). However, it would avoid certain situations of
explicit casts where one might needlessly cast primitive strings,
whereas with the stringable data type the runtime could take care of it.
It should also be possible to generate more efficient code, since the
runtime knows better what situations are possible. Something that is
unclear with an explicit cast.

To give an example: Exceptions implement __toString(), which contains the
exception message, location information and backtrace. Of course,
exceptions are rather different from strings and treating an exceptions as
a string is usually incorrect.

Nikita

For the receiver its a string and not an exception, and it does not care
that it was one.

Now, after thinking more about this, I actually think that it should
cover other scalar types too. It might be very strict, which is nice,
but at the same time this strictness does not truly add a lot of value.
After all, bool, int, float, and null can always be converted to a
string too.

In the end the use-case is to have a type constraint in strict mode that
allows more types to pass through than string only. Like a formatter
(think printf).

--
Richard "Fleshgrinder" Fussenegger

Hey! :)

The reference is actually not a problem for a Stringable because you
would get the "Only variables can be passed by reference" error with an
object if strict_types is enabled.

Simply because the object MUST be converted into a string. The
object itself does not satisfy the constraint, but the object clearly
states that it can be converted into a string at any point.

This is the part I disagree with. The object clearly states that it can be
turned into a string when you are done using it as a object. If it gets
turned into a string, you can no longer use it as a object.

There is a difference between changing an int to string and an object to
string, in that afterwards the int->string can continue to be treated as an
int afterwards, thanks to loose typing (otherwise it wouldn't have become a
string in the first place). However with an object->string afterwards it
can ONLY be treated as a string, it can no longer be treated as an object.
Meaning

$int = 3;
foo(3);

Sorry this should have been:
foo($int);

var_dump(++$int); // 4, success, no errors

$obj = new Foo('a');
foo($obj);
var_dump($obj->method()); // Fatal error: call to member function method
on string.

To me, this doesn't make sense.

Not doing so would violate what strict_types actually promise us. ;)

--
Richard "Fleshgrinder" Fussenegger

function foo(string &$s) {
    $s = 'foo';
}

final class Stringable {
    public function __toString() {
        return 'stringable';
    }
}

$stringable = new Stringable;

foo($stringable);
// Fatal error: Only variables can be passed by reference in ...

$string = (string) $stringable;
foo($string);
// Heureka!

Why is that?
At the point where we reach the call foo($stringable) we need to
perform various checks, which will lead to the conclusion that we
require a string and that the value of $stringable is an object that
can be converted to a string. That is exactly what we do. Hence, the
call is not foo($stringable) but rather foo('stringable'), the value
that we received from the conversion.

The conversion is in place, just like a cast would be, hence ...

foo((string) $stringable);

... is equivalent to ...

foo($stringable);

... with a type constraint of string for that particular argument.

Obviously we should yield another error message in such cases, to ensure
that people are not confused. However, this is only about the logic.

This means by implication that a ...

function foo(stringable &$s) { }

... is impossible. Something we encounter a lot lately with many
features that we would like to have. This is also one of the reasons why
many higher languages do not support pointers in their type systems.

--
Richard "Fleshgrinder" Fussenegger

Hi,

I still don't understand what you're using this check for that means you
want to exclude integers. If you're passing on the value to anything that
actually needs a string, you're doing a string cast, either explicitly or
implicitly, so there's no difference between me passing you (string)'42',
(int)42, or new class { function __toString() { return '42'; } }

This goes all the way back to the heated discussion about scalar type
hints ... Being explicit is the entire point, and why many people
wanted strict typing.

Stringable seems very explicit and strict to me, since it is opt-in.
Currently there is no way to have the ergonomics of coercion if strict
mode is active for a file. This could be a very explicit way to enable
it for portions.

I don't understand what you're trying to say here, or rather what you
mean by "stringable" at this point ... Is it a compound type for
string and __toString() objects only, or not? Your last comments
suggest that it isn't.

What is the use case where every other scalar (and null) type is not
acceptable? I defended that stringable should bridge only string and
objects with __toString too first, but after thinking more about it,
there is no real world reason why one would need that. Almost all use
cases I can think about evolve around strict mode and some function that
simply does not care what it was. Hence, stringable would truly act like
the into trait in Rust.

Think of value objects. Perhaps you'd have a few methods on a value
object, but mostly use it to give context to a scalar type value.

For example, a Cookie object may have the cookie attributes (domain,
path, etc.) as value objects, but they can easily be created from raw
strings, while other types would be ambiguous.
A similar effect could be desirable for HTTP headers.

All of these can work with any other scalar value that was coerced to a
string. I actually think that most examples given will have dedicated
strictly typed methods to ensure that the value is correct for their
domain. Don't forget that a string in PHP is a binary buffer and may
contain pretty much every kind of malicious stuff that you never wanted
or expected. Validation is absolutely necessary at all times when
dealing with strings. Having an integer that is converted to a string
does not make strings more evil than they already are.

How can "any other scalar value" work? Using the cookie and headers examples:

• booleans can be used as On/Off flags for the secure and httpOnly
  cookie attributes, but aren't valid literal values for any of the
  attributes, or any HTTP header.
• integers are valid as a few headers' values - that is true, but
  certainly in a minority of cases
• floats may be used for the q(uality) attribute in content
  negotiation (and nothing else AFAIK), but that is a very, very narrow
  domain
• null is obviously invalid ... who sends an empty header? And if you
  have a use case where you do want to use them, we can already make
  anything nullable

Of course the string values should be validated, unless you want to
allow setting arbitrary headers, e.g.:

abstract function setHeader(stringable $name, stringable $value);

... but filtering out the known to be invalid types is validation.
And just that much better if it happens at compile time.

You actually already need to deal with all kinds of data that gets
coerced, since you have no control over the strict mode of the caller. ;)

Yes, and I hate that, which is why I want something that doesn't
silently accept every single scalar type.

Here's the radical idea I mentioned in my initial email: make strict
mode enforceable and/or add dedicated syntax for strict type hints.
But that goes way beyond my current proposal ... if anybody wants to
talk about this, please start a separate discussion.

Also, we're talking about strings here only because we don't have
__toInteger(), __toFloat(), etc. I'm not saying we should, but if we
did - similar use cases would be present for other scalar types too.
Even easier to imagine - a DateTime object would probably have
__toInteger() returning a UNIX timestamp.

I actually consider the existence of almost all magic methods as a
hindrance for evolving the language, and definitely do not desire to get
more of them into core. Having a DateTime::toTimestamp() is much more
valuable than a DateTime::__toInteger().

These magic methods are a result of the incoherent type system. Treating
the symptoms instead of the root cause. The story would be different if
a Timestamp could extend Integer which would directly allow it to be
passed to all functions that are capable of dealing with an Integer.
(Or any other possible constellation of a more sophisticated type system.)

I explicitly noted that I'm NOT suggesting we should be adding more
magic, but simply using that for a hypothetical example.

Cheers,
Andrey.

For example, a Cookie object may have the cookie attributes (domain,
path, etc.) as value objects, but they can easily be created from raw
strings, while other types would be ambiguous.
A similar effect could be desirable for HTTP headers.

OK, now we have some concrete examples, thanks. I would say that in
these cases, what you actually want is a much tighter contract: not just
"can be converted to string", but "intended to be used in this context".

It fits with what I was saying before about "if you can't name it, maybe
it isn't the right abstraction". In this case, you want to accept some
particular value objects but not, say, Exceptions - which are as useless
for your purpose as an integer, even though (string)$foo would work fine
on both.

So you want objects that have promised to behave appropriately for this
context; that could be as simple as:

interface HTTPHeaderObject {
public function __toString();
}

....with appropriate documentation that objects declaring that they
implement this interface promise to behave in a specific way when cast
to string. This is much clearer than detecting __toString(), which only
promises "I can be cast to string" - the same promise that is made by
all scalar values.

In order to accept this or a string in a type hint, you need Union Types:

function setHeaderValue(string|HTTPHeaderObject $value) { ...

Or you could require the client to pass a respective string wrapper
which extends HTTPHeaderObject instead of a plain string.

--
Christoph M. Becker

Hi Rowan,

For example, a Cookie object may have the cookie attributes (domain,
path, etc.) as value objects, but they can easily be created from raw
strings, while other types would be ambiguous.
A similar effect could be desirable for HTTP headers.

OK, now we have some concrete examples, thanks. I would say that in these
cases, what you actually want is a much tighter contract: not just "can be
converted to string", but "intended to be used in this context".

I know you're trying to help, but I keep reading this as "OK, now I
can try to invalidate your use case".

There's always an alternative solution. I only ask that our
alternatives here include a middle ground between the two extremes of
"accept pretty much everything" and "be as strict as possible".

It fits with what I was saying before about "if you can't name it, maybe it
isn't the right abstraction". In this case, you want to accept some
particular value objects but not, say, Exceptions - which are as useless for
your purpose as an integer, even though (string)$foo would work fine on
both.

I can name it; the name is just ridiculously long/impractical because
__toString() is a special case unlike anything else in PHP.

So you want objects that have promised to behave appropriately for this
context; that could be as simple as:

interface HTTPHeaderObject {
public function __toString();
}

...with appropriate documentation that objects declaring that they implement
this interface promise to behave in a specific way when cast to string. This
is much clearer than detecting __toString(), which only promises "I can be
cast to string" - the same promise that is made by all scalar values.

My argument is that while every scalar value may promise that it "can
be cast to string", the fact that you need to explicitly declare it
means that only __toString() can promise that it "can be useful as a
string" (context-dependent of course).

In order to accept this or a string in a type hint, you need Union Types:

function setHeaderValue(string|HTTPHeaderObject $value) { ...

I would love union types, but unfortunately:

• https://wiki.php.net/rfc/union_types was declined
• They only address parameter hints, and I also want runtime checks
• Would still leave a gap for me, as I (perhaps stubbornly) want to
  treat __toString() objects as regular strings

Though, I can live with the extra function call if we have union types
as that would greatly reduce my needs related to that last point.

For broader use, we could perhaps have named unions:

type HTTPHeaderType = union(string, HTTPHeaderObject);
if ( $value instanceOf HTTPHeaderType ) { ...

An excellent idea, indeed - I'd be a huge proponent of that.

Meanwhile, of course, you can just use a boring old user-defined function:

function is_valid_http_header_value($value) {
return is_string($value) || $value instanceOf HTTPHeaderObject;

}

Yes, and I can already wrap is_string($var) || method_exists($var,
'__toString') in a function, even "override" the original is_string()
with my version, in a namespace. The point was to eliminate that
boilerplate code.

Obviously, I'm getting zero support on the idea and we're running
around in circles at this point, so I guess that's it from me here.

Cheers,
Andrey.