Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.php > #3854

Re: return types

Show all headers | View raw

On Thu, 31 Mar 2016 21:40:04 Thomas 'PointedEars' Lahn wrote:
> > class Foo {
> >         public function cloneMe() : Foo {
> >                 return clone $this;
> >         }
> > }
> > 
> > 
> > class Foo_Child extends Foo {
> >         public function cloneMe() : Foo_Child {
> >                 return clone $this;
> >         }
> > }
> > ?>
> > #v-
> > 
> > führt zu:
> > 
> > | PHP Fatal error:  Declaration of Foo_Child::cloneMe(): Foo_Child must be
> > | compatible with Foo::cloneMe(): Foo in /home/sfroehli/test.php on line
> > | 13

> > Dass die Signaturen kompatibel sein müssen ist klar,

> Ich finde auch das zu eng gedacht.

Stimmt, *müssen* tun sie es nicht. Allerdings:

> Wenn ich eine Methode überschreiben kann, sollte ich das auf beliebige
> Art tun können. Polymorphismus impliziert nicht, dass Gleichbenanntes
> auch gleich funktionieren muss; denn ich kann die Klasse eines Objekts
> ermitteln und die polymorphe Methode so aufrufen, wie es für die
> jeweilige Klasse korrekt ist.

Ich persönlich möchte, wenn ich lese:

#v+
abstract class Foo {
	public function bar(int $b) : int;
}
#v-

...auch *garantiert* das folgende fehlerfrei tun können:

#v+
if ($f instanceof Foo) $b2 = $f->bar($b1);
#v-

...und nicht womöglich daran scheitern, dass die abgeleitete Klasse
Foo_Bar die Methode womöglich ganz anders definiert hat.

Das geht aber nur dann, wenn mir nicht jemand die Signatur dieser
Methode unter dem Hintern wegziehen kann. Allerdings würde ich mir
gelegentlich das wünschen, was ich bei C++ so geschätzt habe, z.B.:

#v+
abstract class Foo {
	public function bar(Array $a) : int;
	public function bar(Collection $c) : int;
}
#v-

Es geht allerdings - wenn überhaupt - nur eines von beiden: Entweder
überschreiben Methoden diejenigen ihrer Elternklasse unabhängig von
den verwendeten Parametern, oder halt nicht.

> > aber eine *Einschränkung* des return types in einer abgeleiteten
> > Klasse ist doch vollkommen unproblematisch; [...]

> ACK.  Darüberhinaus sehe ich nicht einmal die Notwendigkeit, dass
> die Rückgabetypen polymorpher Methoden in einer
> klassenhierarchischen Beziehung zueinander stehen.  Wenn zum
> Beispiel eine abgeleitete Klasse eine gleichnamige Eigenschaft
> hat, in der ein Wert mit einem anderen Typ gespeichert ist als in
> einer übergeordneten Klasse und ein Getter dafür existiert, so ist
> es nicht einzusehen, dass der Getter nicht gleich heissen 
> darf *und* einen anderen Rückgabetyp hat als den, welchen der so 
> überschriebene Getter hat.

Das sehe ich - aus dem gleichen Grund wie oben - nun wiederum
anders. Wäre so etwas zulässig, könnte man sich nicht mehr auf die
Signaturen gemeinsamer Elternklassen verlassen, und gerade das finde
ich sehr hilfreich.

So, wie es derzeit implementiert ist, ist das aber jedenfalls
halbgar und hilft weder Dir noch mir weiter.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan: die Lust zu lieben!
(Sloganizer)

Back to de.comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-03-31 09:35 +0000
  Re: return types k@rl.pflaesterer.de (Karl Pflästerer) - 2016-03-31 12:42 +0200
  Re: return types "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-03-31 14:16 +0200
    Re: return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-04-15 06:37 +0000
    Re: return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-06-22 08:48 +0000
      Re: return types "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-22 12:25 +0200
        Re: return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-06-22 14:49 +0000
          Re: return types "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-22 17:47 +0200
            Re: return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-06-23 08:23 +0000
              Re: return types "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-07-02 01:03 +0200
  Re: return types Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-31 21:40 +0200
    Re: return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-04-01 16:26 +0000
      Re: return types "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-04-02 19:23 +0200
        Re: return types Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-02 20:36 +0200
        Re: return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-04-11 21:18 +0000
      Re: return types Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-02 20:33 +0200
        Re: return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-04-11 21:32 +0000
          Re: return types Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-19 20:24 +0200
            Re: return types Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-04-20 07:05 +0000
              Re: return types Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-21 02:55 +0200

csiph-web