Hi!
> The issue, as you well know, is that references disable copy-on-write. Thus
> assume you have code like this:
>
> function with_ref(&$a) {
>count ($a);
> }
>
> function no_ref($a) {
> count($a);
> }
>
> The count in with_ref() will copy the array, while no_ref() can use copy on
>
Hi!
> The idea is to allow specifying declare directives for a whole library or
> project using:
>
> namespace_declare('Vendor\Lib', ['strict_types' => 1]);
I am not sure I like this. Namespace is a prefix to a class name.
Anybody can declare a class with any name, and the side-effect that t
On December 12, 2017 7:38:54 AM GMT+01:00, Stanislav Malyshev
wrote:
>Hi!
>
>> I would rather discourage usage of references. Since PHP 7 the cost
>of
>> breaking cow isn't as expensive anymore, but receiving values by
>value
>> and returning by value is more idiomatic imo. Using objects can be
Hi!
> Once issue is the PHP_BUILD_DATE, which makes the build
> non-reproducible. I've made a PR which uses SOURCE_DATE_EPOCH which is
> set in the reprodiculbe build env. This should keep the current
> functionality intact, while adding support for reproducible builds. [2]
> [3]
SOURCE_DATE_EPOC
Hi!
> I would rather discourage usage of references. Since PHP 7 the cost of
> breaking cow isn't as expensive anymore, but receiving values by value
> and returning by value is more idiomatic imo. Using objects can be more
> efficient.
Objects are kind of overkill when you just need a modifyable
Hi all,
Debian, Arch Linux and other distro's are trying to get full
reproducible builds. There are some issues in PHP's codebase which makes
builds unreproducible. Reprodicuble builds are currently reproduced in
Arch Linux by building PHP twice, and in two different env's, varying
hostname, syste
On Mon, Dec 11, 2017 at 4:46 PM, Sara Golemon wrote:
> On Mon, Dec 11, 2017 at 8:43 AM, Nikita Popov
> wrote:
> > Some time ago I introduced the following proposal for namespace-scoped
> > declares:
> >
> > https://wiki.php.net/rfc/namespace_scoped_declares
> >
> > The idea is to allow speci
On 11/12/2017 13:43, Nikita Popov wrote:
Namespace-scoped declares are perfectly suited to resolve this problem. We
can introduce a require_explicit_send_by_ref declare directive to make the
call-site annotation required, and libraries/projects can easily opt-in to
it using namespace_declare().
On Mon, Dec 11, 2017 at 8:43 AM, Nikita Popov wrote:
> Some time ago I introduced the following proposal for namespace-scoped
> declares:
>
> https://wiki.php.net/rfc/namespace_scoped_declares
>
> The idea is to allow specifying declare directives for a whole library or
> project using:
>
>
Hi internals!
Some time ago I introduced the following proposal for namespace-scoped
declares:
https://wiki.php.net/rfc/namespace_scoped_declares
The idea is to allow specifying declare directives for a whole library or
project using:
namespace_declare('Vendor\Lib', ['strict_types' => 1
>> >
>> > Obviously, the `\0` is horrible and can probably be improved: depends on
>> > whether the API is intended for human or machine consumption. If it is
>> > machine consumption, strings are the wrong approach anyway.
>>
>> Machine or human?
>> One goal is that these names can be used as arra
See http://php.net/manual/en/language.namespaces.rules.php
What you mean is a "qualified name" so it would be a QN.
On 11 December 2017 at 10:28, Marco Pivetta wrote:
> Weird, that looks wrong to me, so I may be wrong here.
>
> When receiving a string containing a symbol, the only sensible appro
Weird, that looks wrong to me, so I may be wrong here.
When receiving a string containing a symbol, the only sensible approach is
to consider it a FQN, as no context is provided with the string.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Mon, Dec 11, 2017 at 10:23
On 11 December 2017 at 10:16, Marco Pivetta wrote:
> On Mon, Dec 11, 2017 at 10:03 AM, Andreas Hennings
> wrote:
>>
>> On 11 December 2017 at 09:16, Marco Pivetta wrote:
>> > If you really want to expose a symbol's FQN,
>>
>> Just to clarify: For me, "FQN" means "fully-qualified name", which
>>
On 11 December 2017 at 08:58, Marco Pivetta wrote:
> What's the use-case for creating a userland `ReflectionType` instance,
> besides mocking the reflection API itself?
> Consider that the subclassing in userland already provides an easy way to
> perform these operations (although ugly):
> https:/
On Mon, Dec 11, 2017 at 10:03 AM, Andreas Hennings
wrote:
> On 11 December 2017 at 09:16, Marco Pivetta wrote:
> > If you really want to expose a symbol's FQN,
>
> Just to clarify: For me, "FQN" means "fully-qualified name", which
> begins with "\\".
> This is specifically not what I propose her
On 11 December 2017 at 09:16, Marco Pivetta wrote:
> If you really want to expose a symbol's FQN,
Just to clarify: For me, "FQN" means "fully-qualified name", which
begins with "\\".
This is specifically not what I propose here. I want the name without
the leading namespace separator.
So maybe "g
On 11 December 2017 at 09:23, Andreas Hennings wrote:
>>> These side effects would be that the class loader loads files which can
>>> break things?
>>
>>
>> Yes. Reflecting over a codebase which contains even just polyfills
>> (duplicate classes) can already lead to unexpected crashes. Reflecting
>> These side effects would be that the class loader loads files which can
>> break things?
>
>
> Yes. Reflecting over a codebase which contains even just polyfills
> (duplicate classes) can already lead to unexpected crashes. Reflecting over
> non-PSR-2 code can even lead to worse things such as s
On 11 Dec 2017 09:10, "Andreas Hennings" wrote:
On 11 December 2017 at 09:05, Marco Pivetta wrote:
> On 11 December 2017 at 08:46, Marco Pivetta wrote:
> > Indeed that already exists at
> > https://github.com/Roave/BetterReflection/blob/2.0.1/docs/fe
> atures.md#analysing-types-from-docblock
If you really want to expose a symbol's FQN, I suggest exposing the
internal name as per `(array)` cast semantics.
namespace A {
class B {
public $c;
private $d;
private $e;
}
}
That would be:
"A\B#\$c"
"A\B#\0*\0\$d"
"A\B#\0A\\B\0\$e"
Obviously, the `\0` is horr
On 11 December 2017 at 09:05, Marco Pivetta wrote:
> On 11 December 2017 at 08:46, Marco Pivetta wrote:
> > Indeed that already exists at
> > https://github.com/Roave/BetterReflection/blob/2.0.1/docs/
> features.md#analysing-types-from-docblocks
> > - relatively new lib, so it probably didn't ge
On 11 Dec 2017 04:04, "Andreas Hennings" wrote:
So far this proposal only discusses reflections of PHP declarations /
symbols.
What would we do for e.g. ReflectionObject?
Return the spl_object_hash()?
Or return the hash of the instantiated class?
Or a hash of the serialized object?
We need to re
On 11 December 2017 at 08:46, Marco Pivetta wrote:
> Indeed that already exists at
> https://github.com/Roave/BetterReflection/blob/2.0.1/
docs/features.md#analysing-types-from-docblocks
> - relatively new lib, so it probably didn't get noticed upfront in here.
Yes, parser / userland solutions e
24 matches
Mail list logo
