Hi, internals!
I want to mention, that all existing internal API of Zend could be
accessible via FFI as of PHP7.4. This gives opportunity to implement
userspace operator overloading as a simple PHP package.
I know, that FFI requires some polishing, but it could become a tool to
create interesting
Hello, internals team!
I would like to propose to rename the PhpToken::getAll() method into the
PhpToken::tokenize(string $source) or PhpToken::lex(string $source) to use
a more meaningful verb word.
After renaming, it will sound more natural: $tokenStream =
PhpToken::tokenize($sourceCode)
Best
In some distant future it could be implemented in more natural way with
classes for primitive types and automatic boxing/unboxing for primitive
built-in types:
Php\Type\Object
Php\Type\Scalar
⌊ Php\Type\String
⌊ Php\Type\Integer
⌊ Php\Type\Float
⌊ Php\Type\Boolean
Php\Type\Array
And i
flectionParameter API.
What is your opinion about this? Thanks!
Best regards,
Alexander Lisachenko
Hi, internals!
Just quick idea: what about moving from old-school mailing list with
unclear subscription logic and ugly interface to the RFC project on GitHub?
Maybe https://github.com/php/rfc or similar.
There are cases when language developers actively use GitHub for
maintaining RFC-s, label the
2016-12-29 16:12 GMT+03:00 Mathieu Rochette :
> I find that using the decorator pattern is very verbose and maybe
> something could be done about that,
> an article[1] I saw proposed a "decorates" keyword to solves this, here is
> how it might look like in PHP:
>
> * the constructor is optional
There was small typo in my previous link to object comparison: new one is
https://3v4l.org/tMokY
2016-12-27 14:33 GMT+03:00 Alexander Lisachenko :
> Hi, internals!
>
> I want to propose to deprecate one more weird feature of PHP called
> "comparison of different types" ht
Hi, internals!
I want to propose to deprecate one more weird feature of PHP called
"comparison of different types"
http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.types.
Here you can check one simple example https://3v4l.org/kCOAf to see why it
should be d
Hi, internals!
Today I detected interesting difference in getting prototype methods with
reflection API.
Could you please check this https://3v4l.org/LLebD
Was it intended change?
Thanks!
2016-08-23 18:05 GMT+03:00 Lauri Kenttä :
> Could you do it without reflection, then? I don't think so.
> Thus, I think your "use case" is broken by design.
>
FYI: This use case is used by Go! AOP Framework and AspectMock libraries
that can mock even static methods in the classes, allowing testi
2016-08-23 16:40 GMT+03:00 Julien Pauli :
> My patch allows that, but I can't find a use case to it.
My use case for that was decorating of static methods with additional
behaviour, so it's possible to cache the result of static methods, etc.
Unfortunately, reflection API doesn't provide me suc
2016-08-23 16:13 GMT+03:00 Julien Pauli :
>
> No, How can this be ? B extends A , not A extends B ...
> In this case, B'sfoo() will be called , which is the equivalent to
> having a reflectionMethod from B , so useless to me.
Ok, how can I invoke Parent::whoami() with reflection and get exactl
2016-08-23 16:01 GMT+03:00 Julien Pauli :
> This :
>
> class A { public static function foo() { } }
> class B extends A { public static function foo() { } }
>
> $a = new reflectionMethod('A', 'foo');
> $a->invoke('B');
>
It's perfect way for me.
Just to be sure: in this case we will invoke A::f
2016-08-23 14:51 GMT+03:00 Christoph M. Becker :
> I suggest to deprecate all other types than NULL as first arg for static
> methods, because passing an int, for instance, makes even less sense as
> Rowan has already pointed out elsewhere in this thread.
>
Alternative suggestion (vote for Julie
First argument can be a normal string with a valid scope class name for
static methods. This can be useful for calling parent static methods, see
my example.
I think this will be comparable with Closure::call() method and scope
binding.
понедельник, 22 августа 2016 г. пользователь Rowan Collins н
Hello, there is one more issue with ReflectionMethod::invoke() for static
methods: it's impossible to call an overridden parent static method and
preserve a scope information:
// https://3v4l.org/ASntq
class foo
{
static function bar()
{
echo self::class, ' vs ', static::class, PH
If the first argument for invoke() and invokeArgs() for static methods will
be a string with compatible class name for the scope, then it can be used
as a scope modifier (like second argument for Closure::bind($instance,
$scopeClassName))
2016-08-22 17:29 GMT+03:00 Alexander Lisachenko :
> He
Nikita, Dmitry, ping. What do you think, shouldn't we replace all possible
places with Fatal Errors with correct throwing of Error exceptions? In
this concrete case it's for "require" operator.
>From what I can see Error will give us more control over the file loading
process and make it more ato
2016-06-15 22:28 GMT+03:00 Niklas Keller :
> didn't read it was planned for all file functions.
Let's restrict my first suggestion only for "require" expression for now.
So proposal is following:
Rewrite "require" to throw an Error instead of current Fatal Error if some
file can not be loaded.
Hi, internals!
For PHP7 we have pretty errors for almost everything, even eval can throw a
ParseError exception, but not for the require expression, because it's
still producing an uncatchable fatal errors:
try {
require('no.php');
} catch (Throwable $e) {
echo 'Catch!';
} finally {
e
Hello, internals!
2016-05-05 9:48 GMT+03:00 Stanislav Malyshev :
> Maybe that's what we want to have here - freedom for everybody to invent
> their own languages - but I fear the danger of fragmentation here and
> also people implementing tons of slightly different incompatible parsers
> for AST
2016-04-26 11:15 GMT+03:00 Nikita Popov :
> As an update here, I plan to create an RFC for bundling the php-ast
> extension (maybe with minor modifications) with php-src. This was planned
> for 7.1 anyway, and with the annotations RFC under discussion, this seems
> like a good time.
>
...
>
I'll t
o the core,
providing an API via static class, for example "Php\Parser".
2015-03-03 19:12 GMT+03:00 Leigh :
> On 3 March 2015 at 11:56, Alexander Lisachenko
> wrote:
> > Good morning!
> >
> > I have cleaned https://wiki.php.net/rfc/parser-extension-api and
> re
Hello, internals!
Go! AOP was used closure rebinding to an incompatible context only for one
minor specific feature, called privileged advices, where method was
executing in the context of target class. But all main closure binding in
the framework core work only with compatible contexts, so every
2016-01-05 2:04 GMT+03:00 Andrea Faulds :
> I agree that we could do something with interfaces. I would like to point
> out that we actually already have an example of this, in the form of the
> \ArrayAccess interface, which requires you to implement all the different
> indexing operations at once
Hello, internals!
We discussed this topic early, see this thread:
http://www.serverphorums.com/read.php?7,1123371,1124223 for any additional
thoughts and ideas. I want to attach a link to the Java draft of partial
immutability of objects:
http://cr.openjdk.java.net/~jrose/values/values-0.html, it'
2015-11-02 12:22 GMT+03:00 Rowan Collins :
> Should they? func_get_args() can be used to simulate any function
> signature, so you could equally say that the following are "compatible":
Hello! Thank you for the answer.
However, question is not about func_get_args() at all, it can be removed to
Hello, internals!
I have a question about changed behavior in 7.0 for matching signature of
variadic method.
Here is an example of code:
class Foo {
public static function test($bar = null) {
var_dump(func_get_args());
}
}
class Baz extends Foo {
public static function test(
2015-10-22 18:48 GMT+03:00 Julien Pauli :
> This is very tricky use case IMO.
>
> We should absolutely focus on stability, and if we can't find a way to
> make things safe, we forbid them
> for the stability sake. If there are no way to have stable things,
> well, that's pitty but it's like that.
2015-10-19 12:19 GMT+03:00 Nikita Popov :
> This change is primarily targeting userland methods, so your use-case is
> exactly the one this is supposed to prevent. Note that you can still use
> ->bindTo($object). The only thing you cannot do is ->bindTo($object,
> get_class($object)).
It's very
Hello, internals!
Just noticed this thread and want to clarify some things with getClosure()
method. If i understood correctly, ReflectionFunctionAbstract::getClosure()
should return non-rebindable closure ONLY for internal functions, but for
userland functions binding should be still possible, ri
2015-08-03 16:10 GMT+03:00 Etienne Kneuss :
> As for PHP, It seems like what people actually want is a unique identifier
> for objects (for the lifetime of the request), but they compromise and use
> the handle instead as it is available without userland counter.
Probable, there is no actual nee
Hello, internals!
I like the idea to assign a custom identifier to the object, but why this
should be only in the core? Java has a method 'hashCode' which can be used
to return an unique identifier for specific object. So, my suggestion is to
add 'Hashable' interface for that into the PHP.
Then,
Hello, internals!
I remember the crazy code for invalidating the opcache/realpath entries
from CLI.
Logic was the following: tool asks for the server name with php-fpm to
connect to via ssh connection, then it prepares a small PHP-file and
uploads it to the temp directory on this server and then
I want to mention
http://php.net/manual/en/opcache.configuration.php#ini.opcache.enable-file-override
option, that can cache positive checks information between subsequent
requests.
Thanks!
2015-03-20 9:13 GMT+03:00 Stanislav Malyshev :
> Hi!
>
> > We're doing some performance work in WinCache,
Hello!
2015-03-05 22:40 GMT+03:00 Anthony Ferrara :
> This requires use to immediately follow namespace declarations:
>
> namespace Foo {
> use Bar; //valid
> }
> namespace Bar {
> use Foo; //valid, second namespace in file
> }
> namespace Baz {
> echo "Hi!";
> use Foo; // Invalid
Good morning!
I have cleaned https://wiki.php.net/rfc/parser-extension-api and restricted
it's scope only to the parsing API. Extension API can be implemented later
on top of
https://github.com/php/php-src/commit/1010b0ea4f4b9f96ae744f04c1191ac228580e48
and current implementation, because it requi
2015-02-25 13:37 GMT+03:00 Thomas Gielfeldt :
> Yeah, but the "problem" with this, is that your class' sort method, you
> have to implement all the possible permutations the flags can produce. This
> basically just squeezes the 11 functions into 1. The 1 interface with
> sort() and usort() splits
2015-02-25 13:21 GMT+03:00 Thomas Gielfeldt :
> I have some more proposals for how to implement this interface. Should we
> create an RFC for purposes of discussion, or do you usually do this in the
> mailing lists?
>
Best interface is described by the one single method: sort() that accepts
opti
Morning!
I want to ask this question one more time before PHP7 feature freeze: can
we the engine case sensitive from PHP>=7.0?
There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals mail
list.
Pros: more simple O(1
with public properties, but only
children field will be a generator.
What do you think?
2015-02-18 22:34 GMT+03:00 Alexander Lisachenko :
>
> 2015-02-18 22:22 GMT+03:00 Dmitry Stogov :
>
>> I think the AST API shouldn't use "public" properties.
>> Using it, we w
2015-02-18 22:22 GMT+03:00 Dmitry Stogov :
> I think the AST API shouldn't use "public" properties.
> Using it, we will have to construct the whole tree of objects, duplicating
> information from AST.
> I would propose SimpleXML approach instead - construct object only for
> node(s) we currently a
> I'm okay with having stuff like ->getKindName() on the nodes, however I'd
> still keep around the free-standing functions, because they can be used
> without a node (i.e. you only need the kind AST_FOO and not an instantiated
> node).
I think that getting name of kind is useless without value o
2015-02-18 17:59 GMT+03:00 Nikita Popov :
> Alexander, I would recommend you to split this into two RFCs, one dealing
> only with AST export (and maybe pretty printing) and the second one with
> the compilation hooks. There's probably a few questions about the export
> API that should be discussed
2015-02-17 20:35 GMT+03:00 Tim Bezhashvyly :
> this is my first RFC proposal and I am not sure if in this email is
> supposed to contain all RFC details or just a brief idea .. which is to
> drop PHP constants in favour of “final" immutable variables.
Hello, Tim
Recently, I asked this question
Hello, Lars!
2015-02-17 22:09 GMT+03:00 Lars Strojny :
> Looks cool and I could see a couple of interesting possibilities arising.
> One thing: any particular reason ExtensionInterface is static? I could see
> a couple of benefits having extensions carry state and registerExtension()
> taking an
2015-02-17 19:25 GMT+03:00 Dmitry Stogov :
> I think yes,
> However, Alexander thinks differently
> https://wiki.php.net/rfc/parser-extension-api
> Of course this is not for 7.0
>
This RFC consists of two parts: parsing API and parser extension API. Last
one can be rejected, however it can be per
2015-02-17 16:35 GMT+03:00 Rowan Collins :
> I think "should" is OK for extensions, but not for userland hooks. There
> needs to be a very firm definition of the right and wrong way to implement
> these hooks, which can at the very least warn the user when they are
> slipping into undefined behavi
2015-02-17 15:48 GMT+03:00 Leigh :
> So: Internal Parse AST -> Extension Parse AST -> Generate OpCodes ->
> OpCache?
>
Yes, it's correct flow.
2015-02-17 15:48 GMT+03:00 Leigh :
> So if the parser extension does anything dynamic, then OpCache will
> have the wrong version cached.
>
This restri
2015-02-17 15:29 GMT+03:00 Benjamin Eberlei :
> Well not really, depending on the path towards a require a parser
> extension is already registered or not. Or you have conditional
> registration of extensions. So you could load a file with an extension
> registered, but it still serves the old opc
2015-02-17 15:09 GMT+03:00 Benjamin Eberlei :
> The visitor API is the essential part here and you left it out.
Yes, I decided not to put Visitor in the RFC (this was added as open
question to the RFC). But this part can be discussed in the case of general
acceptance.
2015-02-17 15:09 GMT+03:0
2015-02-17 15:06 GMT+03:00 Leigh :
> Does the AST provided by the internal parser provide all of the
> information required to be able to turn it back into source code?
>
> Yes, this should be possible, via zend_emit_op*() and zend_compile*()
2015-02-17 15:06 GMT+03:00 Leigh :
> Re: Extending t
Hello, internals!
I want to introduce a RFC for providing a userland API for accessing an
Abstract Syntax Tree of the source code and to provide userland parser
hooks for source code modification:
https://wiki.php.net/rfc/parser-extension-api
Thanks!
2015-02-16 15:31 GMT+03:00 Benjamin Eberlei :
>
> My question is how do i evaluate this at runtime? I suppose a function is
> necessary like evaluate_ast(...), but that requires passing the context.
> many many open questions and as nikic points out this should probably be
> delayed to 7.1 becaus
2015-02-16 15:12 GMT+03:00 Benjamin Eberlei :
> but what is the API of an AST node and how does the visitor look like?
I have a draft for that:
https://gist.github.com/lisachenko/ffcfdec4c46e01864b33 This is extended
version for php-ast extension that I want to propose for PHP.
2015-02-16 14:42 GMT+03:00 Dmitry Stogov :
> the idea to not evaluate non-constant expressions at all, but just keep
> AST and provide interface to read it.
> PHP extensions should be able to use them as they like. (evaluate or
> insert into AST of function(s), etc).
>
> Thanks. Dmitry.
It's a
2015-02-16 14:19 GMT+03:00 Dmitry Stogov :
> annotations ::= { annotation }.
> annotation ::= '<' STRING '>' | '<' STRING '(' expr ')' '>'.
>
> where is regular PHP expression.
Hello!
Really like this syntax, actually you steal my thoughts )) I want to call
this metadata, not an annotations
2015-02-10 15:35 GMT+03:00 Pavel Kouřil :
> Hello,
>
> maybe you could try to consult your ideas with Ivan Enderlin. He
> mentioned in previous emails (for instance
> http://news.php.net/php.internals/82245) that he would prefer some
> AOP/hook-based approach to DbC as well, so it may be compatibl
2015-02-10 15:20 GMT+03:00 Dmitry Stogov :
> I thought about this way, and you are welcome to start composing another
> RFC. it makes sense and has its advantages.
> Unfortunately, it relays on many unavailable features that has to be
> designed as well (annotations, AST manipulation, opcode manip
2015-02-10 15:10 GMT+03:00 Alexander Lisachenko :
> I would like to see a language with good extension API. For now, it's
> almost impossible to extend a parser, even from extension level (however,
> PHP7 will have a hook for that, thanks God).
To understand how it can be imp
2015-02-10 14:56 GMT+03:00 Patrick Schaaf :
> Ahem. Any open ended API-for-frameworks will A) force me to pick a
> framework and bend to the way it wants these things to look, and B) result
> in fragmentation and incompatibilities for any two pieces of code/library
> developed with different such
Hello, internals!
DbC is good thing, but the way you want to do this via language changes is
really awful. Why do you want to add more custom features into the
language, instead of providing an API to extend it in a more natural way by
framework developers?
Many existing implementation of DbC is
2015-02-05 16:07 GMT+03:00 Dmitry Stogov :
> In general it's should be possible to provide PHP API to manipulate with
> AST and write compiler extensions in PHP.
> Looks promising.. :)
> Anyway, If you are interested - start working on it.
Actually, it's almost done by Nikita Popov: https://git
2015-02-05 15:32 GMT+03:00 Dmitry Stogov :
> Hi Alexander,
>
> Defining contracts through doc-comments is also possible, but this way is
> not native.
> On the other hand, if you already have this implemented, we may just reuse
> it.
>
Thanks, Dmitry! This would be a really nice feature on engin
So, is it possible to use annotations for defining such metadata on
engine-level? This will be a good way to do this and to define custom
handlers via AST hooks, that can be able to patch method definition node
with concrete opcodes.
2015-02-05 15:24 GMT+03:00 Alexander Lisachenko :
> He
Hello, internals!
>From my point of view, contracts should not affect execution of source code
in production env, or can be enabled partially. I have implemented DbC
paradigm on top of the AOP layer, so each contract can be defined via
annotation and looks pretty nice, for example :
use PhpDeal\A
I want to add a link here to the Java article about Value Types, this
information is quite interesting:
http://cr.openjdk.java.net/~jrose/values/values-0.html
Probably, immutable value objects will be soon in Java world according to
this information:
> Conclusion
>
> Along with the questions, we
Hello, internals!
2015-02-01 4:01 GMT+03:00 Andrea Faulds :
> I think having some means to create value type classes (i.e. PHP 4-style
> classes) would be beneficial. These classes would have the same always-copy
> or copy-on-write behaviour that PHP’s scalar types and arrays have. They’d
> be pe
Faulds написал:
> Hi,
>
> This accidentally went off-list, forwarding for everyone else’s sake.
>
> > Begin forwarded message:
> >
> > Date: 30 January 2015 16:01:43 GMT
> > Subject: Re: [PHP-DEV] [RFC] Immutable variables and objects
> > From: Al
maybe a
direct Copy-on-Write?
$mutableSubRequest->uri = 'https://example.com'; // It's ok to modify
our local copy of an object
$this->kernel->handleRequest($mutableSubRequest);
}
2015-01-30 18:07 GMT+03:00 Andrea Faulds :
> Hi Alexander,
>
> &g
Hello, internals!
Today I was looking at PSR-7 and discovered this part of code:
$body = new StringStream(json_encode(['tasks' => [
'Code',
'Coffee',
]]));;
$request = $baseRequest
->withUri($uri->withPath('/tasks/user/' . $userId))
->withMethod('POST')
->withHeader('Content-T
Hi!
2014-11-18 12:20 GMT+03:00 Stanislav Malyshev :
>
> I'd like to propose the following RFC, which in short would allow any
> method to call parent ctor (and some other methods) even if such is not
> explicitly defined:
+1 for defining base class for all classes and addition of default
constr
2014-11-05 17:02 GMT+03:00 Marco Pivetta :
> For example, this alternative approach perfectly fits the current
> doctrine/annotations use-case:
>
> use Doctrine\ORM\Mapping\Entity;
> use Doctrine\ORM\Mapping\Table;
> use Doctrine\ORM\Mapping\Id;
> use Doctrine\ORM\Mapping\GeneratedValue;
> use Doc
Hi!
It would be nice to take "paving the walkways" approach, but last time
> we tried, IIRC we've got into something very over-engineered. Maybe if
> we try again with more restricted scope (i.e. not trying to put a DSL
> for describing arbitrarily complex data structures into it :) it would
> be
Hello, internals!
> The name __hash is not final, I am open to using __toKey instead or any
> reasonable alternative, we may also include a couple of options in the
> vote if that will be a point of disagreement.
I like this idea with custom hash implementation because spl_object_hash()
is not re
Hello, internals!
> Good evening,
>
> I am presenting a new RFC to add a set of three functions to do validated
> casts for scalar types:
>
> https://wiki.php.net/rfc/safe_cast
>
> Please read it.
Personally I don't like this RFC because it's introducing one more way
to cast value in PHP. We alr
Hello!
> I've written an RFC which proposes to expose a namespace aliases/imports for
> user-land code.
>
> https://wiki.php.net/rfc/aliases_by_reflection
I think that this idea is good, however it isn't correct to keep
aliases per each class, because they are applied per scope.
TokenReflection l
Hi!
Maybe it will be better to do this in another way: introduce an RFC to
add 'deprecated' keyword into the syntax like 'final' or 'protected'.
There are many frameworks that want to deprecate some methods or
classes. Currently it's only possible via "@deprecated" tag in the
phpDoc-block, but thi
78 matches
Mail list logo
