Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103214 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98330 invoked from network); 21 Sep 2018 13:13:42 -0000 Received: from unknown (HELO mail-io1-f54.google.com) (209.85.166.54) by pb1.pair.com with SMTP; 21 Sep 2018 13:13:42 -0000 Received: by mail-io1-f54.google.com with SMTP id n18-v6so11529689ioa.9 for ; Fri, 21 Sep 2018 02:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zQ1hfoItC9oItIDXU19u4LEibYl3RsraP6ygKQvbTaY=; b=bkJTjLCF0JGnmUEIBoQLMCCfgfnyK5J6q2W3sGm6gRAjulODy3hlH4EWjcRoJm1McS k3+nQnM54HBV4ScWO5Sy4rIAHHHIyRoc35z4ceFxPdENhHZfQxkHLH38xYLmVUXWjnll o3RIkq19n/MITK0z2Bk2ucCpUDA0qAF5TRvhkWa35/ox3NAG/8yDqI1roZfdADmxcTgS m+TngfLD/+eqOobOUuBgHsaM7Jmk3wpNy4bnrDr1u92mN75ia1tN6Dy/iSzZiVBKrG0w jCfBs8LReYMuPCpxtD84LJXxHxFz3nd7dmceCEQKneXehkNlJqhShwrGyrUNm6xcsrqE hNdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zQ1hfoItC9oItIDXU19u4LEibYl3RsraP6ygKQvbTaY=; b=m0J9G9gK0N3+xdCjMxqDkiM/ZyEwhLUO5LAfZj5or0ooUkFjDM0LFOl8bcfnG/EAvo PYzJagzNGrnrUDg530xhHyLTs96IT5pcqzkaXS9U0he3op5anp6EfqyZIznVAO+c77m5 o53PhxSaG4QevzV0HPSPhHL6soLmXyaS0/z0pKUHdMXqCqkt2S08HT3HDmQWEvxVd7pH H1Em6lnlTN6XSveqKg7L2vhfvqSiqjrP+w/TQrpdsqZXtZptUJDfd5aeNGiEw594dT/2 rz5Rsea0YQqhFGhwAOQWnqIct2729eGOkx7vntiBw63cuVEkF+QiWby0i1GyalzrSGwo O0vg== X-Gm-Message-State: APzg51Coor/KgOGgyZh8cG72xev2QHSIQ4ZWUcxi79Es5O1SR1Sfpi3t izxuj/SRSbgi5eIJzSAP65JH6zSuPv6isHrR1gl8/Q== X-Google-Smtp-Source: ANB0VdZwoGxXaH5rN9+2RW1gBVU5D7jPv6ikv03ZB7UWBEEIb4ucx//QGJqVZ3HUW4X5SkKtlTJ1jCwwY6oUY5WACjI= X-Received: by 2002:a6b:3108:: with SMTP id j8-v6mr35702247ioa.219.1537521632209; Fri, 21 Sep 2018 02:20:32 -0700 (PDT) MIME-Version: 1.0 References: <4983605.CXexPrWP49@vulcan> In-Reply-To: <4983605.CXexPrWP49@vulcan> Date: Fri, 21 Sep 2018 10:20:20 +0100 Message-ID: To: Larry Garfield , PHP internals Content-Type: multipart/alternative; boundary="000000000000b8f3e005765e269d" Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2 From: rowan.collins@gmail.com (Rowan Collins) --000000000000b8f3e005765e269d Content-Type: text/plain; charset="UTF-8" On Thu, 20 Sep 2018 at 16:52, Larry Garfield wrote: > I think the distinction here is that one group is arguing for "state of > the > data assertions" while the RFC as implemented is "setter assertion > shorthand". > That is, it doesn't assert that a value IS a given type, but that it can > only > be SET TO a given type. > > I don't think a complete IS enforcement is possible given PHP's nature. > ... > That hasn't brought about the end of the world, so I'm not super worried > about > imperfect property checks destroying everything. > > That said, I totally appreciate the desire as a consumer of an object to > know > that it's read-type-safe. This is a useful distinction, thank you for putting it so clearly. Perhaps it depends whether you are looking at the feature as a library author, or a library consumer: as an author, you want to protect "your" objects from invalid *assignments*, inside and outside the library; as a consumer, you want assurance that you can *use* the object in a particular way. The current implementation provides a good tool for the author, but falls short for the consumer. > To wit, could we add an engine check to scan an object and make sure its > objects are all type valid right-now (viz, nothing is unitialized), and > then > call it on selected actions automatically and allow users to call it at > arbitrary times if they are doing more esoteric things? > > I'm thinking: > > * on __construct() exit. > * on __wakeup() exit. > * Possibly other similar checkpoints. > * When a user calls is_fully_initialized($obj); (or something) > > is_fully_initialized() would return bool. The other checkpoints would > throw a > TypeError. > > That would layer on top of the current RFC cleanly, would give us the read- > assurance that we'd like in the 95% case I think this is a really sensible approach: as you say, it may never be possible to assert the invariant in every case, so checking the most common scenarios may be the pragmatic thing to do. Conveniently, treating it as an occasional assertion, rather than a strict invariant, means we can keep the unset() lazy-initialization hack; it's still an odd feature IMO, but probably not all that likely to be triggered by mistake. Regards, -- Rowan Collins [IMSoP] --000000000000b8f3e005765e269d--