# $obj->attr::method() is not allowed - Thread: https://externals.io/message/62745 - Original archive: https://news-web.php.net/php.internals/62745 - Started by Ivan Enderlin @ Hoa on 2012-09-03T14:51:18+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #62745 — Ivan Enderlin @ Hoa — 2012-09-03T14:51:18+00:00 URL: https://externals.io/message/62745#62745 Hello, I would like to start with an example: a = new A(); } public function a ( ) { return $this->a; } public function f ( ) { return $this->a::foo(); } } $b = new B(); var_dump($b->f()); This is not possible. We have a parse error in B::f because $this->a::foo() is not a construction of the language. But we can write: $a = $this->a; $a::foo(); In the same way, we can't write: $this->a()::foo(); I would like to know why? Is it a compiler related issue or just an omission? Would it be interesting to fix it? Best regards. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ --- ## #62747 — Andrew Faulds — 2012-09-03T15:18:52+00:00 URL: https://externals.io/message/62745#62747 · In reply to: #62745 > > I would like to know why? Is it a compiler related issue or just an > omission? Would it be interesting to fix it? > There are plenty of examples of this. One from my code: Can't do this: self::$views[$path](); But I *can* do this: $x = self::$views[$path]; $x(); This is because PHP has a very unusual (and IMO bad) system of type-checking at parse-time, by only allowing some specific (although quite varied) types of variable access, and combinations of these. If nikic's idea to rewrite the parser to use an AST is done, I imagine this could be fixed. We could also add extra rules, but I think fixing the general issue is more important, since it's like plugging two holes in a barrel full of water that's just had a machine gun fired at it. -- Andrew Faulds http://ajf.me/ --- ## #62748 — Ivan Enderlin @ Hoa — 2012-09-03T15:20:56+00:00 URL: https://externals.io/message/62745#62748 · In reply to: #62747 > > > […] > There are plenty of examples of this. One from my code: > > Can't do this: > > self::$views[$path](); > > But I *can* do this: > > $x = self::$views[$path]; $x(); > > This is because PHP has a very unusual (and IMO bad) system of > type-checking at parse-time, by only allowing some specific (although > quite varied) types of variable access, and combinations of these. > > If nikic's idea to rewrite the parser to use an AST is done, I imagine > this could be fixed. We could also add extra rules, but I think fixing > the general issue is more important, since it's like plugging two > holes in a barrel full of water that's just had a machine gun fired at it. Absolutely. PHP has no AST? Why? For historical reasons? -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ --- ## #62749 — Andrew Faulds — 2012-09-03T15:20:57+00:00 URL: https://externals.io/message/62745#62749 · In reply to: #62748 > > Absolutely. > > PHP has no AST? Why? For historical reasons? > I believe so. Rasmus's original parser was not exactly world-class ;) -- Andrew Faulds http://ajf.me/ --- ## #62750 — Ivan Enderlin @ Hoa — 2012-09-03T15:22:59+00:00 URL: https://externals.io/message/62745#62750 · In reply to: #62749 > > > […] > I believe so. Rasmus's original parser was not exactly world-class ;) Haha, ok ;-). Thanks. I thought it was a compiler related issue, now I am sure it is. Cheers. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ --- ## #62751 — Laruence — 2012-09-03T16:03:10+00:00 URL: https://externals.io/message/62745#62751 · In reply to: #62747 > > > […] > There are plenty of examples of this. One from my code: > > Can't do this: > > self::$views[$path](); > > But I *can* do this: > > $x = self::$views[$path]; $x(); > > This is because PHP has a very unusual (and IMO bad) system of type-checking > at parse-time, by only allowing some specific (although quite varied) types > of variable access, and combinations of these. It is great parser(simple and fast) which make php works well for years.. > > If nikic's idea to rewrite the parser to use an AST is done, I imagine this > could be fixed. We could also add extra rules, but I think fixing the > general issue is more important, since it's like plugging two holes in a > barrel full of water that's just had a machine gun fired at it. rewrite the parser for what? for more academism? we will rewrite it soon or later, but it's not because current one is bad, it will because a better parser tool shows up... thanks > > -- > Andrew Faulds > http://ajf.me/ > > > -- > > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #62752 — Andrew Faulds — 2012-09-03T16:05:34+00:00 URL: https://externals.io/message/62745#62752 · In reply to: #62751 > It is great parser(simple and fast) which make php works well for years.. No, it's not, it's overly complex. You have to define all sorts of different expression and variable variations :( > > […] No, because current one is constraining implementation of some things, and making some things impossible. (we are limited, for instance, in options for order that generator expressions (e.g. Python's [i*2 for i in range(6)]) could be) > > […] Well, current one is bad. It only works well for some common cases. For others, it doesn.t -- Andrew Faulds http://ajf.me/ --- ## #62753 — Laruence — 2012-09-03T16:17:44+00:00 URL: https://externals.io/message/62745#62753 · In reply to: #62752 > > > […] > > No, it's not, it's overly complex. You have to define all sorts of different > expression and variable variations :( if you don't, you will get a complex executor. > > > […] > > No, because current one is constraining implementation of some things, and > making some things impossible. (we are limited, for instance, in options for > order that generator expressions (e.g. Python's [i*2 for i in range(6)]) > could be) > > > […] > > Well, current one is bad. It only works well for some common cases. For > others, it doesn.t I really don't get it, you are saying current is bad, but every language has defects, either parser, or executor. why do you think rewrite a new parser will make every think perfect? there is no perfect language at all. thanks > > -- > Andrew Faulds > http://ajf.me/ > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #62754 — jpauli — 2012-09-03T16:21:25+00:00 URL: https://externals.io/message/62745#62754 · In reply to: #62752 We have some RFC for parser rewrite using lemon : https://wiki.php.net/rfc/lemon And AFAIR, adoy has a full working rewrite just as-is, the main topic with lemon was to make the parser thread safe, not to generate an AST. Writing a parser / compiler for using an AST is a very huge task, so that might be done. Julien.P > > > […] > > No, it's not, it's overly complex. You have to define all sorts of different > expression and variable variations :( > > > […] > > No, because current one is constraining implementation of some things, and > making some things impossible. (we are limited, for instance, in options for > order that generator expressions (e.g. Python's [i*2 for i in range(6)]) > could be) > > > […] > > Well, current one is bad. It only works well for some common cases. For > others, it doesn.t > > > -- > Andrew Faulds > http://ajf.me/ --- ## #62755 — Andrew Faulds — 2012-09-03T16:22:40+00:00 URL: https://externals.io/message/62745#62755 · In reply to: #62753 > > > […] > if you don't, you will get a complex executor. Not really, type checks are cheap. > I really don't get it, you are saying current is bad, but every > language has defects, either parser, or executor. > > why do you think rewrite a new parser will make every think perfect? > > there is no perfect language at all. I don't mean perfect, but current parser in PHP is very limiting compared to other language parsers, and it makes doing things more difficult, and creates lots of things which should work but don;t. -- Andrew Faulds http://ajf.me/