Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82546 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8652 invoked from network); 12 Feb 2015 16:59:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Feb 2015 16:59:23 -0000 Authentication-Results: pb1.pair.com header.from=php@tutteli.ch; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=php@tutteli.ch; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender) X-PHP-List-Original-Sender: php@tutteli.ch X-Host-Fingerprint: 80.74.154.78 ns73.kreativmedia.ch Linux 2.6 Received: from [80.74.154.78] ([80.74.154.78:42022] helo=hyperion.kreativmedia.ch) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 11/00-08423-8EBDCD45 for ; Thu, 12 Feb 2015 11:59:21 -0500 Received: (qmail 32009 invoked from network); 12 Feb 2015 17:59:16 +0100 Received: from cm135-167.liwest.at (HELO RoLaptop) (81.10.135.167) by ns73.kreativmedia.ch with ESMTPSA (AES256-SHA encrypted, authenticated); 12 Feb 2015 17:59:16 +0100 To: "'Andrea Faulds'" Cc: "'Nikita Nefedov'" , =?utf-8?Q?'Pavel_Kou=C5=99il'?= , "'PHP Internals'" References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me> <54DAF884.7000508@lerdorf.com> <203e611c8e0b03568a868b8d931aec37@mail.gmail.com> <61E01A7C-C5C8-447F-A8FA-E12A18E847CA@ajf.me> <85D76C91-9A9E-459B-847A-619AA21B9262@ajf.me> <342635C4-F0EA-4557-A37F-753E51100402@ajf.me> <007b01d046df$1bde01d0$539a0570$@tutteli.ch> <13D542A4-16A3-40AF-8982-E851AF7AD9D3@ajf.me> In-Reply-To: <13D542A4-16A3-40AF-8982-E851AF7AD9D3@ajf.me> Date: Thu, 12 Feb 2015 17:59:15 +0100 Message-ID: <007c01d046e5$3c01a420$b404ec60$@tutteli.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJMIZG9mXkdirFXmuP9r5ZK3xIuzQJbJJA/AzCIQggCYWllLQKBurkXAYsw6s4B6qYCMgHjX/2GAb5UKOABwylnMQKF/fUwArGIQ84B1RtadQMO5Q+CAqJubzkBDVl/xQJTeJzMAVmQE0uaz3Zs0A== Content-Language: de-ch Subject: AW: [PHP-DEV] [VOTE] Scalar Type Hints From: php@tutteli.ch ("Robert Stoll") > -----Urspr=C3=BCngliche Nachricht----- > Von: Andrea Faulds [mailto:ajf@ajf.me] > Gesendet: Donnerstag, 12. Februar 2015 17:50 > An: Robert Stoll > Cc: Nikita Nefedov; Pavel Kou=C5=99il; PHP Internals > Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints >=20 > Hey Robert, >=20 > > On 12 Feb 2015, at 16:15, Robert Stoll wrote: > > > > There are several programming languages which do support dynamic = typing and method overloading somehow (Clojure, > Erlang, Prolog, Cecil and certainly more). Most of them use a = multi-method approach and I think if PHP would introduce > function/method overloading, then such an approach would be = appropriate. >=20 > Interesting, I should maybe look into those. I=E2=80=99m not sure if = all of those are really=E2=80=A6 =E2=80=9Cdynamic=E2=80=9D as such. Are = you sure the > overloading you=E2=80=99re referring to there isn=E2=80=99t = pattern-matching? >=20 > > Right now, I need to implement the dynamic dispatching quasi myself = which might be more verbose but is also more > cumbersome (and uglier IMO). Consider the following (fictional = example): > > > > I want to write a Logger-Service which provides one public method > > "log" which writes all kind of objects to a log. The corresponding > > classes do not all belong to my code base, are part of third party > > libraries respectively, so I am not able to introduce some interface > > which all classes implement. The strategy pattern is certainly a = good > > idea for this problem but nevertheless, somewhere I need to have the > > distinction based on many if/else with instanceof (latest in the > > LoggerStrategyFactory) -- off topic, if someone has a better design > > approach to handle this problem, then let me know it in a private > > message, would be interesting as well ;) > > > > class Logger{ > > public function log($x){ > > if($x instanceof Foo){ > > logFoo($x); > > }else if($x instanceof Bar){ > > logBar($x); > > } > > //... > > }else{ > > throw new Exception("type ".gettype($x)." not supported"); > > } > > } > > private function logFoo(Foo $f){ > > //.. > > } > > private function logBar(Bar $b){ > > //.. > > } > > //... > > } > > > > With method overloading I could write the following, removing the = hassle to write the dynamic dispatch myself: > > > > class Logger{ > > public log(){ > > $this->_log($x); > > } > > private function _log(Foo $f){ > > //.. > > } > > private function _log(Bar $b){ > > //.. > > } > > //... > > private function _log($x){ > > throw new Exception("type ".gettype($x)." not supported"); } } > > > > Which is cleaner IMO. >=20 > We could also add some sort of pattern-matching syntax which could do = the same thing, but would have usefulness > beyond merely dispatching to multiple methods. >=20 > -- Sure, IMO that is just another way to support overloading, or rather the = other way round, overloading is in some cases just another form of = supporting pattern matching based only on types (as you said, pattern = matching is way more powerful than just distinguishing types). In this = sense, pattern matching would be even more useful and would surely have = my support. Yet, there are cases where pattern matching is rather ugly = as well. Let's consider the code above again and let us assume we have = more than 10 different types which we want to log. Having all the logic = in one pattern match block is rather ugly and does pretty much violate = the single responsibility principle. In such a case overloading makes = more sense and is cleaner.