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

Groups > de.comp.lang.php > #3843 > unrolled thread

return types

Back to article view | Back to de.comp.lang.php

Contents

  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

#3843 — return types

Ich habe mich jetzt einmal ein wenig mit return types herumgespielt, weil
ich mir davon ein bisschen an zusätzlicher Kontrolle verspreche. Zum einen
erfüllt sich das (noch) nicht, weil sicherlich die Hälfte meiner Methoden
alternativ auch NULL zurückgeben kann, was momentan nicht unterstützt wird.

Zum anderen aber:

#v+
<?php

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

Man möge mir die eher sinnfreie Methode verzeichen, aber - ist das nicht
ein bisschen zu eng gedacht? Dass die Signaturen kompatibel sein müssen ist
klar, aber eine *Einschränkung* des return types in einer abgeleiteten
Klasse ist doch vollkommen unproblematisch; das bedeutet ja nichts weiter,
als dass von allen zulässigen Foos nur diejenigen in Frage kommen, die
zufällig auch Foo_Childs sind (und das wiederum taucht in Objekthierarchien
an jeder zweiten Ecke in der einen oder anderen Form auf).

Sollte man das als Bug melden, oder hat das am Ende sogar einen tieferen
Sinn, den ich bloss nicht sehe?

Servus, 
   Stefan

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

Stefan. Hastig und spannend!
(Sloganizer)

[toc] | [next] | [standalone]

#3845

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> Ich habe mich jetzt einmal ein wenig mit return types herumgespielt, weil
> ich mir davon ein bisschen an zusätzlicher Kontrolle verspreche. Zum einen
> erfüllt sich das (noch) nicht, weil sicherlich die Hälfte meiner Methoden
> alternativ auch NULL zurückgeben kann, was momentan nicht unterstützt wird.
>
> Zum anderen aber:
>
>
> #v+
> <?php
>
> 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
>
> Man möge mir die eher sinnfreie Methode verzeichen, aber - ist das nicht
> ein bisschen zu eng gedacht? Dass die Signaturen kompatibel sein müssen ist
> klar, aber eine *Einschränkung* des return types in einer abgeleiteten
> Klasse ist doch vollkommen unproblematisch; das bedeutet ja nichts weiter,
> als dass von allen zulässigen Foos nur diejenigen in Frage kommen, die
> zufällig auch Foo_Childs sind (und das wiederum taucht in Objekthierarchien
> an jeder zweiten Ecke in der einen oder anderen Form auf).
>
> Sollte man das als Bug melden, oder hat das am Ende sogar einen tieferen
> Sinn, den ich bloss nicht sehe?


Laut RFC gibt es momentan nur invariante Rückgabetypen.

https://wiki.php.net/rfc/return_types#variance_and_signature_validation

 KP

[toc] | [prev] | [next] | [standalone]

#3846

Stefan Froehlich schrieb:

> Ich habe mich jetzt einmal ein wenig mit return types herumgespielt, weil
> ich mir davon ein bisschen an zusätzlicher Kontrolle verspreche. Zum einen
> erfüllt sich das (noch) nicht, weil sicherlich die Hälfte meiner Methoden
> alternativ auch NULL zurückgeben kann, was momentan nicht unterstützt wird.

Das Thema wird seit einer Weile viel diskutiert (u.a. bzgl. der "Typed
Properties"[1]); eine mögliche Lösung wären "Union Types"[2], eine
andere "Nullable Types" wie von Hack unterstützt[3].

[1] <https://wiki.php.net/rfc/typed-properties>
[2] <https://wiki.php.net/rfc/union_types>
[3] <https://docs.hhvm.com/hack/types/type-system#nullable>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3879

On Thu, 31 Mar 2016 14:16:24 Christoph M. Becker wrote:
> Das Thema wird seit einer Weile viel diskutiert (u.a. bzgl. der "Typed
> Properties"[1]); eine mögliche Lösung wären "Union Types"[2], eine
> andere "Nullable Types" wie von Hack unterstützt[3].
 
> [1] <https://wiki.php.net/rfc/typed-properties>
> [2] <https://wiki.php.net/rfc/union_types>
> [3] <https://docs.hhvm.com/hack/types/type-system#nullable>

Ich verfolge die RFCs in unregelmäßigen Abständen, und die Nullable
Types <https://wiki.php.net/rfc/nullable_types> sind mir dabei schon
untergekommen, die Union Types, hatte ich noch nicht entdeckt.

Rein persönlich gefallen mir die Union Types *deutlich* besser,
schon rein von der Lesbarkeit her, aber gerade auch wegen
"Array|Traversable", was eigentlich geradezu ein klassischer
Anwendungsfall ist, "string|ToString" wäre ein weiterer.

Ich habe mir jetzt einmal ein paar Postings aus den aktuellen
Diskussionen durchgelesen. Die Meinungsbildung dauert wohl noch...

Servus,
   Stefan

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

Das zarte Sehnen, oder warum Stefan so arm knutscht!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3917

On Thu, 31 Mar 2016 14:16:24 Christoph M. Becker wrote:
> > [...], weil sicherlich die Hälfte meiner Methoden alternativ auch NULL
> > zurückgeben kann, was momentan nicht unterstützt wird.
 
> Das Thema wird seit einer Weile viel diskutiert (u.a. bzgl. der "Typed
> Properties"[1]); eine mögliche Lösung wären "Union Types"[2], eine
> andere "Nullable Types" wie von Hack unterstützt[3].

Die nullable types werden wir ja zum Glück demnächst bekommen, bei den
union types und den typed properties sieht es aber leider ganz und gar
nicht so aus :-(

Servus,
   Stefan

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

Die Spannung zu fühlen! Stefan, für die Beichte danach!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3918

Am 22.06.2016 um 10:48 schrieb Stefan Froehlich:

> On Thu, 31 Mar 2016 14:16:24 Christoph M. Becker wrote:
>>> [...], weil sicherlich die Hälfte meiner Methoden alternativ auch NULL
>>> zurückgeben kann, was momentan nicht unterstützt wird.
>  
>> Das Thema wird seit einer Weile viel diskutiert (u.a. bzgl. der "Typed
>> Properties"[1]); eine mögliche Lösung wären "Union Types"[2], eine
>> andere "Nullable Types" wie von Hack unterstützt[3].
> 
> Die nullable types werden wir ja zum Glück demnächst bekommen, bei den
> union types und den typed properties sieht es aber leider ganz und gar
> nicht so aus :-(

Ich finde die typed Properties nicht verkehrt, aber zum einen fände ich
die diversen Einschränkungen (geht nicht für globale, lokale und
statische Variablen, Referenzen) und den Performance-Nachteil nicht so
schön. Zum anderen aber löst es nicht das eigentliche Problem einer
stabilen und typsicheren API[1]. Da will ich im Zweifel eben keine
öffentlichen (oder geschützten) Eigenschaften anbieten, sondern ein
abstrakteres Konzept, bei dem ich bei Bedarf einhaken kann (und sei es
nur für eine Deprecated-Notice). Mit __get() und __set() kann man das
zwar notfalls tun, aber mir erscheint das nur ein Workaround. Was ich
mir da eher wünschen würde, wären Property-Accessors
(<https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented>).

Die Union-Types fände ich in einer statisch typisierten Sprache ja noch
ganz sinnvoll, aber bei PHP sehe ich da keinerlei Notwendigkeit, da man
dort solche Ausnahmefälle eben nicht typisieren muss. Und Ausnahmefälle
sollten es meiner Meinung nach bleiben, sonst wird es zu verwirrend. Die
aufgezeigten Beispiele haben mich jedenfalls nicht überzeugen können,
dass PHP allgemeine Union-Types haben sollte.

[1] Die Klassen-interne Typsicherheit finde ich sekundär. Gerade kleine
Klassen sollten überschaubar sein.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3919

On Wed, 22 Jun 2016 12:25:53 Christoph M. Becker wrote:
> Ich finde die typed Properties nicht verkehrt, aber zum einen fände ich
> die diversen Einschränkungen (geht nicht für globale, lokale und
> statische Variablen, Referenzen) und den Performance-Nachteil nicht so
> schön.

Performance-Nachteile sind nie schön, aber wenn ich den RFC richtig
verstanden habe, sind die eher theoretischer Natur - und ob man in einem
zweiten Schritt nicht Code effizienter gestalten könnte (weil Typen schon
vorab bekannt sind) wäre auch noch zu klären.

> [1] Die Klassen-interne Typsicherheit finde ich sekundär. Gerade
> kleine Klassen sollten überschaubar sein.

Mir gefiele daran halt die Möglichkeit, mich selbst wieder ein Stück
mehr kontrollieren zu können. Und ganz egal, wie klein und
überschaubar die Klasse ist, ist alles willkommen, was dazu
beiträgt, Fehler zu erkennen.

> Was ich mir da eher wünschen würde, wären Property-Accessors
> (<https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented>).

Das wiederum kann ich mir allenfalls in homöopathischen Ausnahmefällen als
(für mich) nutzbringend vorstellen - und wenn es nur darum geht, den Typ
einer Property festzulegen, ist der Aufwand erheblich.

Anstatt

| public int $i;

wäre das dann

| public $i {
|	get;
|	set(int $i) { $this->i = $i; }
| }

Bei Objekten mit vielen Properties ginge damit die Übersichtlichkeit
völlig verloren.
 
> Die Union-Types fände ich in einer statisch typisierten Sprache ja
> noch ganz sinnvoll, aber bei PHP sehe ich da keinerlei
> Notwendigkeit, da man dort solche Ausnahmefälle eben nicht
> typisieren muss. Und Ausnahmefälle sollten es meiner Meinung nach
> bleiben, sonst wird es zu verwirrend.

Gerade das erwähnte Array|Collection kommt bei mir eigentlich an
allen Ecken und Enden vor und unterläuft damit die sonst inzwischen
schon halbwegs durchgängige Typsicherheit.

Andere Fälle sind seltener, ja. Aber wie bei so vielen Dingen: Wenn
es eh kaum vorkommt, wird es auch kaum verwendet, stört also nicht
(und dort, wo man es braucht, hilft es).

Servus,
   Stefan

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

Stefan. Für imponierende Umfaller, wenn sie zwei linke Hände haben!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3920

Am 22.06.2016 um 16:49 schrieb Stefan Froehlich:

> On Wed, 22 Jun 2016 12:25:53 Christoph M. Becker wrote:
>
>> Was ich mir da eher wünschen würde, wären Property-Accessors
>> (<https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented>).
> 
> Das wiederum kann ich mir allenfalls in homöopathischen Ausnahmefällen als
> (für mich) nutzbringend vorstellen - und wenn es nur darum geht, den Typ
> einer Property festzulegen, ist der Aufwand erheblich.

Ja, stimmt schon. Aber ich definere eben ungern eine public property,
denn wenn ich die Implementierung ändern wollte, dann habe ich mich an
die Wand gefahren: geht nicht sauber ohne BC-Break. Da stelle ich lieber
einen Getter zur Verfügung, und das ist noch aufwendiger und
unübersichtlicher als die Property-Syntax, und auch noch langsamer für
den Fall, dass es wirklich nur ein einfacher Attributs-Getter ist.

>> Die Union-Types fände ich in einer statisch typisierten Sprache ja
>> noch ganz sinnvoll, aber bei PHP sehe ich da keinerlei
>> Notwendigkeit, da man dort solche Ausnahmefälle eben nicht
>> typisieren muss. Und Ausnahmefälle sollten es meiner Meinung nach
>> bleiben, sonst wird es zu verwirrend.
> 
> Gerade das erwähnte Array|Collection kommt bei mir eigentlich an
> allen Ecken und Enden vor und unterläuft damit die sonst inzwischen
> schon halbwegs durchgängige Typsicherheit.

Just für diesen speziellen Fall gibt es ein anderes RFC:
<https://wiki.php.net/rfc/iterable>. Ich rechne fest damit, dass dieses
zumindest dann für PHP 7.1 zur Abstimmung gebracht wird, falls die
allgemeinen Union-Types abgelehnt werden. Und ich kann mir durchaus
vorstellen, dass dieses RFC dann auch akzeptiert würde – vergleichbare
Sonderfälle gibt es in PHP ja schon (z.B. Traversable).

> Andere Fälle sind seltener, ja. Aber wie bei so vielen Dingen: Wenn
> es eh kaum vorkommt, wird es auch kaum verwendet, stört also nicht
> (und dort, wo man es braucht, hilft es).

Na ja, meiner Meinung nach sind Referenzen auch so etwas, was man
eigentlich nur sehr selten *braucht*. Trotzdem sehe ich, dass diese
häufig verwendet werden. Okay, ich selbst brauche sie nicht zu nutzen,
aber wenn ich "fremden" Code Pflege oder nutzen möchte (Bibliothek),
dann muss ich mich doch wieder damit rumschlagen.

Und das befürchte ich bei den Union-Types auch, speziell bezüglich der
üblichen Sachen wie numeric. Dann definiert jede Bibliothek ihre eigene
Variante, und ich muss die Feinheiten im Kopf haben oder immer wieder
nachschlagen. Und wenn erst mal Union-Types verfügbar sind, dann kommen
auch bald Typ-Aliase, weil keiner immer wieder alles tippen will. Und
dann kommt:

   type \LibFoo\numeric = integer|float|string;
   type \LibBar\numeric = integer|float|GMP;

   function myFunc(\LibFoo\numeric|\LibBar\numeric $num) {...}

Guck mal, Perl! Na ja, doch lieber ein eigener Typ-Alias:

   type \MyApp\numeric = \LibFoo\numeric|\LibBar\numeric;

Hm, habe ich da noch die Kontrolle, was ich eigentlich bevorzugt
bekomme? Vielleicht besser:

   type \MyApp\numeric = integer|float|GMP|string;

Na also, geht doch – bis zum nächsten Update einer der beiden
Bibliotheken, wo sich die Typ-Details vielleicht ändern, und dann merke
ich das nicht mal gleich.

Und hier habe ich nicht mal die möglicherweise verwirrenden
Interaktionen zwischen strict und non-strict typisiertem Code
berücksichtigt. Da wird zumindest mir schwindelig.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3921

On Wed, 22 Jun 2016 17:47:54 Christoph M. Becker wrote:
> Am 22.06.2016 um 16:49 schrieb Stefan Froehlich:
> > On Wed, 22 Jun 2016 12:25:53 Christoph M. Becker wrote:
> >> Was ich mir da eher wünschen würde, wären Property-Accessors
> >> (<https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented>).
 
> > Das wiederum kann ich mir allenfalls in homöopathischen
> > Ausnahmefällen als (für mich) nutzbringend vorstellen - und wenn
> > es nur darum geht, den Typ einer Property festzulegen, ist der
> > Aufwand erheblich.

> Ja, stimmt schon. Aber ich definere eben ungern eine public property,
> denn wenn ich die Implementierung ändern wollte, dann habe ich mich an
> die Wand gefahren: [...]

Das "public" habe ich eher der Vollständigkeit halber
hingeschrieben, bei mir sind eigentlich 95% der Properties private
und der Rest protected - aber auch klassenintern fände ich
Typsicherheit nett.

> [...] geht nicht sauber ohne BC-Break. Da stelle ich lieber einen
> Getter zur Verfügung, und das ist noch aufwendiger und
> unübersichtlicher als die Property-Syntax, und auch noch langsamer
> für den Fall, dass es wirklich nur ein einfacher Attributs-Getter
> ist.

Mache ich ebenso, wiewohl ich sagen muss, dass ich allenfalls in
homöopathischen Ausnahmefällen einmal Implementierungen geändert
habe, ohne dass sich dabei auch die Getter/Setter entsprechend
mitverändert hätten, ich also erst recht den ganzen Rattenschwanz an
Anpassungen durchzuführen hatte.

Das liegt in der Natur der Sache, die meisten Änderungen erfolgen ja
nicht grundlos, sondern weil der status quo nicht mehr
aufrechterhalten werden kann (sei es, weil er sich als falsch
erwiesen hat, sei es, weil der Funktionsumfang erweitert worden ist;
was auch immer).

[Union Types] 
> > Gerade das erwähnte Array|Collection kommt bei mir eigentlich an
> > allen Ecken und Enden vor und unterläuft damit die sonst
> > inzwischen schon halbwegs durchgängige Typsicherheit.
 
> Just für diesen speziellen Fall gibt es ein anderes RFC:
> <https://wiki.php.net/rfc/iterable>. Ich rechne fest damit, dass
> dieses zumindest dann für PHP 7.1 zur Abstimmung gebracht wird,
> falls die allgemeinen Union-Types abgelehnt werden.

Gut, das wäre immerhin schon einmal ein Trost.

> > Wenn es eh kaum vorkommt, wird es auch kaum verwendet, stört
> > also nicht (und dort, wo man es braucht, hilft es).
 
> Na ja, meiner Meinung nach sind Referenzen auch so etwas, was man
> eigentlich nur sehr selten *braucht*. Trotzdem sehe ich, dass
> diese häufig verwendet werden.

Mir fallen ad hoc genau zwei Gelegenheiten ein, wo ich sie verwende
und recht froh darum bin. Gäbe es sie nicht, wäre das dort
ärgerlich, aber andererseits kümmert es mich auch nicht, was andere
Leute damit anstellen.

> [...] wenn ich "fremden" Code Pflege oder nutzen möchte
> (Bibliothek), dann muss ich mich doch wieder damit rumschlagen.
 
> Und das befürchte ich bei den Union-Types auch, speziell bezüglich
> der üblichen Sachen wie numeric. [...]

Ok, wenn man sich um Fremdcode Sorgen macht, sieht das natürlich
anders aus. Aber dann darf man eigentlich überhaupt nichts erlauben;
wer mit Leistungsmerkmalen Unsinn anstellt, kann das auch auf andere
Art und Weise tun.

Ich verwende momentan nahezu nur selbst geschriebenen Code - der
muss anderen Menschen nicht gefallen (wird er auch nicht), aber er
ist in sich einigermaßen konsistent.

Und binde ich eine Bibliothek ein, die derartige Dinge tut:

>    type \LibFoo\numeric = integer|float|string;
>    type \LibBar\numeric = integer|float|GMP;

...dann sollte sich das doch unauffällig verhalten, solange ich die
Methoden nur mit Argumenten der passenden (Basis-!) Typen füttere.
Und *das* wiederum muss ich ja ohnehin tun, wenn ich keine Probleme
bekommen möchte.
 
Servus,
   Stefan

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

Vergnügen mit Stefan, verbissen und bunt!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3922

Am 23.06.2016 um 10:23 schrieb Stefan Froehlich:

> On Wed, 22 Jun 2016 17:47:54 Christoph M. Becker wrote:
>
> Mache ich ebenso, wiewohl ich sagen muss, dass ich allenfalls in
> homöopathischen Ausnahmefällen einmal Implementierungen geändert
> habe, ohne dass sich dabei auch die Getter/Setter entsprechend
> mitverändert hätten, ich also erst recht den ganzen Rattenschwanz an
> Anpassungen durchzuführen hatte.

Okay, dem Code am Ende der Bibliothekskette stehen letztlich beliebige
Änderungen offen. Aber eine Bibliothek kann eben nicht einfach mal
umgekrempelt werden.

>> Just für diesen speziellen Fall gibt es ein anderes RFC:
>> <https://wiki.php.net/rfc/iterable>. Ich rechne fest damit, dass
>> dieses zumindest dann für PHP 7.1 zur Abstimmung gebracht wird,
>> falls die allgemeinen Union-Types abgelehnt werden.
> 
> Gut, das wäre immerhin schon einmal ein Trost.

Ist zwar noch ein Tag bis zum Ende der Abstimmung, aber es sieht ganz so
aus als ob iterable mit PHP 7.1 kommt.

> Mir fallen ad hoc genau zwei Gelegenheiten ein, wo ich sie [Referenzen] 
> verwende
> und recht froh darum bin. Gäbe es sie nicht, wäre das dort
> ärgerlich, aber andererseits kümmert es mich auch nicht, was andere
> Leute damit anstellen.

Mich auch nicht, solange ich nicht mit solchem Code arbeiten muss…

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3847

Stefan Froehlich 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
> 
> Man möge mir die eher sinnfreie Methode verzeichen, aber - ist das nicht
> ein bisschen zu eng gedacht?

Nein.  (Vorsicht, Logik.)

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

Ich finde auch das zu eng gedacht.  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.

> aber eine *Einschränkung* des return types in einer abgeleiteten
> Klasse ist doch vollkommen unproblematisch; das bedeutet ja nichts weiter,
> als dass von allen zulässigen Foos nur diejenigen in Frage kommen, die
> zufällig auch Foo_Childs sind (und das wiederum taucht in
> Objekthierarchien an jeder zweiten Ecke in der einen oder anderen Form
> auf).

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.

> Sollte man das als Bug melden,

Ja.

> oder hat das am Ende sogar einen tieferen Sinn, den ich bloss nicht sehe?

Nein, es ist insbesondere in einer Sprache mit dynamischer Typüberprüfung 
widersinnig, und man findet es in keiner anderen, mir bekannten, 
objektorientierten Programmiersprache.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3854

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)

[toc] | [prev] | [next] | [standalone]

#3855

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

[toc] | [prev] | [next] | [standalone]

#3857

Christoph M. Becker wrote:

> Stefan Froehlich schrieb:
>> So, wie es derzeit implementiert ist, ist das aber jedenfalls
>> halbgar und hilft weder Dir noch mir weiter.
> 
> […] Der folgende Code wird anstandslos akzeptiert:
> 
>   class Foo
>   {
>       function bar(): Baz {}
>   }

Ja, aber wenn keine Überprüfung in der Methode vorkommt, kann sie dann auch 
ohne Argumente aufgerufen werden, ohne dass eine Exception ausgelöst wird.  
Typdeklarationen sollten aber auch das unnötig machen.
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3865

On Sat, 02 Apr 2016 19:23:24 Christoph M. Becker wrote:
> > 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.

Das ist zwar richtig, aber in dem Moment, wo man einer abgeleiteten
Klasse erlaubt, die bestehende Methode der Elternklasse mit anderer
Signatur zu überschreiben, hat sich das mit der Polymorphie
automatisch erledigt. Deshalb.

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

Mit type-hinting könnte man die passende Methode ausführen, sofern
vorhanden und - ebenfalls sofern vorhanden - als Fallback eine
Methode ohne type-hints.

Aber wenn das überhaupt jemals kommen sollte, dann erst sehr weit in
der Zukunft.
 
> 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.

Stimmt, das ist allerdings ein Argument.

Servus,
   Stefan

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

Das große Entzücken! Stefan, wenn der Chef wieder tobt!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3856

Stefan Froehlich wrote:

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

ACK.  “instanceof” überprüft aber _nicht_, ob ein Objekt eine Instanz einer 
bestimmten Klasse ist.  Ich meinte deshalb get_class().

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

Die aus C++ bekannte Funktionalität ist in PHP vorhanden, aber entweder 
müssen die Klassen voneinander abgeleitet sein oder die Typüberprüfung muss 
manuell implementiert werden.  Entweder

  $foo instanceof ArrayObject === $foo instanceof Collection /* [1] */

dann

  public function bar (ArrayObject $c) : int;

(wenn man davon ausgeht, dass eine Collection eine Spezialisierung eines 
ArrayObjects ist), oder

  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.

Was nicht zum Ziel führt, ist

  public function bar (object $c) : int
  {
    /* … */
  }

denn es gibt keine Klasse “object”; ebenso führt “stdClass” statt “object” 
nicht zum Ziel, obwohl es diese Klasse gibt.  Stattdessen muss (wie von 
Christoph vorgeschlagen) die Methode ohne Parameter deklariert werden, und 
der Zugriff auf Argumente mit func_*_param*() vorgenommen werden; eine 
Typüberprüfung muss dann in der Methode stattfinden.

Auch hier erscheint mir das PHP-Typsystem und Type Hinting/Declaration in 
PHP nicht zuende gedacht: da

  (object) $foo

zu einer Referenz auf eine Instanz von “stdClass” konvertiert, sollten alle 
PHP-Klassen implizit von “stdClass” (oder noch besser neu von einer 
“object”-Klasse, vgl. Python) abgeleitet sein.  Jedoch z. B.

  (new ArrayObject()) instanceof stdClass === false

________
[1] “Array” ist wegen Nichtbeachtung von Gross-/Klein-Schreibung kein
    zulässiger Klassenname.
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3866

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)

[toc] | [prev] | [next] | [standalone]

#3886

Stefan Froehlich wrote:

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

Bezeichner von Exception-Klassen sollten auf “Exception” oder “Error” 
*enden* und benutzerdefinierte Exception-Klassen sollten in einem eigenen 
Namespace deklariert werden.

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

$ php -r '

  class FooException extends Exception
  {
    public function __construct ($message, $code=NULL)
    {
      call_user_func_array("parent::__construct", func_get_args());
      // [some magic]
    }
  }

  try
  {
    throw new FooException("bla");
  }
  catch (Exception $e)
  {
    echo $e->getCode() . "\n";
  }

'
0
 
> Da braucht es wohl noch ein paar Nachbesserungen.

Sonst schon, da nicht unbedingt.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3888

On Tue, 19 Apr 2016 20:24:14 Thomas 'PointedEars' Lahn wrote:
> > class Exception_Foo extends Exception {

> Bezeichner von Exception-Klassen sollten auf “Exception” oder “Error”
> *enden* und benutzerdefinierte Exception-Klassen sollten in einem eigenen
> Namespace deklariert werden.

Zum einen ist das ein *Beispiel*, das ich nicht ohne Not durch Namespaces
überfrachten möchte (tatsächlich stehen die Exceptions bei mir in diversen
Namespaces, nämlich genau dort, wo die auslösenden Objekte zu finden sind),
zum anderen: sagt wer?


[geht nicht] 
> > parent::__construct($message, $code);

[geht schon]
>       call_user_func_array("parent::__construct", func_get_args());
>       // [some magic]

> > Da braucht es wohl noch ein paar Nachbesserungen.
 
> Sonst schon, da nicht unbedingt.

Öhm. Die Verletzung Deiner bevorzugten Namenskonvention regt Dich auf,
aber derartige - völlig unintuitive - Konstrukte nicht? Solcher Code
kommt mir ohne zwingende Notwendigkeit sicherlich nicht über die Finger, da
verzichte ich lieber für den moment auf strict types.

Servus,
   Stefan

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

Happy mit Stefan, verbissen und heiss!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3889

Stefan Froehlich wrote:

> On Tue, 19 Apr 2016 20:24:14 Thomas 'PointedEars' Lahn wrote:
>> > class Exception_Foo extends Exception {
>> Bezeichner von Exception-Klassen sollten auf “Exception” oder “Error”
>> *enden* und benutzerdefinierte Exception-Klassen sollten in einem eigenen
>> Namespace deklariert werden.
> 
> Zum einen ist das ein *Beispiel*, das ich nicht ohne Not durch Namespaces
> überfrachten möchte (tatsächlich stehen die Exceptions bei mir in diversen
> Namespaces, nämlich genau dort, wo die auslösenden Objekte zu finden
> sind), zum anderen: sagt wer?

Name: Konvention.  UTSL.  Demgegenüber ist “Exception_*” unüblich; es 
erinnert eher an ZF1, das für den Autoloader “_” statt Namespaces verwendet; 
dort aber hätte es dann ein “Exception”-Verzeichnis gegeben mit z. B. einer 
Foo.php darin, in der die Klasse “Exception_Foo” deklariert ist.

Namespaces: Ergibt sich aus dem sinnvollen Wunsch, Namenskollisionen mit 
Built-ins zu vermeiden, insbesondere mit jener Namenskonvention.

> [geht nicht]
>> > parent::__construct($message, $code);
> 
> [geht schon]
>>       call_user_func_array("parent::__construct", func_get_args());
>>       // [some magic]
> 
>> > Da braucht es wohl noch ein paar Nachbesserungen.
>  
^^
…

>> Sonst schon, da nicht unbedingt.
> 
> Öhm. Die Verletzung Deiner bevorzugten Namenskonvention regt Dich auf,

Nein.

> aber derartige - völlig unintuitive -

Nein.

sh:              foo () { bar "$@" 42; }

ECMAScript:      foo: function () {
                   this._super.bar.apply(this,
                     [].concat.call(arguments, 42));
                 }

ECMAScript 2015: foo () { super.bar(...arguments, 42); }

Perl:            sub foo { $self->SUPER::bar(@_, 42); }

PHP 5.4+:        public function foo ()
                 {
                   call_user_func_array(
                     "parent::bar", array_merge(func_get_args(), [42]));
                 }

Python:          def foo (self, *args, **kwargs):
                     args.append(42)
                     super().bar(*args, **kwargs)

> Konstrukte nicht?

Ja.

> Solcher Code kommt mir ohne zwingende Notwendigkeit sicherlich nicht über
> die Finger, da verzichte ich lieber für den moment auf strict types.

Was hat das eine mit dem anderen zu tun?

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.php

csiph-web