Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96853 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 99724 invoked from network); 12 Nov 2016 14:15:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Nov 2016 14:15:32 -0000 Authentication-Results: pb1.pair.com header.from=pthreads@pthreads.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=pthreads@pthreads.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.47 cause and error) X-PHP-List-Original-Sender: pthreads@pthreads.org X-Host-Fingerprint: 74.125.82.47 mail-wm0-f47.google.com Received: from [74.125.82.47] ([74.125.82.47:38655] helo=mail-wm0-f47.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/15-35596-40427285 for ; Sat, 12 Nov 2016 09:15:32 -0500 Received: by mail-wm0-f47.google.com with SMTP id f82so25399003wmf.1 for ; Sat, 12 Nov 2016 06:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pthreads-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NmJ7GU4EkeOsXVUZbo/Ialmy5QDvAPMRJJOcQIiLy2c=; b=K240h/nwL/8KaBxW6Gcs+9RJ5y//tKdPfwo9oDk2fYo1rl9YV3TYmMz3tyy/7DjFR4 xJ2mPd3JEfTBskJknAelWUTkWMRJLjSZeUlnkBHqgRuObEYus2Su6mP3yjkXBN0sfF4M ER4eCAUrYZ63sUusVyZZPpK87kGLjHCpRwLPAvmtrebUt1+WkBD3OmMrG7wYhEaxnEk3 8BpynOvhohkJWStpT5k6gd8sPwQLNAsg5BylPgGlUW+S3Vy3UTFPjLol/AzjyfihHkJ6 K7iOr6NSaDN2E/M4LqKq2E3d9WutWKH+SELCSvABV8cS15cDctCvmAYN+KutqfeBQ5Fj BBZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NmJ7GU4EkeOsXVUZbo/Ialmy5QDvAPMRJJOcQIiLy2c=; b=KDnBeAnxeHMUv0bsaiX/LIvUDnrDphbMT92lDYgJW/xpUprxc/tmlqtAb4/AugmVia 08nBIOLk/jJymCg2EOVMljhUtZJmQqdSeOmHOQ3AGx9YX0WRbgRME6KLzkwh70H1bGM4 k6kwaw/idl2GQV6qZL9dfw32yh1CWdw+u+SUiTVFUfi0w8C0cpEaTbqKYWQlOXmRWHAa VTYaCiYWKFMBkjHjkqRtOCXKX8z5unjAkhxYNSvPguB8yysaZ3CEuT/wkUgUu9REpkqb VMwO/zhLMvU6wosVKKNatJBRcaOCw0jlqAhf5+qDdOMUfJLI71+B3yA6ilFVRtZaEDxD ZMOg== X-Gm-Message-State: ABUngvd21QvLPCnghGFBms/JlmqPcjjpxs0fSdgWjExduORR2encNZzjRvgE2hhTUK9au/Nn33A2BgXy8VMJpw== X-Received: by 10.28.9.80 with SMTP id 77mr2872823wmj.68.1478960129425; Sat, 12 Nov 2016 06:15:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.161.230 with HTTP; Sat, 12 Nov 2016 06:15:28 -0800 (PST) X-Originating-IP: [109.157.245.230] In-Reply-To: References: Date: Sat, 12 Nov 2016 14:15:28 +0000 Message-ID: To: Nikita Popov Cc: "Christoph M. Becker" , PHP internals Content-Type: multipart/alternative; boundary=001a11444da826e10005411b3dc8 Subject: Re: [PHP-DEV] Re: C89 vs. C99 From: pthreads@pthreads.org (Joe Watkins) --001a11444da826e10005411b3dc8 Content-Type: text/plain; charset=UTF-8 Morning Nikita, It is actually the first kind I'm rebelling against. I think the second kind might lead people to think we would accept the first kind, and I think an extreme version of the second kind could also harm readability. How about we adopt the rule of thumb that "declarations should be grouped for clarity" (as sort of suggested by you) This means you can write the kind of code you want to write, and I can refuse to merge the kind of code I don't want to merge ? Cheers Joe On Sat, Nov 12, 2016 at 1:59 PM, Nikita Popov wrote: > On Sat, Nov 12, 2016 at 2:21 PM, Joe Watkins > wrote: > >> Morning Nikita, >> >> All good points, that it's hard to refute. >> >> However, right now, I know where all variables that are going to be used >> are declared, no matter the size of the function or it's complexity. If not >> at the very top, eyes get good at scanning for blocks. >> >> What I don't want is to have to scan already complicated code to find out >> when a variable was declared. >> >> We need to have rules of thumb, and unless someone can defend their use >> rigorously, I would say the rule of thumb that code shouldn't be mixi ought >> to be followed. At least it ought to be followed in the top layer of PHP >> (anything inside a PHP|ZEND_FUNCTION and such). >> >> A defence of elegance is legitimate, so long as their use does genuinely >> increase elegance. Such examples exist, but I think more examples of mixi >> code being harder to follow exist ... >> >> Cheers >> Joe >> > > I have the feeling that we both sort-of agree, but are really talking > about different things. > > There are two ways in which you can have code mixed with declarations. The > first one is within a single "basic block", like this: > > int a = ...; > b = ...; > int c = ...; > a = ...; > float d = ...; > // ... > > I can totally see how some many people might find this kind of code to be > objectionable. > > However, the use-case that I have in mind is different -- it's the case > where declarations **are** at the top of a block -- but its the top of a > basic block in terms of control flow, not a block in terms of C syntax. To > clarify what I mean by that: For a compiler (and arguably, a programmer), > the control flow of > > if (...) { > return; > } > > // Basic block starts here, but not C block > type var = ...; > > and of > > if (...) { > return; > } else { > // Basic block starts here, and C block > type var = ...; > } > > is the same. The declaration in both cases is at the top of a control-flow > block. It just doesn't happen to coincide with a syntactic C block. > > This is the case I'm interested in. > > Anyway, I'll just leave this gem from our codebase here: > https://github.com/php/php-src/blob/master/ext/standard/ > http_fopen_wrapper.c#L114 (Some of those variables have 500 lines of code > between declaration and first use) > > Thanks, > Nikita > --001a11444da826e10005411b3dc8--