Hi,
I've thought twice about making classes final. The return type issue can be solved by specifying static, but as Barney mentioned, there is a problem with operator overloading, for example addition, where the class of the resulting object changes if the left and right operands are swapped. In other words, if that problem can be solved, it may be possible to make a class inheritable without making it final. The only solution I can think of at the moment is to impose the constraint that when computing operator overloading, if the operands are both objects, they must be of the exact same class. When calculating using a method, it is clear which object should be prioritized, so there is no risk of breaking down even if the method accepts objects of different classes as arguments. It would be possible to unify the behavior of the methods with operator overloading, but this would be undesirable because the arguments would be contravariant. I think my idea is somewhat better than using final classes in terms of freedom for the user. Whether it's a good API or not may require some further discussion. However, I think it is unlikely that a user will misunderstand and introduce a bug into their code because an error will occur before it will act as a bug. Alternatively, a user may misunderstand that a method can only receive objects of the same class as an argument, but this only restricts the degree of freedom and does not create a bug in itself. The only concern is that when do a calculation like `$numChild->add($num)`, users might misunderstand that it returns the class of the argument object. I'm a bit unsure if this could be a solution as there may still be something I've overlooked. Regards. Saki |
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Jordan LeDoux
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Barney Laurance
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Barney Laurance
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Tim Düsterhus
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Tim Düsterhus
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Barney Laurance
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Jordan LeDoux
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Tim Düsterhus
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Jordan LeDoux
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Rowan Tommins [IMSoP]
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Tim Düsterhus
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Rowan Tommins [IMSoP]
- Re: [PHP-DEV] [RFC] [Discussion] Support object type... Saki Takamachi