Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98459 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36137 invoked from network); 9 Mar 2017 17:47:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2017 17:47:55 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.82 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.82 mx101.easyname.com Received: from [77.244.243.82] ([77.244.243.82:44388] helo=mx101.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 12/C0-31244-A4591C85 for ; Thu, 09 Mar 2017 12:47:54 -0500 Received: from cable-81-173-135-7.netcologne.de ([81.173.135.7] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cm2AJ-0002rV-7p; Thu, 09 Mar 2017 17:47:51 +0000 Reply-To: internals@lists.php.net References: <24efb0e7-b0e3-68ed-5f42-2d5481f8f291@gmail.com> <44add374-6c4b-399a-c542-8d7f100dfaa3@fleshgrinder.com> To: Andrey Andreev , "internals@lists.php.net" Message-ID: Date: Thu, 9 Mar 2017 18:47:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-DNSBL-PBLSPAMHAUS: YES Subject: Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString() From: php@fleshgrinder.com (Fleshgrinder) On 3/9/2017 12:47 PM, Andrey Andreev wrote: > Hi, Hey :) On 3/9/2017 12:47 PM, Andrey Andreev wrote: > On Thu, Mar 9, 2017 at 1:49 AM, Fleshgrinder wrote: >> Stringable seems very explicit and strict to me, since it is opt-in. >> Currently there is no way to have the ergonomics of coercion if strict >> mode is active for a file. This could be a very explicit way to enable >> it for portions. >> > > I don't understand what you're trying to say here, or rather what you > mean by "stringable" at this point ... Is it a compound type for > string and __toString() objects only, or not? Your last comments > suggest that it isn't. All scalars, null, and objects with a __toString are stringable. I argued at first that we should only bridge string and objects with a __toString but later came to the conclusion that it does not add value. I understand that this might be confusing, since there are right now many messages in this thread. On 3/9/2017 12:47 PM, Andrey Andreev wrote: > How can "any other scalar value" work? Using the cookie and headers examples: > > - booleans can be used as On/Off flags for the secure and httpOnly > cookie attributes, but aren't valid literal values for any of the > attributes, or any HTTP header. > - integers are valid as a few headers' values - that is true, but > certainly in a minority of cases > - floats may be used for the q(uality) attribute in content > negotiation (and nothing else AFAIK), but that is a very, very narrow > domain > - null is obviously invalid ... who sends an empty header? And if you > have a use case where you do want to use them, we can already make > anything nullable > > Of course the string values should be validated, unless you want to > allow setting arbitrary headers, e.g.: > > abstract function setHeader(stringable $name, stringable $value); > > ... but filtering out the known to be invalid types *is* validation. > And just that much better if it happens at compile time. Because: - bool(true) = '0' - bool(false) = '1' - int(n) = 'n' - float(n) = 'n' - null = '' - object(s) = 's' - string(s) = 's' All values are possible values that I can pass to you if you use the string type constraint. Hence, all these types are valid string values if you request a stringable. Stringable should work exactly like the string constraint in non-strict mode, but regardless of the strict mode. The difference to a scalar type constraint is that the passed values are always converted to a scalar string, hence, the source type is unknown to the receiver. As you can see, it does not matter if the stringable pseudo-type accepts more than just string and objects with a __toString method. -- Richard "Fleshgrinder" Fussenegger