Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94635 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16258 invoked from network); 22 Jul 2016 15:45:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jul 2016 15:45:10 -0000 Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.29 out5-smtp.messagingengine.com Received: from [66.111.4.29] ([66.111.4.29:44749] helo=out5-smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/55-24343-58F32975 for ; Fri, 22 Jul 2016 11:45:10 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 76156202C9 for ; Fri, 22 Jul 2016 11:45:07 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Fri, 22 Jul 2016 11:45:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=YmTBuynEB4FANBp s8lXpDG94S5o=; b=gD26IGGq3NDwCdbCRTOFDkUj2wyu4XAYNmWmAWBw0pi8AYf kN0RS4hAkydRqDPOye3BgS4Byv4l/k+z9n2oMego1ihTVSILADlgAOqFW2Mx+eGn q72dPPzQYdlswXW6fGhYrSQmmlorCixQ9EK5L2uSZFy6P1FdcEEmwaKBlNZg= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4370B166FF; Fri, 22 Jul 2016 11:45:07 -0400 (EDT) Message-ID: <1469202307.3729097.673942625.3A62CE90@webmail.messagingengine.com> X-Sasl-Enc: xY4ndqsEMha2clTCMtp23OnqNOYZn4MB2KTg+9I3Wr1L 1469202307 To: internals@lists.php.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-2ccfea0a In-Reply-To: References: Date: Fri, 22 Jul 2016 10:45:07 -0500 Subject: Re: [PHP-DEV] RFC: lazy statements From: larry@garfieldtech.com (Larry Garfield) On Thu, Jul 21, 2016, at 10:51 AM, David Rodrigues wrote: > This Feature Request is about the implementation of lazy statements. > > Basically it should implements a 'lazy' keyword (or similar) and > structured like an anonymous function, except that it doesn't accepts > arguments, but accept the use() feature. > > $var = lazy { return 1; } > $var = lazy use ($x) { return $x; } > > It differ from anonymous function because this assignment is treated > as variable, without need to call or check if it is a valid Closure > all the time. > > --- > > Execution example: > > echo $var; > echo $var; > > In this example, the first echo will execute the lazy statement and > set the returned value directly to $var container, then will echo 1. > The second echo will not execute the lazy anymore, because it was > processed on first echo, so will just echo 1. > > --- > > It should be very useful on framework or package development because > you can defines lazy properties that need to be calculated only when > it is requested the first time. > Should be useful too when you have a global variable like $user that > you should not use all the time (in all requests). > > View::share('user', lazy { return User::find(session('user.id')); }); > > This code will be executed only on try read or write on $user variable. > > --- > > It should works from read or write, to the next code is valid: > > $var = lazy { return [ 1, 2, 3 ]; }; > $var[] = 4; > > --- > > Currently it is possible do it in a very hackish way: by using magic > getter, by create a user getter or a own implementation of this > feature. > All this ways have a lot of limitations. > > A hackish example that shows how it should works on current PHP > version: http://pastebin.com/cz93wL7n > > --- > > I tell more about that here: https://bugs.php.net/bug.php?id=72637 > > -- > David Rodrigues In concept I like the idea, especially as it would allow for "optionally computed values", which is a performance benefit if those values may not be used. Think of pulling default values out of configuration in the database if not provided at runtime; no sense running the query if it won't be used. I could also see it having very interesting use cases in dependency injection containers. However, that also means there's an enormous potential for race conditions. Technically no more than closures now, but the use cases seem like they'd make it more prevalent. If you "use" by reference, or use a mutable object, or a service that depends on IO, etc. then the resulting value of the lazy variable is not technically non-deterministic, but will certainly feel like it to the developer. Is there a way we could provide better safety around that issue? --Larry Garfield