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


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

Re: return types

From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Newsgroups de.comp.lang.php
Subject Re: return types
Date 2016-04-21 02:55 +0200
Organization PointedEars Software (PES)
Message-ID <1554180.peWpD3a0XF@PointedEars.de> (permalink)
References (2 earlier) <dm7lpsFpt1jU1@mid.individual.net> <6322257.QELA2EPoA3@PointedEars.de> <ft570c14e6i64can3e8%sfroehli@Froehlich.Priv.at> <1882669.YLIovkB3xS@PointedEars.de> <1t571726e1i2b88n3e8%sfroehli@Froehlich.Priv.at>

Show all headers | View raw


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.

Back to de.comp.lang.php | Previous | NextPrevious in thread | Find similar | Unroll thread


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