Re: [ZEND-ENGINE-CVS] interfaces

OK thx. At 12:35 AM 6/7/2006, Marcus Boerger wrote:

Hello Andi, as far as i can tell it works. At least all my code works as well as all the tests. If i remember correctly the outside reallocation was some kind of ptimization. But anyway it must be compatible becuase if we end up in implementing an interface that extends one or more interfaces we call zend_do_inherit_interfaces() which itself does reallocation. But it should be possible to drop the preallocation and initialization to zero. As soon as i figured that part out i can commit - i have one problem though in head, some valid interface code doesn't work there, so i first have to figure out what's wrong in head. best regards marcus Wednesday, June 7, 2006, 5:27:42 AM, you wrote: Hi Marcus, Looks like a good change to me. I think we can live with it not catching that edge case (for which the developer should be shot anyway :) especially as it does only keep the iface once so no biggy. A couple of things re: the patch: a) I see zend_do_implement_interface() is exported. Is the behavior of this function changing in a BC incompatible way? I'm asking mainly because of the new emalloc/erealloc in there which used to be outside. Not sure if it actually affects BC though. b) I prefer changing p_if_num and o_if_num to be more similar to our naming conventions. p_if_num -> parent_iface_num, and o_if_num to current_iface_num (OK not sure about current. Maybe you have a better one :) Looks great! Thanks. Andi At 03:31 PM 6/6/2006, Marcus Boerger wrote:

Hello Andi, hello again on the same matters. I did another patch (against 5.2) which is a bit better. It drops multiple interfaces from the interface list so that reflection nolonger generates wrong output and maybe even prevents from other problems. Now what the patch does: 1) (invalid) interface U {} class X implements U, U {} => error, before U was inherited twice 2) (actually used in SPL) interface U {} class X implements U {} class Y extends X implements U {} => U is inherited only once, no error, before U was inherited twice 3) (in theory wrong) interface U {} class X implements U {} class Y extends X implements U, U {} => U is inherited only once, no error, this is where the patch

     fails, well it is not pedantic, Aontony and myself checked
     it and it seems impossible to catch these without API change.

4) (actually used in SPL) interface U {} interface V extends U {} interface W extends U {} class X implements V, W {} class Y implements U, V, W {} => both classes implement U only once, no error

     before U was inherited multiple times

So besides that the patch is not pedantic but it fixes all issues. What do you guys think? best regards marcus Tuesday, June 6, 2006, 5:54:41 PM, you wrote:

That's what I thought. Thanks Stas for checking it out. Antony, it's ok if you warn if there are two on the same line e.g. implements foo, foo but if the interface is inherited we shouldn't prevent that.

Andi

At 08:43 AM 6/6/2006, Stanislav Malyshev wrote:

About interfaces and doble interfacing prohibition patch - Java

allows this:

class A implements Serializable { } class B extends A implements Serializable {