Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108792
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <77CBA006-9B5C-4671-BA93-153A50206F65@newclarity.net>
Date: Fri, 28 Feb 2020 14:59:23 -0500
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <187930AC-002C-413D-AB50-A2F2EF4007BE@newclarity.net>
References: <CAF+90c9UZbpMM22YVywD9RGP_PBMv=AFDfMa8+BgJr=-f_he2Q@mail.gmail.com>
 <77CBA006-9B5C-4671-BA93-153A50206F65@newclarity.net>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] SimpleXMLIterator
From: mike@newclarity.net (Mike Schinkel)

Well, that did not work as intended...


> On Feb 28, 2020, at 2:57 PM, Mike Schinkel <mike@newclarity.net> =
wrote:
>=20
> OFFLIST=20
>=20
> First one want to say but thanks and kudos for all you are doing for =
PHP.
>=20
> 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.
>=20
> 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.
>=20
> Note my thoughts here are very much influenced by Uncle Bob's blog =
post "'Interface' Considered Harmful": =20
>=20
> 	=E2=80=A2 =
https://blog.cleancoder.com/uncle-bob/2015/01/08/InterfaceConsideredHarmfu=
l.html
>=20
> My questions are: =20
>=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}")
>=20
> 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}")
>=20
> 3. Lastly, ignoring all the above, is there a technical reason we =
would not be able to allow:
> 	=E2=80=A2 Interfaces to declare static methods?
> 	=E2=80=A2 Traits to implement constants?
> 	=E2=80=A2 Interfaces to declare constants?
>=20
> Thank you in advance for taking the time to read, consider and reply.
>=20
> -Mike
>=20
> P.S. Did you see/read this which I linked to one of your Github =
tickets: =20
>=20
> 	=E2=80=A2 https://mikeschinkel.me/2020/adding-delegation-to-php/
>=20
> Any thoughts or feedback?
>=20
>=20
>=20
>> 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
>=20