Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64863 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38395 invoked from network); 11 Jan 2013 15:32:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jan 2013 15:32:25 -0000 Authentication-Results: pb1.pair.com header.from=cpriest@zerocue.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cpriest@zerocue.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender) X-PHP-List-Original-Sender: cpriest@zerocue.com X-Host-Fingerprint: 67.200.53.250 mail.zerocue.com Received: from [67.200.53.250] ([67.200.53.250:33939] helo=mail.zerocue.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 61/E2-11723-78030F05 for ; Fri, 11 Jan 2013 10:32:23 -0500 Received: from [172.17.0.122] (unknown [66.25.151.173]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.zerocue.com (Postfix) with ESMTPSA id 066F712037A; Fri, 11 Jan 2013 15:32:19 +0000 (UTC) Message-ID: <50F03079.3030801@zerocue.com> Date: Fri, 11 Jan 2013 09:32:09 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pierre Joye CC: PHP internals , Stas Malyshev , "guilhermeblanco@gmail.com" References: <50EF2634.9030008@sugarcrm.com> <50EF8FCF.7020701@zerocue.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010600060503010903050105" Subject: Re: [PHP-DEV] A remark about PHP's Vision and new things. From: cpriest@zerocue.com (Clint Priest) --------------010600060503010903050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It's a pretty decent read, but the major point that his article about the virtues of C misses a huge mark. Software written in C, when they become of sufficient size become completely impossible to keep track of. A function that is related to a zend_function struct could be placed anywhere, in any file and can be named in any way. Finding it is like looking for a needle in a haystack, then you add macros. When I first started with working with the php-core I was doing everything wrong because it's a big mess, that's what happens with C, it has no organization requirements whatsoever and unless everyone who is working on the project is highly organized in the same fashion it will become a disorganized mess. Sure, C++ adds a lot of things that *can* overly complicate things but at the very least it requires organization, something that most projects sorely need. Even so, C++ is not the only object oriented language out there. -Clint On 1/11/2013 12:35 AM, Pierre Joye wrote: > No. C++ is horrible. Very good read: > http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html > On Jan 11, 2013 5:06 AM, "Clint Priest" wrote: > >> Oooh, a rewrite? Can we write it in an object oriented language this >> time? Please? Pretty Please??? >> >> :D >> >> On 1/10/2013 9:49 PM, guilhermeblanco@gmail.com wrote: >> >> Stas, >> >> I totally agree and Pierrick and I faced all these problems during the >> creation of patch. >> If PHP doesn't all have support required for a given feature, let's just >> not only discuss feature, but also the required support too. Named >> parameters is a great example. I'd also name another one, >> ReflectionNamespace; namespaces are converted to strings and attached to >> their classes during compile time and you can never reflect over them to >> grab for example their names. >> I even mentioned to Andi back in 2010 that ZE gets re-written every 5 >> years. That happened in 2000, 2005 and we're now hitting walls because of >> "monster" changes required to implement feature A or B. Maybe it's time to >> consider a rewrite again? >> >> Cheers, >> >> >> On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote: >> >> >> Hi! >> >> >> I strongly suggest to anyone following the (too many) threads about >> annotations to try the C# annotation and see what it allows. It goes >> >> >> As far as I can see, C# annotations rely on two very important things: >> 1. Compiler support. Compiler really knows a lot about what annotations do. >> 2. Extensive library support. Annotations themselves are just passive >> metadata, what makes them work is .net framework that uses them. >> >> This means to make annotations as useful in PHP we would have to have >> substantial support in the engine (including bytecode caching >> provisions, etc.) and some libraries that require very >> latest-and-greatest version of PHP. >> >> Another thing is that we're not having some features that are used >> extensively in C# annotations, main being named parameters support. >> >> I am saying this not to oppose the idea of annotations or the idea of >> looking into C# and other languages (actually, I think anybody who talks >> about it should look at least into what C# and Java do with it - and >> also what Python does, which is completely different direction, just to >> know other options). I'm just saying porting this to PHP may be less >> than straightforward. >> >> -- >> Stanislav Malyshev, Software Architect >> SugarCRM: http://www.sugarcrm.com/ >> (408)454-6900 ext. 227 >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> -- >> -Clint >> -- -Clint --------------010600060503010903050105--