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

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

Re: return types

Show all headers | View raw

On Sat, 02 Apr 2016 20:33:35 Thomas 'PointedEars' Lahn wrote:
> > 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.
 
> ACK.  “instanceof” überprüft aber _nicht_, ob ein Objekt eine
> Instanz einer bestimmten Klasse ist.  Ich meinte deshalb
> get_class().

Ok, hatte ich falsch verstanden. Trotzdem: Dazu müsste ich mich dann
für obiges $b2 = $f->bar($b1) mit allen möglichen Klassen von $f
auseinandersetzen, was - je nach Anwendungsfall - durchaus komplex
werden könnte.

($f instanceof Foo) hat für mich gerade den Charme, das nicht tun zu
müssen. Sehr oft ist Foo eine abstrakte Basisklasse, und ich weiss
bei der Verwendung ihrer Methoden überhaupt nicht, mit welchen
konkreten Objekten und Klassen ich es später einmal zu tun haben
werde - ich weiss aber, dass sie alle von Foo abgeleitet sind.
Dementsprechend nett ist es, wenn ich mich darauf verlassen kann,
dass die Methoden auf Foo unverändert zur Verfügung stehen.
 
> > #v+
> > abstract class Foo {
> > public function bar(Array $a) : int;
> > public function bar(Collection $c) : int;
> > }
> > #v-
 
>   public function bar (ArrayAccess $c) : int
>   {
>     if (!($c instanceof ArrayObject || $c instanceof Collection))
>     {
>       throw new \InvalidArgumentException('ArrayObject or Collection 
> expected.');
>     }
>   }
 
> wenn man davon ausgeht, dass sowohl ArrayObject als auch
> Collection das ArrayAccess-Interface implementieren, ohne
> voneinander abgeleitet zu sein.

So mache ich das heute, eleganter fände ich allerdings den C++
Ansatz.
 
> Was nicht zum Ziel führt, ist
> 
>   public function bar (object $c) : int
>   {
>     /* … */
>   }

> denn es gibt keine Klasse “object”;

Die fehlt mir momentan eben so, wie eine Klasse "scalar" als
Überbegriff für int, float, string und bool, ja.




Nicht direkt mit return types, aber mit dem artverwandten
strict_types zu tun hat folgende Kuriosität: Ableiten einer
benutzerspezifischen Exception-Klasse, bei der die Fehlercodes
so, wie bei der nativen Klasse, optional sein sollen:

#v+
declare(strict_types=1);

class Exception_Foo extends Exception {
	public function __construct($message, $code=NULL) {
		[some magic]
		parent::__construct($message, $code);
	}
}

throw new Exception_foo('Test');
#v-

Tja, *so* geht das jedenfalls nicht. Mit Defaultwert 0 kommt man
weiter, erreicht aber nicht das, was eigentlich angestrebt worden
ist.

Da braucht es wohl noch ein paar Nachbesserungen.

Servus,
   Stefan

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

Stefan: ein starker Partner!
(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