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

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

Re: return types

Show all headers | View raw

Stefan Froehlich schrieb:

> 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.

Da geht es Dir genau wie Barbara Liskov, die daher das nach ihr benannte
Substitutionsprinzip formuliert hat. Und mir geht es auch so. :)

> 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-

Das ist allerdings keine dynamische Polymorphie, sondern Überladung
(overloading), und hat, streng genommen, nichts mit Objektorientierung
zu tun. Eine solche Überladung ist wohl bei dynamischen Sprachen eher
ungewöhnlich, weil sie nicht einfach zu implementieren ist (ganz im Ggs.
zu statisch kompilierten Sprachen).

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

Rückgabetyp-Invarianz bzgl. der Funktions-Definition ist aber doch (noch
immer) ziemlich verbreitet, oder? Kovarianz wäre natürlich
wünschenswert, erfordert aber zumindest, dass die Rückgabetypen zur
Kompilationszeit bereits bekannt sind, was u.U. gar nicht so einfach zu
lösen ist. Derzeit ist das PHP jedenfalls nicht nötig. Der folgende Code
wird anstandslos akzeptiert:

  class Foo
  {
      function bar(): Baz {}
  }

-- 
Christoph M. Becker

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