Hello,
I would like to start with an example:
<?php
class A {
public static function foo ( ) {
return 'foo';
}
}
class B {
protected $a = null;
public function __construct ( ) {
$this->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/
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/
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.
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/
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/
Absolutely.
PHP has no AST? Why? For historical reasons?
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/
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.
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/
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 :(rewrite the parser for what? for more academism?
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)
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...
Well, current one is bad. It only works well for some common cases. For
others, it doesn.t
--
Andrew Faulds
http://ajf.me/
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 :(
if you don't, you will get a complex executor.
rewrite the parser for what? for more academism?
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)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...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/
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 :(
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/
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
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 :(rewrite the parser for what? for more academism?
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)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...Well, current one is bad. It only works well for some common cases. For
others, it doesn.t--
Andrew Faulds
http://ajf.me/