Concept: "arrayable" pseudo type and \Arrayable interface

5 years ago by Aimeos | Norbert Sendetzky — view source — reply

unread

Since PHP 7.1 there's the "iterable" pseudo type hint that matches
"array" and "Traversable".

PHP frameworks would profit from support of an "arrayable" pseudo type
hint that matches "array" and all objects that implements "Traversable",
"ArrayAccess" and "Countable".

Thus, we could pass arrays or all objects that behave like arrays to
methods and do:

function useArrayable( arrayable $arg ) : arrayable {
$cnt = count( $arg );
$value = $arg['key'];
foreach( $arg as $key => $entry ) { ... }
return $arg;
}

It would be useful to implement an Arrayable interface too:

interface Arrayable extends \Iterator, \Countable, \ArrayAccess
{
public function toArray() : array;
}

Then, we can use array like objects:

class Test implements \Arrayable
{
// ...
}

$arrayable = new Test();
$arrayable['key'] = $value;
$arrayable = useArrayable( $arrayable );

And if necessary, we can convert them to native arrays:

if( $arrayable instanceof \Arrayable ) {
$arrayable = $arrayable->toArray();
}

5 years ago by Ken Stanley — view source — reply

unread

On Sun, Nov 17, 2019 at 9:42 AM Aimeos | Norbert Sendetzky <
norbert@aimeos.com> wrote:

Since PHP 7.1 there's the "iterable" pseudo type hint that matches
"array" and "Traversable".

PHP frameworks would profit from support of an "arrayable" pseudo type
hint that matches "array" and all objects that implements "Traversable",
"ArrayAccess" and "Countable".

Thus, we could pass arrays or all objects that behave like arrays to
methods and do:

function useArrayable( arrayable $arg ) : arrayable {
$cnt = count( $arg );
$value = $arg['key'];
foreach( $arg as $key => $entry ) { ... }
return $arg;
}

It would be useful to implement an Arrayable interface too:

interface Arrayable extends \Iterator, \Countable, \ArrayAccess
{
public function toArray() : array;
}

Then, we can use array like objects:

class Test implements \Arrayable
{
// ...
}

$arrayable = new Test();
$arrayable['key'] = $value;
$arrayable = useArrayable( $arrayable );

And if necessary, we can convert them to native arrays:

if( $arrayable instanceof \Arrayable ) {
$arrayable = $arrayable->toArray();
}

--

Also the toArray() should be called when an Arrayable is cast to an array:
(array)$arrayable.

And shouldn’t the toArray match the same naming semantics as __toString?

"Do not go gentle into that good night. Rage, rage against the dying of the
light." — Dylan Thomas

5 years ago by Rowan Tommins — view source — reply

unread

PHP frameworks would profit from support of an "arrayable" pseudo type
hint that matches "array" and all objects that implements "Traversable",
"ArrayAccess" and "Countable".

...

It would be useful to implement an Arrayable interface too:

interface Arrayable extends \Iterator, \Countable, \ArrayAccess
{
public function toArray() : array;
}

It feels like there are two alternative suggestions here. Not only do
they use the same keyword to mean different things, but "convertible to
array", and "usable as array" seem like distinct concepts to me.

For the "convertible to array" case, I think __toArray, or an interface
specifying just that one method, would make more sense than combining it
with the existing interfaces. I'm sceptical of that concept, though,
because most objects could be converted to many different arrays in
different circumstances, each of which should be given a different and
descriptive name.

For the "usable as array" case, the big advantage would come if internal
array_* functions could take such objects, but that requires a bit of
thought on how each function should behave. There could also be some
surprising behaviour passing infinite iterators, or objects where the
output of ArrayAccess and iteration don't match up. It might make sense
to have objects opt into an Arrayable interface, to make clear they're
expecting to be used this way; but require no additional methods other
than those required by Iterator (or Traversable), Countable, and
ArrayAccess.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

5 years ago by Mike Schinkel — view source — reply

unread

Since PHP 7.1 there's the "iterable" pseudo type hint that matches
"array" and "Traversable".

PHP frameworks would profit from support of an "arrayable" pseudo type
hint that matches "array" and all objects that implements "Traversable",
"ArrayAccess" and "Countable".

If we are going to open up arrays for enhancement in PHP 8 I would ask that we seriously consider addressing the various differences between a built-in array and an instance of ArrayObject and/or the related associated interfaces such that the objects can be used interchangeably with a built-in array, i.e. that ArrayObject and the related associated interfaces can fully replace the use of arrays when refactoring.

Specifically I would propose that we provide some type of mechanism that would allow the developer to cause is_array() to return true on an ArrayObject/interfaces. Maybe something like this (I have not considered all the special cases, I am just spitballing in concept here):

class MyArray extends ArrayObject {
function __AsArray() {
return true;
}
function hello() {
echo 'Hi!';
}
}
echo is_array(new MyArray()) // outputs: true
? 'true'
: 'false';

Also, when the object is used by any of the internal PHP functions that expect an array, such as sort() the internal function would treat the object as an array inside the function. This also means returning the object from methods like array_filter() when an ArrayObject with __AsArray()===true is passed.

Even though these objects would be treated as arrays when in an array context they should still be able to call their own methods, e.g.

$array = new MyArray()
$array->hello() // outputs: Hi!
? 'true'
: 'false';

This would go a long way to allowing PHP developers to incrementally clean up the gobs of legacy code in the wild, and move to objects where appropriate.

-Mike

5 years ago by me@jhdxr.com — view source — reply

unread

The union types RFC passed, so I didn't see much value in the arrayable pseudo except pressing less keys.

Regarding the Arrayable interface, or toArray method. Since it extends Iterator, iterator_to_array can do the job already.
So what's the benfits for introducing this new interface?

I would suggest to find a way to make those built-in array_* functions support the arraylike objects, no matter which interface it requires, existing ArrayAccess, or any new interface.

Regards,
CHU Zhaowei

-----Original Message-----
From: Aimeos | Norbert Sendetzky norbert@aimeos.com
Sent: Sunday, November 17, 2019 10:41 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable
interface

Since PHP 7.1 there's the "iterable" pseudo type hint that matches "array"
and "Traversable".

PHP frameworks would profit from support of an "arrayable" pseudo type
hint that matches "array" and all objects that implements "Traversable",
"ArrayAccess" and "Countable".

Thus, we could pass arrays or all objects that behave like arrays to methods
and do:

function useArrayable( arrayable $arg ) : arrayable {
$cnt = count( $arg );
$value = $arg['key'];
foreach( $arg as $key => $entry ) { ... }
return $arg;
}

It would be useful to implement an Arrayable interface too:

interface Arrayable extends \Iterator, \Countable, \ArrayAccess {
public function toArray() : array;
}

Then, we can use array like objects:

class Test implements \Arrayable
{
// ...
}

$arrayable = new Test();
$arrayable['key'] = $value;
$arrayable = useArrayable( $arrayable );

And if necessary, we can convert them to native arrays:

if( $arrayable instanceof \Arrayable ) {
$arrayable = $arrayable->toArray();
}

--
To unsubscribe, visit:
http://www.php.net/unsub.php

5 years ago by Rowan Tommins — view source — reply

unread

[Note: I've included the full text of the previous message as it wasn't
sent to the list.]

It feels like there are two alternative suggestions here. Not only do
they use the same keyword to mean different things, but "convertible to
array", and "usable as array" seem like distinct concepts to me.
The name of the interface isn't perfect because it may be too close to
the type hint and therefore misleading. Suggestions for a better name
are always welcome.

The concept contains three parts:

arrayable type hint: Use objects and arrays alike

\Arrayable interface: To enable implementing objects that are "arrayable"

__toArray(): To convert objects to arrays

Like I say, the name is part of it, but the purposes also overlap the
way you describe them. It makes more sense to me to have two separate
features for two separate use cases:

If I just want to know that the object I've received can be iterated,
counted, and accessed using square brackets, then I need either a
special type hint or a new interface, but not both.
On the other hand, if I just want to know I can call toArray or
__toArray on an object, I don't care whether it implements Iterator,
Countable, etc as well.

For the "convertible to array" case, I think __toArray, or an interface
specifying just that one method, would make more sense than combining it
with the existing interfaces. I'm sceptical of that concept, though,
because most objects could be converted to many different arrays in
different circumstances, each of which should be given a different and
descriptive name.
Can you give some examples for different conversions?

Well, pretty much any method that returns array could be called "to
array", but not many would be good candidates for such a generic name.
You might return an array structure to be incorporated into a JSON
response, or to be passed to a template renderer, or to map to database
columns, etc.

The only case I can think of where a generic "toArray" method would make
sense is if you're creating a general-purpose "collection" or "list"
object, in which case you're probably better off directly implementing
methods like map and sort, rather than encouraging users to convert it
back to a plain array. It doesn't seem like a common enough use case to
need a new language feature, when it's simple enough to write
"$foo->toArray()" without anything new.

The possibility to pass arrayable objects to the array_* methods should
be out of scope for the moment and is better discussed later to keep the
pieces small, I think. You are totally right, there may be some
unexpected behavior when doing that.

The reason I mentioned it is that without it the new type hint or
interface seems rather limited: I can't imagine many "array" type
constraints being replaced with "arrayable" if you had to remember not
to pass the variable to array_map, sort, etc.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

5 years ago by Mike Schinkel — view source — reply

unread

Well, pretty much any method that returns array could be called "to array", but not many would be good candidates for such a generic name. You might return an array structure to be incorporated into a JSON response, or to be passed to a template renderer, or to map to database columns, etc.

The only case I can think of where a generic "toArray" method would make sense is if you're creating a general-purpose "collection" or "list" object, in which case you're probably better off directly implementing methods like map and sort, rather than encouraging users to convert it back to a plain array. It doesn't seem like a common enough use case to need a new language feature, when it's simple enough to write "$foo->toArray()" without anything new.

I have been pondering that objection ever since Steven Wade proposed __toArray() on the list a few months back.

In part I agree with the sentiment, and in part I feel that perfection is being the enemy of the good here. But as I had no strong argument for how it could be done better I did not say anything on the matter.

Consider this: __toArray() is hardly a rare case where a short name can be applied in multiple contexts. We have infinite contexts where we need to name methods for one context that might conflict with others, and so I have been agonizing for years over how to deal with this conundrum without resorting to really long method names.

(As an aside, I think long method names result in harder to comprehend code, and as I have never seen a set of conventions that results in multiple programmers (almost) always choosing the same long names for the same use-cases I prefer our standards to suggest shorter names so that we can maintain more consistence across programmers.)

Recently I have been experimenting with using namespaces instead of long method names, and I think using them can result in the best of both worlds and resolve your concern. Consider the following classes, each of which could have their own __toArray() method specific to their use-case:
\Widgets\Widget
\Widgets\JSON\Widget
\Widgets\Mustache\Widget
\Widgets\DbColumns\Widget
With the above you can "have your cake and eat it too." Your namespace can specify the exact context for your __toArray() and thus developers who want to use that architecture can get the benefits of a __toArray() magic method.

#jmtcw

-Mike

5 years ago by Mike Schinkel — view source — reply

unread

I'm not sure avoiding the name "toArray" necessarily leads to "really long method names" - even with extremely specific distinctions, you don't need to call the method "toJsonArrayForVersion5OfTheApi", just "toV5Json" or "getV5Array" or "formatForJsonV5".

I now realize that my commenting on my experience in reviewing legacy code — where long names are frequently used, regardless of the fact they are not required — caused you to focus on the long naming comment aside and not on the primary ask for consistency.

Even if short, a code base littered with method names like toV5Json() or getV5Array() or formatForJsonV5() is still inconsistent.

The important thing is that the method name is now communicating its purpose, whereas "toArray" communicates only its return type, and a hugely flexible return type at that.

What I was suggesting instead, which obviously was not clear, is that you communicate the purpose with the namespace and by doing so allows for the capability of casting to array be added. Otherwise the perfect is the enemy of the good.

I'm not clear what these objects represent. If I have a Widget object passed out from some business logic,

Similarly it is not clear to me was toV5Json() or getV5Array() or formatForJsonV5() mean.

However if V5 somehow has meaning then your namespaces class could just as easily be named if that is what you want:

\Widgets\ToV5Json\Widget

how do I make use of these other classes? Would I have to call "(array)(new \Widgets\Mustache\Widget($myWidget))", as sugar for "(new \Widgets\Mustache\Widget($myWidget))->__toArray()"?

Maybe we code differently, but I would never write a full namespace in code like that. I would have one of the following at the top of my PHP file:

use \Widgets\Mustache\Widget
use \Widgets\Mustache\Widget AS MustacheWidget

That would result in the following as one of — a you say — sugar for (new \Widgets\Mustache\Widget($myWidget))->__toArray():

(array)(new Widget($myWidget))
(array)(new MustacheWidget($myWidget))

However I doubt I would ever instantiate and then cast the object in the same line of code. Instead the value of array casting — to me — is in its polymorphic nature where I can have a "generic" method that can just cast to an array and instead of having to know if the developer used toV5Json() or getV5Array() or formatForJsonV5().

If so, I don't really see the benefit of the magic method over just standardising a method name, like "interface MustacheFormatter { public function getData(): array; }"

Backward compatibility is the benefit. If we standardize one any name then we can break existing code. Adding a magic method cannot break existing code unless that code violated the reserved nature of double underscore methods.

Or are you proposing we start adding __*() methods that are not actually magic?

Which is basically my objection to __toArray() - I can't think of many situations where writing (array)$foo saves or gains you anything over writing $foo->asArray() or $foo->somethingMoreSpecific()

But I and others can think of situations where it would help.

Because asArray() and somethingMoreSpecific() are neither a standard you don't get polymorphism with different named methods.

And any new standard non-magic method we add has the potential to break BC. And is unlike anything else in PHP I can think of.

OTOH, I have a hard time thinking of a scenario where __toArray() would actually cause a problem for someone like you who cannot think of a benefit. Can you present a use-case how it would cause you a tangible problem that could not be resolved with namespaces or by just creating your own somethingMoreSpecific() method and ignoring __toArray()?

-Mike

5 years ago by Rowan Tommins — view source — reply

unread

I now realize that my commenting on my experience in reviewing legacy code
— where long names are frequently used, regardless of the fact they are not
required — caused you to focus on the long naming comment aside and not on
the primary ask for consistency.

Even if short, a code base littered with method names like toV5Json() or
getV5Array() or formatForJsonV5() is still inconsistent.

Inconsistent with what? Unless you suggest we introduce enough magic
methods that every method name in your application begins with two
underscores, you are always going to have to name things.

If there is a common requirement for objects to be converted to a
particular type of array, then you should pick a standard name for that and
enforce it via code review; or better, make all those objects implement an
interface, and the compiler will enforce it for you.

That seems no harder to me than enforcing a convention that __toArray
should always be included, and have a particular meaning.

What I was suggesting instead, which obviously was not clear, is that you
communicate the purpose with the namespace and by doing so allows for the
capability of casting to array be added. Otherwise the perfect is the
enemy of the good.

I'm not asking for any kind of perfection, I'm just saying names should be
meaningful. Bear in mind that namespaces are really just part of the class
name, so all you're really saying is that you like long specific class
names and short generic method names.

Similarly it is not clear to me was toV5Json() or getV5Array() or
formatForJsonV5() mean.

I was imagining an API that had gone through different versions, so needed
methods to serialize objects into the JSON published in version 5 of a
specification.

how do I make use of these other classes? Would I have to call "(array)(new

\Widgets\Mustache\Widget($myWidget))", as sugar for "(new
\Widgets\Mustache\Widget($myWidget))->__toArray()"?

Maybe we code differently, but I would never write a full namespace in
code like that. I would have one of the following at the top of my PHP file:

Yes, that example was just me being lazy when typing the example, sorry. I
was trying to understand what the "MustacheWidget" class did, and it seems
I was correct in seeing it as an adapter.

If so, I don't really see the benefit of the magic method over just
standardising a method name, like "interface MustacheFormatter { public
function getData(): array; }"

Backward compatibility is the benefit. If we standardize one any name
then we can break existing code.

If your code base is such a mess that you can't propose any method name
without it conflicting, and can't trace usages of any method that needs
renaming to not conflict, then yes, you get a one-off benefit from the fact
that __ is reserved. That seems a pretty poor justification for a language
feature.

Since you're suggesting separate classes for each transform, how many
public methods do they have? Would making everything in your *\Mustache*
namespaces implement a MustacheFormatter interface actually be harder than
adding a __toArray method to them all?

One huge benefit I haven't mentioned yet is the ability to add parameters.
Imagine if your mustache formatters are used in both plain text and HTML
contexts, and that affects some of the data to return. If you have a
MustacheFormatter interface, you could alter it to require "getData(bool
$forHtml=false)", and only change the implementations where it mattered.
With __toArray(), you are limited to one parameter-less method per class,
so would have to create new copies of every single formatter, in a new
MustacheHtml namespace.

Thinking about it, if you're only going to allow one method per class, with
the class's namespaced name telling you what it does, you might as well use
__invoke():

use Foo\Mustache\Widget as MustacheWidget;
$tplWidget = new MustacheWidget($myWidget);
$output = $tplWidget(); // calls Foo\Mustache\Widget::__invoke()

Because asArray() and somethingMoreSpecific() are neither a standard you
don't get polymorphism with different named methods.

You can only rely on __toArray if you standardise on every object
implementing it; at which point, you can standardise on any name you like.
People are quite happily using polymorphism with named methods in literally
millions of OO code bases.

And any new standard non-magic method we add has the potential to break
BC. And is unlike anything else in PHP I can think of.

I'm not suggesting PHP standardises on some other name, just that your
code base standardises on common names for common tasks.

OTOH, I have a hard time thinking of a scenario where __toArray() would
actually cause a problem for someone like you who cannot think of a
benefit. Can you present a use-case how it would cause you a tangible
problem that could not be resolved with namespaces or by just creating
your own somethingMoreSpecific() method and ignoring __toArray()?

Well, I started this sub-thread saying I was "sceptical" rather than
"strongly opposed". If the feature was added, I would simply ignore it, and
probably argue against its use in code review and style guides.

However, other people have pointed out that unlike (string)$object,
(array)$object does have a default behaviour, and adding an overload for it
has the potential to break code relying on that. So it's not an entirely
zero-cost feature.

Regards,

Rowan Tommins
[IMSoP]

5 years ago by Mike Schinkel — view source — reply

unread

Even if short, a code base littered with method names like toV5Json() or
getV5Array() or formatForJsonV5() is still inconsistent.

Inconsistent with what?

Inconsistent with each other. If one developer names it toV5Json() and another developer names it getV5Array() then those two developers choices are inconsistent.

Yes, a team lead could require an interface be used for consistency across a team, which is fine, but it is not consistent across unrelated projects. Having worked with GoLang for a while where interfaces are not required to be explicitly named by classes that implement them I have learned that having consistency across unrelated projects can result in some surprisingly serendipitous reuse scenarios.

Unless you suggest we introduce enough magic methods that every method
name in your application begins with two underscores, you are always going
to have to name things.

Forgive me for saying, but that argument is bordering on reductio ad absurdum. We are talking about a magic method for converting to a built-in data type.

In PHP — ignoring null — there are only seven built-in data types, we already have a magic method for one of them (string), having one for resource makes no sense to me since it is such a special case, and so the only ones for which most instances of a declared class can be fully captured are array and object. IOW, two (2) potential magic methods: __toArray() and either __toObject() or __toStdClass().

That said, I could see a value in having __toInt(), __toFloat(), and __toBool() as having them would allow us to represent scalar data types in classes. That could be extremely useful in selected contexts.

So given the argument there would at maximum be five (5) new magic methods that could be added vs. the infinite methods you assert this approach would invite.

P.S. That said, I could see adding more for well-known data that goes beyond existing data types, e.g. JSON, XML, HTML, CSV, etc. but really if we did that I would argue that PHP should create a first-class built-in data type for them first.

If there is a common requirement for objects to be converted to a
particular type of array, then you should pick a standard name for that

You assert that a developer "should" do it the way you believe is correct, but what is the arbiter of "should" vs. "should not" here? Is there some fundamental best practice that the industry has universally embraced that I am unfamiliar with, or just your opinion?

(I am not trying to be sarcastic, but I am challenging you to justify your use of "should.")

I'm not asking for any kind of perfection, I'm just saying names should be
meaningful. Bear in mind that namespaces are really just part of the class
name, so all you're really saying is that you like long specific class
names and short generic method names.

Absolutely agree that names need to be meaningful, which is why I want more control, not less.

What you are implicitly saying is that rather than allow others the option to use __toArray() which by its nature could result in consistent use across unrelated projects you want to deny others who value it from being able to take advantage of it because you personally do not see value in it and would not use it. Or did I misrepresent?

Similarly it is not clear to me was toV5Json() or getV5Array() or
formatForJsonV5() mean.

I was imagining an API that had gone through different versions, so needed
methods to serialize objects into the JSON published in version 5 of a
specification.

Godforbid someone uses that kind of naming for their methods. Versioning screams out for encoding into namespace names, not method names. Why burden the developer with the requirement to use the version name in every single method call? Better to isolate it to use a use statement.

BUT, this is a tangent and a different debate from the discussion about __toArray().

If your code base is such a mess that you can't propose any method name
without it conflicting, and can't trace usages of any method that needs
renaming to not conflict, then yes, you get a one-off benefit from the fact
that __ is reserved. That seems a pretty poor justification for a language
feature.

I was not talking about my codebase, I was talking about the collective entirety of all existing PHP codebases.

So I now understand that you were proposing even less than I thought you were proposing. I thought you were proposing that PHP would recognize and give speaking meaning to a method called toArray() or similar. Now I realize you were proposing even less and instead placing the burden of said standardization on each project, guaranteeing no serendipitous reuse across projects. :-(

One huge benefit I haven't mentioned yet is the ability to add parameters.
Imagine if your mustache formatters are used in both plain text and HTML
contexts, and that affects some of the data to return.

When you have the need for parameters, by all means create a named method. But why block the use cases that do not need parameters? Why not simply let developers who find __toArray() useful be able to use them?

If you have a
Thinking about it, if you're only going to allow one method per class, with
the class's namespaced name telling you what it does, you might as well use
__invoke():

But it is reasonable to expect that a class could need both an __invoke() and a __toArray() method.

Also there is no guarantee that an object that implements __invoke() will return an array whereas there should be a reasonable guarantee that if function_exists($object,'__toArray') is true that casting to (array) would be valid.

You can only rely on __toArray if you standardise on every object
implementing it; at which point, you can standardise on any name you like.

But method name standardization does not work across unrelated projects. Because programmers.

Casting to (array) would work across unrelated projects.

People are quite happily using polymorphism with named methods in literally
millions of OO code bases.

https://en.wikipedia.org/wiki/Status_quo_bias https://en.wikipedia.org/wiki/Status_quo_bias

I'm not suggesting PHP standardises on some other name, just that your
code base standardises on common names for common tasks.

And therein is where your argument breaks down compared to the argument for __toArray(). It assumes each team's and/or project's codebase is an island.

Well, I started this sub-thread saying I was "sceptical" rather than
"strongly opposed". If the feature was added, I would simply ignore it, and
probably argue against its use in code review and style guides.

I think I have discovered another difference between you and I. When someone proposes a feature I can easily ignore, I do not write long emails arguing against it.

#justsaying :-)

However, other people have pointed out that unlike (string)$object,
(array)$object does have a default behaviour, and adding an overload for it
has the potential to break code relying on that. So it's not an entirely
zero-cost feature.

I do not see this as an issue because this BC break is entirely opt-in by the developer.

It is possible a library developer could add a __toArray() in a new version of a open-source library where one did not previously exist and thus break other's code that depended on the previous version of the library. That would be no different than if the library developer changed the behavior of one of their existing methods. So that would be one the library developer, not on PHP.

-Mike

5 years ago by Rowan Tommins — view source — reply

unread

Yes, a team lead could require an interface be used for consistency across
a team, which is fine, but it is not consistent across unrelated projects.
Having worked with GoLang for a while where interfaces are not required to
be explicitly named by classes that implement them I have learned that
having consistency across unrelated projects can result in some
surprisingly serendipitous reuse scenarios.

That's actually precisely why I don't like generic names like
__toArray(). How do I know looking at it whether this particular method
will give me something suitable for passing to a Mustache template, or just
a list of IDs used in some cross-referencing algorithm? The only thing I
know from the name is "it returns an array".

Forgive me for saying, but that argument is bordering on reductio
ad absurdum. We are talking about a magic method for converting to a
*built-in *data type.

...

That said, I could see a value in having __toInt(), __toFloat(), and
__toBool() as having them would allow us to represent scalar data types
in classes. That could be extremely useful in selected contexts.

So given the argument there would at maximum be five (5) new magic methods
that could be added vs. the infinite methods you assert this approach would
invite.

I didn't say it would invite infinite methods, I said it would only give
the claimed benefits if you had a huge number of magic / "standard"
methods, because you need to "standardise" every method you have in your
current code base.

__toBool() is perhaps a good comparison. Would you consider renaming a
method called "isSuccessful()" to "__toBool()" a positive change? Because I
would not.

If there is a common requirement for objects to be converted to a

particular type of array, then you should pick a standard name for that

You assert that a developer "should" do it the way you believe is
correct, but what is the arbiter of "should" vs. "should not" here?
Is there some fundamental best practice that the industry has universally
embraced that I am unfamiliar with, or just your opinion?

Are you saying that you don't believe consistency is a good thing?
Because that's all this sentence really says: "if you have something you do
a lot, you should do it in a consistent way".

The justification for that can be found in the introduction to any style
guide you can lay your hands on.

Absolutely agree that names need to be meaningful, which is why I want
more control, not less.

What you are implicitly saying is that rather than allow others the option
to use __toArray() which by its nature could result in consistent use
across unrelated projects you want to deny others who value it from being
able to take advantage of it because you personally do not see value in it
and would not use it. Or did I misrepresent?

I think you are misrepresenting slightly. I haven't actually said I want to
"deny" or "block" this addition. What I have said is that I am unconvinced
by the arguments being put forward in favour of it, and have tried to point
out what I see as flaws in those arguments.

In particular, if your claim is that it will make code more consistent
across code bases, it's no use if you're the only person that adopts it. So
let me rephrase from a personal objection to a prediction: I predict that
people will not use this feature consistently in a way that will bring the
benefits you claim for it.

So I now understand that you were proposing even less than I thought you
were proposing. I thought you were proposing that PHP would recognize and
give speaking meaning to a method called toArray() or similar. Now I
realize you were proposing even less and instead placing the burden of said
standardization on each project, guaranteeing no serendipitous reuse across
projects. :-(

There is certainly benefit to standardising things across projects, and
that's what organisations like PHP-FIG try to do. However, standardisation
is more useful the more specific it is, and if the definition of "toArray"
is just "it returns an array that in some way represents the object", I'm
struggling to see how that would lead to useful interoperability.

But it is reasonable to expect that a class could need both an __invoke()
and a __toArray() method.

It's also reasonable to expect that a class could need two methods that
return arrays; you've already "solved" that, by splitting the methods among
more classes and namespaces so they don't need unique names any more.

Also there is no guarantee that an object that implements __invoke() will
return an array whereas there should be a reasonable guarantee that if
function_exists($object,'__toArray') is true that casting to (array)
would be valid.

Which brings us back to square one: knowing that a method returns an array
isn't enough; I need to know what kind of array that is, and the thing that
normally tells me that is the method's name.

Regards,

Rowan Tommins
[IMSoP]

5 years ago by Rowan Tommins — view source — reply

unread

Should we make decisions about future language enhancements based on
conflicting and impossible to forecast predictions, or when a significant
subset of PHP developers see value in a feature for their use-cases and
others can simply ignore if they do not want to use it?

Neither. We should discuss the advantages of the feature, the potential
costs, and whether other features would be even better.

I challenge that assertion that having a huge number of magic or standard

methods is the "only" way this provides benefit.

Not the only way it can bring any benefit, but the only way it can bring
the particular benefit of eliminating the need to agree method names
across code bases.

I think that's where this conversation has broken down a bit, which may be
my fault: I wasn't intending to argue against all the possibilities of the
feature, only the specific arguments you were raising. We disagree over
whether (array)$foo would be used more consistently than meaningful method
names, so maybe we should leave that there, and look at some other pros and
cons of the feature.

Since conversion to array from object is a common need just this one
method could provide a similar level of benefit that __toString() already
provides.

What makes __toString() worthy of a special case in my mind is that there
are fairly common scenarios where variables are implicitly cast to
string: in double-quoted strings, echo, etc. Having the language be able to
automatically call a particular method in those situations is therefore
more valuable. I think I'd actually be more receptive to a proposal to
allow all casts to be overloaded, rather than adding array as a second
special case, because implicitly casting to array doesn't seem like it
would be any more common than other types.

Yes, if your class is named Transaction then isSuccessful() probably is
a better name than __toBool().

But if your class name itself is isSuccessful()?

Yes, I would see that as a better example. I think operator overloading in
general makes sense when the object itself can be thought of as a
special-case of the primitive it's emulating operators for. So in this
case, the IsSuccessful class would be "a special kind of boolean"; and the
hypothetical List or Collection classes I mentioned a couple of days ago
would be "a special kind of array". We even have that in PHP for built-in
types: GMP objects can now be used with mathematical operators like $foo *
$bar, and those operations do what you'd expect them to do on an integer or
float.

Operator overloading can also be used just as a cute way of spelling
something - probably most famously, C++ uses the << and >> operators for
writing to and reading from streams, even though they're actually overloads
of the bit-shift operator. This kind of use is, I would say, more
controversial - going back to consistency, it's easier to reason about code
if $foo * $bar always does some kind of multiplication than if it's been
overloaded to mean "$foo is the star of $bar".

Overloading of cast operators is no different - the clearest use cases for
__toString() are where the whole class basically represents a piece of
text, and the more controversial are where (string)$foo is actually a cute
spelling of one method on a complex class.

That's not necessarily a reason to not add a feature - any feature can be
abused - but it potentially makes it harder for users to understand each
other's code, and that's a cost we should at least consider.

Let me count the ways. Here are several examples:

https://gist.github.com/mikeschinkel/361bbcf44da1dac0da6afd786b6b8c3a

A great example of this is the AllowedHtml class I wrote for the above
gist whose sole purpose is to streamline the specification of allowed HTML
using to KSES library.

This is an interesting example. On the one hand, there is only one array
ever going to be produced by that class; but on the other hand, the
ultimate use of it is explicitly passing to a function that expects a
different type. Assuming the same behaviour as __toString, the code shown
would give an error under strict_types=1, and need changing to
wp_kses((array)$allowed_html)

A different interpretation would be that this is the Builder Pattern, and
the target type happens to be an array rather than an object. So you might
decide that the consistency you really needed is that all builders should
have a build() method, and the last line of the example would become:

$clean_html = wp_kses($_POST[ 'content' ] ?? null,
$allowed_html_builder->build());

That doesn't mean the version you wrote is wrong, but should make us
consider why one version deserves special treatment by the language and the
other one doesn't.

Regards,

Rowan Tommins
[IMSoP]

5 years ago by Mike Schinkel — view source — reply

unread

Neither. We should discuss the advantages of the feature, the potential
costs, and whether other features would be even better.

In concept, I agree.

But AFAIK no other "better" features were proposed. Do you have an alternate to propose for __toArray()? I am all ears.

I think that's where this conversation has broken down a bit, which may be
my fault: I wasn't intending to argue against all the possibilities of the
feature, only the specific arguments you were raising. We disagree over
whether (array)$foo would be used more consistently than meaningful method
names, so maybe we should leave that there, and look at some other pros and
cons of the feature.

I appreciate you elaborating.

We can certainly disagree; in both cases it is just our opinion for what might happen if a new feature is introduced, and neither of us can know for certain what the potential future holds.

That said, which I think you acknowledged, it is a bit of bikeshedding on both our parts to belabor this one point any longer.

What makes __toString() worthy of a special case in my mind is that there
are fairly common scenarios where variables are implicitly cast to
string: in double-quoted strings, echo, etc. Having the language be able to
automatically call a particular method in those situations is therefore
more valuable.

The same can be said for __toBool(), and could be said for any other data type assuming that the appropriate __toType() were available.

Said another way, if __toString() was not in PHP then no implicit casting would be possible and thus nobody would do it.

So there really is no difference; if we had __toArray() and __toBool(), people could start using them where they would be implicitly cast to those values.

I think I'd actually be more receptive to a proposal to
allow all casts to be overloaded, rather than adding array as a second
special case, because implicitly casting to array doesn't seem like it
would be any more common than other types.

The feels like "perfect being the enemy of the good" again.

If there is anything I have picked up by studying the nature of enhancements to PHP it is that they are added incrementally at best. Consider type hinting; we have basic type hinting today but we are just now getting union types. It would have been ideal to get all typing needs addressed at once, but if that had been the bar we probably would still be doing without.

Also consider that implementation of all casts would be a heavier lift than implementing just one today, and then hopefully implementing others later.

And consider that the nature of PHP with its voting means that larger changes are exponentially harder to get accepted.

So for me, rather than argue against a feature because we don't take all 10 steps at once, I would celebrate moving 1 step at a time in the positive direction, because we would at least be 1 step ahead of where we are today.

Yes, I would see that as a better example. I think operator overloading in
general makes sense when the object itself can be thought of as a
special-case of the primitive it's emulating operators for. So in this
case, the IsSuccessful class would be "a special kind of boolean"; and the
hypothetical List or Collection classes I mentioned a couple of days ago
would be "a special kind of array". We even have that in PHP for built-in
types: GMP objects can now be used with mathematical operators like $foo *
$bar, and those operations do what you'd expect them to do on an integer or
float.

Exactly! I agree that for general purpose classes the general array cast is less ideal.

But there would really be value in having "cast" magic methods to wrap built-in data types and then add related methods to them.

Operator overloading can also be used just as a cute way of spelling
something - probably most famously, C++ uses the << and >> operators for
writing to and reading from streams, even though they're actually overloads
of the bit-shift operator.

Interestingly, I am against general operator overloading, because Ruby and Rails.

Seriously, when operators can be overloaded you can end up with code that is almost impossible to decipher. But I do not think the same is true for casting as I tried to illustrate by example.

Overloading of cast operators is no different - the clearest use cases for
__toString() are where the whole class basically represents a piece of
text, and the more controversial are where (string)$foo is actually a cute
spelling of one method on a complex class.

I fully agree with that.

That's not necessarily a reason to not add a feature - any feature can be
abused - but it potentially makes it harder for users to understand each
other's code, and that's a cost we should at least consider.

I would like to err on the side of power combined with documentation and education rather than prohibition.

This is an interesting example. On the one hand, there is only one array
ever going to be produced by that class; but on the other hand, the
ultimate use of it is explicitly passing to a function that expects a
different type. Assuming the same behaviour as __toString, the code shown
would give an error under strict_types=1, and need changing to
wp_kses((array)$allowed_html)

You assume that my proposed __asArray() was not also implemented.

However — per the proposal — when __asArray() returns true PHP would treat the object as an array in any context where an array is expected but still allow methods to be called.

A different interpretation would be that this is the Builder Pattern, and
the target type happens to be an array rather than an object. So you might
decide that the consistency you really needed is that all builders should
have a build() method, and the last line of the example would become:

$clean_html = wp_kses($_POST[ 'content' ] ?? null,
$allowed_html_builder->build());

Totally.

But the primary use-case for __toArray() I have identified is to support patterns that exist in other peoples code — such as WordPress core — where you cannot easily rearchitect the code to be what a developer thinks they really need; you have to go with what is not what you want to be.

That doesn't mean the version you wrote is wrong, but should make us
consider why one version deserves special treatment by the language and the
other one doesn't.

What other version, and what special treatment is needed?

I think I am sensing a pattern in your objections: For you, providing benefits in one area is to be avoided unless all areas can receive similar benefits? And when providing all areas with similar benefits would mean infinite features, you would prefer that no use cases get improved at all, even if the areas proposed to be improved represent the ~80 percentile of use-cases?

Tell me if I am grasping your objections correctly?

-Mike

5 years ago by Rowan Tommins — view source — reply

unread

But AFAIK no other "better" features were proposed. Do you have an
alternate to propose for __toArray()? I am all ears.

It's hard to know without understanding the use cases, which is why I got
so hung up on your "consistency" argument - I wanted to understand what you
were trying to achieve, and if this was the best way to achieve it.

One thing you mentioned earlier was implicit interfaces, i.e. being able to
match "any object that has a foo() method" rather than "any object that
opted into the Fooable interface". You seemed to be saying that __toArray()
would bring similar advantages, but maybe if we had implicit interfaces,
those advantages would already be there? I may have completely
misunderstood, but that's just an example of the wider thinking I'm talking
about.

Said another way, if __toString() was not in PHP then no implicit casting
would be possible and thus nobody would do it.

Not quite. What I meant was that there are lots of places which implicitly
cast something to string, and would still do so if we didn't have
__toString(). For instance, it's common to use an integer in a
double-quoted string or echo statement, which will implicitly cast it to
string, so being able to use an object in the same place feels natural and
useful.

The feels like "perfect being the enemy of the good" again.

...

Also consider that implementation of all casts would be a heavier lift
than implementing just one today, and then hopefully implementing others
later.

Possibly, but it's also about how we prioritise features. If the general
plan is "eventually we hope to have overloads for all casts, but let's do
them one at a time", we should have some reason why array comes next. My
gut feel is that implicit casts to boolean (e.g. in if statements) are the
next most common after strings, so if asked to prioritise, I would pick
that over arrays.

There's also a kind of "tipping point" where splitting up the feature no
longer makes sense - it would be weird to have __toString, __toArray, and
__toBool; then add __toInt; then wait a release to add __toFloat. So I
guess my suggestion is that maybe we've already reached that tipping point,
and rather than bikeshedding the order to add things in, we should go ahead
and add them all.

But maybe there is a reason that __toArray() is easier / less dangerous /
more useful than the rest.

Seriously, when operators can be overloaded you can end up with code that
is almost impossible to decipher. But I do not think the same is true for
casting as I tried to illustrate by example.

I guess this is where I'm less optimistic; I think overloaded casts could
be just as unreadable as any other overloaded operator if abused - and just
as powerful if used appropriately.

I'd actually really love to be able to write $price = new Money('GBP', 100,

- new Money('GBP', 50, 50);

I would like to err on the side of power combined with documentation and
education rather than prohibition.

Just to play devil's advocate, the same reasoning could be used to dismiss
your dislike of full operator overloading.

You assume that my proposed __asArray() was not also implemented.

However — per the proposal — when __asArray() returns true PHP would
treat the object as an array in any context where an array is expected but
still allow methods to be called.

OK, I'd completely missed that proposal. It's an interesting idea, but it
feels like there are some rough edges: why would you implement the function
but return false, and how would that behave? And what if it returned true
but there was no __toArray? Also, would the function actually receive the
object, or the result of calling __toArray() on it? Would it be different
in strict_types mode?

In keeping with the idea of one feature at a time, it would probably make
sense to work out the details of that mechanism for strings first, since we
already have __toString(), then extend both parts to arrays at the same
time.

$allowed_html_builder->build());

But the primary use-case for __toArray() I have identified is to support
patterns that exist in other peoples code — such as WordPress core — where
you cannot easily rearchitect the code to be what a developer thinks they
really need; you have to go with what is not what you want to be.

My example requires exactly the same interaction with the third-party code
as your example - create a custom object, and call some methods on it. If
the __toArray() call is completely automatic, then your example saves the 9
characters of "->build()", but it doesn't change the architecture of the
solution.

That doesn't mean the version you wrote is wrong, but should make us
consider why one version deserves special treatment by the language and
the
other one doesn't.

What other version, and what special treatment is needed?

The version using "$foo->build()" rather than "(array)$foo", and the
special treatment of "(array)$foo" actually calling "$foo->__toArray()".

I think I am sensing a pattern in your objections: For you, providing
benefits in one area is to be avoided unless all areas can receive similar
benefits?

Almost. It's more that I'm against adding a large number of small features
that each make one use case slightly easier, but don't generalise very well.

... even if the areas proposed to be improved represent the ~80
percentile of use-cases?

Quite the opposite! I'm sceptical of this feature precisely because I think
the use cases for it are rather narrow.

Regards,

Rowan Tommins
[IMSoP]

5 years ago by Larry Garfield — view source — reply

unread

Yes, I would see that as a better example. I think operator overloading in
general makes sense when the object itself can be thought of as a
special-case of the primitive it's emulating operators for. So in this
case, the IsSuccessful class would be "a special kind of boolean"; and the
hypothetical List or Collection classes I mentioned a couple of days ago
would be "a special kind of array". We even have that in PHP for built-in
types: GMP objects can now be used with mathematical operators like $foo *
$bar, and those operations do what you'd expect them to do on an integer or
float.

Operator overloading can also be used just as a cute way of spelling
something - probably most famously, C++ uses the << and >> operators for
writing to and reading from streams, even though they're actually overloads
of the bit-shift operator. This kind of use is, I would say, more
controversial - going back to consistency, it's easier to reason about code
if $foo * $bar always does some kind of multiplication than if it's been
overloaded to mean "$foo is the star of $bar".

Overloading of cast operators is no different - the clearest use cases for
__toString() are where the whole class basically represents a piece of
text, and the more controversial are where (string)$foo is actually a cute
spelling of one method on a complex class.

I just want to pop in here to highlight this last point, because that's the best heuristic I've seen for when __toString() is appropriate or not. I may have to steal that heuristic because it's spot on.

To the rest of the thread, I think it's wise to split discussion of __toArray() off from "arrayable". They seem like they are addressing different if related problems. While an object with __toArray() would be "arrayable", there's already 2 array-ish things: arrays and the ArrayAccess interface. So some short hand for array|\ArrayAccess can stand on its own as a proposal.

Or, since we now have union types, maybe that makes such a shorthand no longer necessary. I'm not sure there.

--Larry Garfield