Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108791
Message-ID: <77CBA006-9B5C-4671-BA93-153A50206F65@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_98ED74F4-EC8B-4093-AF29-9DA11FC5B97F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 28 Feb 2020 14:57:11 -0500
In-Reply-To: <CAF+90c9UZbpMM22YVywD9RGP_PBMv=AFDfMa8+BgJr=-f_he2Q@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Nikita Popov <nikita.ppv@gmail.com>
References: <CAF+90c9UZbpMM22YVywD9RGP_PBMv=AFDfMa8+BgJr=-f_he2Q@mail.gmail.com>
Subject: Re: [PHP-DEV] SimpleXMLIterator
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_98ED74F4-EC8B-4093-AF29-9DA11FC5B97F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

OFFLIST=20

First one want to say but thanks and kudos for all you are doing for =
PHP.

Second, and so as not to hijack your thread or worse start a whole bike =
shedding debate on the list, I have been wanted to ask you some =
questions and I saw this as a good segue to ask your thoughts on traits =
vs. interfaces vs. extends.

Simply put I have found that to use a same-named trait+interface I can =
effectively achieve multiple inheritance, which is what it sounds like =
would help the scenario you have below.  If we had multiple inheritance =
we could see much more fine-grain classes to inherit from (my =
traits+interfaces are fine grained) and that could make these kind of =
issues easier to deal with.

Note my thoughts here are very much influenced by Uncle Bob's blog post =
"'Interface' Considered Harmful": =20

=
https://blog.cleancoder.com/uncle-bob/2015/01/08/InterfaceConsideredHarmfu=
l.html

My questions are: =20

1. Internally in PHP, how different are traits implemented than classes, =
and ignoring what anyone's opinion would be on if we should do it, how =
technically feasible would it be to be able to "use {class_name}" in =
addition to the current "use {trait_name}?"  (Or better yet "use class =
{class_name}")

2. Additionally, a class with only abstract methods is effectively an =
interface.  How technically feasible would it be to be able to =
"implements {class_name}" in addition to the current "implements =
{interface_name}?"   (Or better yet "implements class {class_name}")

3. Lastly, ignoring all the above, is there a technical reason we would =
not be able to allow:
Interfaces to declare static methods?
Traits to implement constants?
Interfaces to declare constants?

Thank you in advance for taking the time to read, consider and reply.

-Mike

P.S. Did you see/read this which I linked to one of your Github tickets: =
=20

https://mikeschinkel.me/2020/adding-delegation-to-php/

Any thoughts or feedback?



> On Feb 28, 2020, at 5:59 AM, Nikita Popov <nikita.ppv@gmail.com> =
wrote:
>=20
> Hi internals,
>=20
> I'm currently trying to make sure that all internal Traversable =
classes
> implement either Iterator or IteratorAggregate. This is a hard =
requirement
> for userland classes, but internal classes can get away with =
implementing
> only the internal get_iterator() mechanism. (
> https://github.com/php/php-src/pull/5216)
>=20
> One problem I ran into along the way is the SimpleXMLIterator class. A
> naive person might think that there is some sanity left in this world, =
and
> the hierarchy for SXE/SXI looks like this:
>=20
>    SimpleXMLElement implements IteratorAggregate
>    // where SimpleXMLElement::getIterator() returns:
>    SimpleXMLIterator implements Iterator
>=20
> Of course, they would be wrong. The actual hierarchy is this:
>=20
>    SimpleXMLElement implements Traversable
>    SimpleXMLIterator extends SimpleXMLElement implements Iterator
>=20
> The fact that SimpleXMLIterator extends SimpleXMLElement leaves me in =
a
> tough spot, because it means SimpleXMLElement cannot be an
> IteratorAggregate -- that would mean that SimpleXMLIterator implements =
both
> IteratorAggregate and Iterator, which is not permissible.
>=20
> It seems that it's also not possible to remove the "extends" without a
> non-trivial backwards-compatibility break, because apparently writing
> simplexml_load_string($str, 'SimpleXMLIterator') is a thing, which =
requires
> SimpleXMLIterator to extend SimpleXMLElement (and possibly is the =
reason
> why this was done in the first place.)
>=20
> The only way out I see here is to lift the methods from =
SimpleXMLIterator
> into SimpleXMLElement, make SimpleXMLElement implement Iterator =
itself, and
> basically leave SimpleXMLIterator as a dummy extension of =
SimpleXMLElement.
>=20
> Does that sound "reasonable"? Or rather, is there something more =
reasonable
> that can be done?
>=20
> Regards,
> Nikita


--Apple-Mail=_98ED74F4-EC8B-4093-AF29-9DA11FC5B97F--