Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92815 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34818 invoked from network); 26 Apr 2016 19:33:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Apr 2016 19:33:02 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.164 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.25.164 mx208.easyname.com Received: from [212.232.25.164] ([212.232.25.164:47904] helo=mx208.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 07/C9-20013-C62CF175 for ; Tue, 26 Apr 2016 15:33:00 -0400 Received: from cable-81-173-133-226.netcologne.de ([81.173.133.226] 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 1av8j6-0006ms-Av; Tue, 26 Apr 2016 19:32:52 +0000 Reply-To: internals@lists.php.net References: To: Alexander Lisachenko , Nikita Popov Cc: Nikita Popov , PHP internals list Message-ID: <571FC258.2020600@fleshgrinder.com> Date: Tue, 26 Apr 2016 21:32:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Oup7G1iBlPih7liofNpWIdE7lXfKGCmJn" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API From: php@fleshgrinder.com (Fleshgrinder) --Oup7G1iBlPih7liofNpWIdE7lXfKGCmJn Content-Type: multipart/mixed; boundary="B9EbDUX1fQdpIObI6n5XJ9AOiK8qvXdFo" From: Fleshgrinder Reply-To: internals@lists.php.net To: Alexander Lisachenko , Nikita Popov Cc: Nikita Popov , PHP internals list Message-ID: <571FC258.2020600@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API References: In-Reply-To: --B9EbDUX1fQdpIObI6n5XJ9AOiK8qvXdFo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/26/2016 10:38 AM, Alexander Lisachenko wrote: > Hello, Nikita! >=20 > It's a great news! Having this stuff in the 7.1 core is awesome! >=20 > But I have several petitions for this API: > 1) Could it avoid using of raw functions for parsing API, like > ast\parse_file or ast\parse_code > 2) Could you please put all the parsing stuff into the `Parser` class a= nd > put it into the `Php\` namespace, as well with node classes? >=20 The current coding standard still prescribes to do so. However, these requests keep popping up and I think that this should be discussed at some point. However, putting everything into a static class just to mimic some OO that you might like makes absolutely no sense. We have multi-paradigm support for a reason: best tool for the job? That being said, the current implementation violates more rules of the coding standard (camelCase vs. snake_case). Currently we have the following: namespace ast { parse_file() parse_code() get_kind_name() kind_uses_flags() class Node { public $kind; public $flags; public $lineno; public $children; } } namespace ast\Node { class Decl extends ast\Node { public $endLineno; public $name; public $docComment; } } =46rom a pure coding standards view and current conventions in core at least the following has to change: ast_parse_file() ast_parse_code() ast_get_kind_name() // ast_kind_name? ast_kind_uses_flags() // ast_kind_has_flags? class AstNode { public $kind; public $flags; public $lineno; public $children; } class AstDecl extends AstNode { public $end_lineno; public $name; public $doc_comment; } Of course usage of the \Php\Ast or \PHP\AST or \Php\AST or \PHP\Ast namespaces is possible but you already see from the four variations that this opens a huge can of worms that would require discussion. Personally I would design the API as follows, given that it is not a goal to have an anemic model in order to support direct changes of the public properties without any kind of validation. If that is an intended functionality things might need to be implemented a bit differently (and the anemic DTO approach could even make sense). Also note that I am modelling it in an OO way because it fits the actual data structure (tree= ). enum AstKind { /*API =3D [ ORDINAL, NAME ]*/ FUNCTION =3D [ 66, 'AST_FUNC_DECL' ]; CLASS =3D [ 67, 'AST_CLASS' ]; // ... /** @see \AstKind::getName() */ public function __toString(): string; /** bitfield */ public function getFlags(): int; public function getName(): string; public function getOrdinal(): int; public function hasFlags(): bool; } final class AstNode implements Countable, Traversable { private AstKind $kind; private int $line_number; private array $children =3D []; public function getKind(): AstKind; public function getLineNumber(): int; } final class AstDeclarationNode extends AstNode { private string $doc_comment; private int $end_line_number; private string $name; /** @see \AstDeclarationNode::getName() */ public function __toString(): string; public function getDocComment(): string; public function getEndLineNumber(): int; public function getName(): string; } final class Ast implements Countable, Traversable { private AstNode $root; private function __construct(); public static function fromFile(string $path): Ast; public static function fromCode( string $code, string $filename =3D 'string code' ): Ast; /** @see \Ast::getDump() */ public function __toString(): string; public function getDump(bool $line_numbers =3D false): string; } I do not think that it is necessary to use the exact same constant names as are used in the C source (e.g. AST_FUNC_DECL vs. AST_CLASS). The userland API could be more consistent here. You might disagree thought but in the end only the ordinal must be an absolute perfect match. --=20 Richard "Fleshgrinder" Fussenegger --B9EbDUX1fQdpIObI6n5XJ9AOiK8qvXdFo-- --Oup7G1iBlPih7liofNpWIdE7lXfKGCmJn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXH8JhAAoJEOKkKcqFPVVrs2UQAJYC6bpNSImYRzeZLqDKcRnI yH1fT12WQEhA0w5jnDbj/MzvBSDjqpp/tnEqw5Qh/NqpXNnI+XenjxM4yhD3CNoc bX+RCCmC9WtMAXrgHQVx2PzILSWYRL3gy0Ma3Hzbvfwww85LLQqvM5e7YOgNLytu heyI82I6JgWUrj+PY+/cmD5DIGVfTYLyLelGv6m1rngOnxd5z+m3d0ImmX6R8NKA q5Sh7TeobM4cLDyOzlPP2070nNK4lg9Sj4J0LsGp4CDWIKWQgf2zGE8E5zYRVw3f YL7xUx4280GBPIBDP4s2TX5tKmoYLFHViCjz7oSuDW/Z0y8nI5FdU1OVFyjbvzOg t6kEwmOmdn97R1BEzl3DaiyFFnBwkPs6qH4LPwLdnnV7KpSU0G9tdWI84ubmSDTd Cco2y5w6GuMDNol19vVYeDYApz7rDzPteSdoaMzwRzt9d7GQeiIbOBzmwzgoQfyd ZiwOW2pXUS07O7gMa7fCPYeUpW12eZYtn3ry9+vfqlRYXojUiptEY9kEXIH3ViQ+ wn/olyKgXDhi+xe8aSaqIAl2NhnVyumuZveBFDNFxatOa5ogvGncUbygqRCTec47 RTSDjmV/eSeQFdG8gzxHELFgCk5/1ImigbsUCzRYgr/kGmHBQxbpflBUcxnP/AXl OtEnWIMFXTO8j1oEh2aG =tJCS -----END PGP SIGNATURE----- --Oup7G1iBlPih7liofNpWIdE7lXfKGCmJn--