Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93341 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38955 invoked from network); 15 May 2016 14:45:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 May 2016 14:45:06 -0000 Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.163 cause and error) X-PHP-List-Original-Sender: me@kelunik.com X-Host-Fingerprint: 81.169.146.163 mo4-p00-ob.smtp.rzone.de Received: from [81.169.146.163] ([81.169.146.163:57767] helo=mo4-p00-ob.smtp.rzone.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 90/E8-48938-17B88375 for ; Sun, 15 May 2016 10:45:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1463323503; l=4792; s=domk; d=kelunik.com; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version; bh=E5z+pikXDLjBL+bqDUVGYvjzCJCuVEBrl1BeYcc6heI=; b=bAja4gQ30XAhYI7Yd/NhH3+/MrnkuHa0XzPPHsPcVtbCKyoctjBzmEGJnXNfAWBrhml quXrg6Y+/7fxPujZOZ2M+uwxYCmMat6HV2WoeFIMz/mdL5CVwdm9Esd0tDQjlG/pFdHV9 c/x0+dw4Rb9cv8p5vTZfu/OXiTN7JUv+K8k= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtO3s6 X-RZG-CLASS-ID: mo00 Received: from mail-wm0-f48.google.com ([74.125.82.48]) by smtp.strato.de (RZmta 37.26 AUTH) with ESMTPSA id h043c7s4FEj2wfR (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate) for ; Sun, 15 May 2016 16:45:02 +0200 (CEST) Received: by mail-wm0-f48.google.com with SMTP id a17so99656758wme.0 for ; Sun, 15 May 2016 07:45:01 -0700 (PDT) X-Gm-Message-State: AOPr4FWX5xSqnlAo3hv0IXJCrJcRbLY6XQe3u3luGayjnpG6Q2fw95Hdl8x02KaRpqUMunmGKdPF2uoA7ofYWg== MIME-Version: 1.0 X-Received: by 10.194.87.103 with SMTP id w7mr25037763wjz.13.1463323501886; Sun, 15 May 2016 07:45:01 -0700 (PDT) Received: by 10.28.53.132 with HTTP; Sun, 15 May 2016 07:45:01 -0700 (PDT) In-Reply-To: References: <5734B148.40602@mvlabs.it> <925076c8-5d9c-a780-c260-f1c76855283c@gmail.com> <5734F21D.1050801@mvlabs.it> Date: Sun, 15 May 2016 16:45:01 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Rasmus Schultz , Joe Watkins Cc: Marco Perone , PHP internals Content-Type: multipart/alternative; boundary=047d7bf10b5485c2a30532e28dfe Subject: Re: [PHP-DEV] Functorial interfaces From: me@kelunik.com (Niklas Keller) --047d7bf10b5485c2a30532e28dfe Content-Type: text/plain; charset=UTF-8 2016-05-15 16:21 GMT+02:00 Rasmus Schultz : > > As a downside, you can't implement it in a normal class anymore and just > use > > an instance of that class. > > I see that as a plus, because, as a you said: > > > That's why you call it with the method name of the interface > > Your logic is circular - you also said: > > > As a downside, you can't implement it in a normal class anymore and just > use > > an instance of that class. > > So you want it both ways, class and callable. > > But if I'm not supposed to invoke it as a callable, why implement it > as a callable in the first place? > > In other words, you can't really have both - it doesn't really work: a > callable can be treated as a class, but a class can't be treated as > callable. If I have to treat everything as classes anyhow, why not > just use classes? > > The only advantage seems to be shorter syntax than anonymous class > declarations - the resulting objects have to be treated the same way > in practice, From the RFC: The anonymous class version: - must use referencing, or fetch a new Countable object on each iteration, - is extremely verbose - must set dependencies in the constructor - has no support for lexical scope The functional interface version: - is sparse - is easier to reason about - does not require the use of references - supports lexical scope - Functional interface support does not change the definition of an interface, and only reuse the definition of a Closure. > e.g. you can't safely treat them as callables. That's > where the chain falls off for me: you end up with callables, but you > shouldn't depend on them being callables, so then why make them > callables in the first place? --047d7bf10b5485c2a30532e28dfe--