Re: [PHP-DEV] [RFC] Allow ::class on objects

> > $fooClass = Foo::class; > > echo $foo::class; // TypeError b/c string? > > Yes, at least per the current proposal. Whether to allow this is listed as > an open question. > I missed that part! If it could return `string`, that'd be super useful! We have tons of lines of code that

Re: [PHP-DEV] [RFC] Static return type

> Of course this ": $this" could be added later in the future. > But this would have the risk that people start adding ": static" on methods > that really return $this. > I second $this. I also would like to be able to declare `function foo(): $this` at the same time as `function foo(): static`

[PHP-DEV] Re: Preloading experiments with Symfony

Hello, I didn't get any response to my email from June 17th, yet I think this is pretty critical, see below. I did not manage to make preloading with Symfony yet, see https://bugs.php.net/78512 also? Thanks for considering, the behavior is unexpected to me, as it deviates from common behavior. I

Re: [PHP-DEV] [RFC] Union Types v2

> > https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md Thank you Nikita, this would be a hugely welcomed step forward! Can't wait to get rid of all those docblock annotations! I've some additional suggestions that would greatly help remove more docblocks and provide

Re: [PHP-DEV] get_class_vars() and typed properties

Le dim. 18 août 2019 à 11:59, Benjamin Morel a écrit : > Hi Internals, I just noticed the following behaviour: > > class A { > public int $a; > public ?int $b; > public ?int $c = null; > } > > $a = new A; > > var_export(get_object_vars($a)); >

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

Le lun. 11 déc. 2017 à 14:44, Nikita Popov a écrit : > 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: > >

Re: [PHP-DEV] Adding return types to internal methods (PHP 8)

Le dim. 11 août 2019 à 15:24, Nikita Popov a écrit : > On Sun, Aug 11, 2019 at 3:01 PM Sara Golemon wrote: > > > On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov > wrote: > > > >> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon wrote: > >> > P.S. - Perhaps a way to the middle might be to introduce

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

Le mar. 6 août 2019 à 13:34, G. P. B. a écrit : > The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at >

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Le mar. 30 juil. 2019 à 10:34, Rowan Collins a écrit : > On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas > wrote: > > > I think enough time has passed since php4's call-by-ref for the syntax to > > be > > reused now. I think it's unfair to call the RFC a reminis

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Le mer. 6 déc. 2017 à 20:50, Nikita Popov a écrit : > Hi internals, > > I'd like propose optional support for explicitly marking by-reference > argument passing at the call-site, in addition to the declaration-site: > > https://wiki.php.net/rfc/explicit_send_by_ref > > In short, while

Re: [PHP-DEV] Stop replacing dots with underscores in query, post and cookie parameters for PHP 8?

Le mar. 16 juil. 2019 à 09:51, Nikita Popov a écrit : > On Tue, Jul 16, 2019 at 3:40 AM Arnold Daniels < > arnold.adaniels...@gmail.com> > wrote: > > > Hi, > > > > PHP replaces dots with underscores for $_GET, $_POST and $_COOKIE. This > > behavior once made sense because of Register globals.

[PHP-DEV] Preloading experiments with Symfony

Hello, I experimented with preload on a small Symfony app. I have two segfaults on my patch to make it work, reported here: https://bugs.php.net/bug.php?id=78175 I also opened https://bugs.php.net/bug.php?id=78169 but were asked to raise the point on the list: When opcache.preload is used,

Re: [PHP-DEV] Re: JSON_THROW_ON_ERROR implementation detail

Hi, Le ven. 24 mai 2019 à 01:55, Andrea Faulds a écrit : > > Please see the discussion on the original pull request: > https://github.com/php/php-src/pull/2662 > > The existing behaviour is deliberate, was already discussed, and was > Symfony is affected too, could you please have a look at

Re: [PHP-DEV] Proposal for a RFC

Le sam. 4 mai 2019 à 18:37, Marco Pivetta a écrit : > Hi Steven, > > As it currently stands, the array cast is the only operation capable of > exposing object state without triggering any kind of access guards: it is > very much required for anything that works with reflection and typed >

Re: [PHP-DEV] [VOTE] New custom object serialization mechanism

> How do people feel about deprecating Serializable in 7.4 and > removing in 8.0 (not as part of this RFC but a separate one)? The > deprecation warning would only be thrown if Serializable is implemented but > the class has no __serialize/__unserialize. The timeline would be a bit > aggressive in

[PHP-DEV] Re: [RFC] New custom object serialization mechanism

Le mar. 19 févr. 2019 à 11:31, Nikita Popov a écrit : > On Mon, Feb 18, 2019 at 4:12 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> Hi Nikita, >> >> I'd like to propose a new custom object serialization mechanism intended >>> to

[PHP-DEV] Re: [RFC] New custom object serialization mechanism

Hi Nikita, I'd like to propose a new custom object serialization mechanism intended to > replace the broken Serializable interface: > > https://wiki.php.net/rfc/custom_object_serialization > > This was already previously discussed in > https://externals.io/message/98834, this just brings it into

Re: [PHP-DEV] [RFC] JIT

> [...] I think that whether or not we include it in 7.4 > is a tactical decision (and I'm not sure myself where I stand on it), but I > do think there's a reasonable case for both directions. > If I may add some voice to Zeev's arguments, being able to play with JIT as early as possible would

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

> https://wiki.php.net/rfc/consistent_type_errors >> >> >> Would it make sense and be possible to trigger a deprecation notice in >> PHP 7.4? >> >> That might help the ecosystem move forward in a smooth way instead of >> experimenting the failure when actually moving to 8. >> > > We generally

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

Hi Nikita https://wiki.php.net/rfc/consistent_type_errors Would it make sense and be possible to trigger a deprecation notice in PHP 7.4? That might help the ecosystem move forward in a smooth way instead of experimenting the failure when actually moving to 8. Nicolas

Re: [PHP-DEV] [RFC] Reflection for references

> > I'd like to move forward with the RFC as is -- I'm uncomfortable with > switching this to a simple XOR for security reasons. I think we should > start off with the current implementation, with the option of switching to > an integer return value at a later time. > Works for me, thank you!

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

(I should have reviewed myself in the first message - sentences edited in this reply) Le lun. 28 janv. 2019 à 08:58, Marco Pivetta a écrit : > On Sun, Jan 27, 2019 at 5:37 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> Le jeu. 24 janv. 2019 à 15:1

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

Le jeu. 24 janv. 2019 à 15:18, Sebastian Bergmann a écrit : > Am 24.01.2019 um 15:09 schrieb Marco Pivetta: > > Not really fussed about having another implicit interface for > serialization > > (via magic methods). > > I second that emotion. > The more I think about it, the more I'm convinced

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

Thank you Nikita, the RFC looks solid to me. Using magic methods makes perfect sense to allow a smooth migration path. We could enforce that if one of __serialize() or __unserialize() is > defined, both have to be defined, to avoid running into such cases. That would make sense a lot of sense

Re: [PHP-DEV] [RFC] Reflection for references

About using "int" as return type for getId(): > * Can the `getId()` return type be restricted to either `int` or > > `string`? Why is it a union type right now? Technical limitation? > > To allow changes in the future. The real return value here is an int, but > the size increase due to hashing

Re: [PHP-DEV] [RFC] Reflection for references

Thank you Nikita, I will definitely need that RFC! Answering to Marco: * `ReflectionReference` seems to be designed around arrays only: maybe > `ReflectionArrayKeyReference` or such? > I agree with the wording in the RFC: the array is the primitive data structure in PHP that holds references.

Re: [PHP-DEV] Password Digest Registry

> > Opening https://wiki.php.net/rfc/password_registry for discussion. > Should the registry support password hashing mechanisms defined in script > code? (I don't think so, but feel free to disagree) > Not for disagreeing but for the discussion: allowing userland to provide algos would allow

[PHP-DEV] setcookie() doesn't follow the RFC in 7.3

Hi all, yesterday I submitted https://bugs.php.net/76906 to report that I wasn't able to set the "samesite" attribute on cookies while I followed what's been approved in https://wiki.php.net/rfc/same-site-cookie Damian answered on the bug report that the $options argument has swallowed the

[PHP-DEV] Getting rid of PHP_Incomplete_Class and "unserialize_callback_func"

Hello, I recently submitted https://bugs.php.net/76681: Make unserialize() handle a new "callback" option entry The full story is that I'd like a way to get rid of any PHP_Incomplete_Class in my code. The way to do it currently is to change the "unserialize_callback_func" ini setting at runtime

[PHP-DEV] Deprecations for PHP 7.4, preparing named args

Hello, I was reading https://wiki.php.net/rfc/named_params again. Named args would be great for 8.x. Following https://wiki.php.net/rfc/deprecations_php_7_4, would it make sense to deprecate calling `call_user_func_array` with associative arrays, so that it can be made to work with named args in

Re: [PHP-DEV] [RFC] Typed Properties

Le mar. 10 juil. 2018 à 14:56, Zeev Suraski a écrit : > On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalhães wrote: > >> On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski wrote: >> >>> I've also given several examples - some of them arguably quite bigger >>> than >>> this proposal - where we sat on

Re: [PHP-DEV] [RFC] Typed Properties

2018-07-10 11:18 GMT+02:00 Marco Pivetta : > It's been a few weeks since this has first landed here, and we're just > wasting time in relatively silly discussions at this point: > > - As I said earlier, this patch has already been tested against some > extremely tricky scenarios, so from a

Re: [PHP-DEV] Introspection for references

> > If we're seeking for a benefit, it would be by turning this to a >> ReflectionZval insteaf of ReflectionReference. There would be isRef, but >> also getType, etc. But honeslty I'm with you on this, only refs make sense. >> > > I'm wondering if there is any legitimate use for something like

Re: [PHP-DEV] Introspection for references

> Before talking about solutions, can the people who need this first outline >>> what functionality is needed and what it is needed for (and maybe what >>> workarounds you currently use). E.g. do you only need to know whether >>> something is a reference, or do you need to know whether two

Re: [PHP-DEV] Introspection for references

Hi Nikita, Before talking about solutions, can the people who need this first outline > what functionality is needed and what it is needed for (and maybe what > workarounds you currently use). E.g. do you only need to know whether > something is a reference, or do you need to know whether two

Re: [PHP-DEV] [RFC] Typed Properties

Le jeu. 21 juin 2018 à 19:37, Nicolas Grekas a écrit : > if ((new ReflectionReference($array[$key]))->getRefcount() > 2) { /* is >> ref */ } else { /* not a ref */ }, for computing the allowed types you’d >> intersect the types of the ReflectionProperties returned by >&g

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

> https://wiki.php.net/rfc/deprecations_php_7_3 > Do you think we could ass Serializable to the list? See your own arguments in https://externals.io/message/98834 :) Nicolas

Re: [PHP-DEV] [RFC] Typed Properties

> > if ((new ReflectionReference($array[$key]))->getRefcount() > 2) { /* is > ref */ } else { /* not a ref */ }, for computing the allowed types you’d > intersect the types of the ReflectionProperties returned by > getReferencingProperties(). > Would work also I suppose, sounds good thanks for

Re: [PHP-DEV] [RFC] Typed Properties

> something like a ReflectionReference class, which will give you the > referencing properties via ReflectionProperty instances > I may not have the object when walking on data structures, but only the reference (in an array.) It could work this way I suppose:

Re: [PHP-DEV] [RFC] Typed Properties

Hi Nikita, Bob, https://wiki.php.net/rfc/typed_properties_v2 > This is really well thought and written, sounds really primising. I agree that "References without intrinsic type" look the best. I anticipate one case on Symfony VarDumper that will break on typed references: the only way to

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

> It returns `?array`. So either `null` or `[$key, $value]`. There are > no notices; sorry for the lack of detail. > See https://3v4l.org/2hX3Y for example

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

> if ([$key, $value] = array_last($input) { > +1 for this proposal, I would even go one step further and suggest a single function, with an index as second argument: `if ([$key, $value] = array_index($input, $index) {` when `0 === $index` => returns the first, `-1 === $index` returns the

Re: [PHP-DEV] A replacement for the Serializable interface

Please allow me to up vote for this proposal. I'm working on some serialization logic these days, and `Serializable` is totally broken: it breaks internal references in serialized data structures, and breaks custom serializers (e.g. igbinaryà from inspecting nested structures. The proposal here

[PHP-DEV] Performance optimization ideas for PHP 7.3

Hello internals, During the last months, I've been working on optimizing Symfony/Twig for PHP7. I found a few situations where the PHP engine could likely be optimized, and where it would benefit real-world apps. In each case, these might look like micro-optimizations, but they are not in hot

[PHP-DEV] Session extension cannot be used in a loop/CLI since 7.2

Hello, I'm having a hard time fixing Symfony's tests suite to 7.2 because of the added warnings+ini_set-rejections in the Session module. Testing the session on the CLI is not possible anymore without starting one PHP process per test case. Why not, you may say. BUT, this also means that the

[PHP-DEV] Don't add simple objects to GC's roots

Hi, I'm hitting more and more the GC threshold in projects I work on (the "10k roots" one), leading to high CPU usage. Usually, the GC finds nothing to clean, so this is just a waste of CPU. By being super light and fast, objects are nice for many tasks, and the trend is to use them all over the

Re: [PHP-DEV] BC break in master (7.2) - Distinguish betweenunmatchedsubpatterns and empty matches in preg_*()

> > PREG_SKIP_UNMATCHED instead of PREG_UNMATCHED_AS_NULL. > I'm just wondering if having holes in the resulting array is a good idea. It may complicate reading dumps and forces using "foreach" vs "for". I'm also wondering if the original proposal wouldn't be better (having NULL for *all*

Re: [PHP-DEV] BC break in master (7.2) - Distinguish between unmatched subpatterns and empty matches in preg_*()

2017-05-15 17:21 GMT+02:00 Sara Golemon <poll...@php.net>: > On Mon, May 15, 2017 at 6:36 AM, Nicolas Grekas > <nicolas.gre...@gmail.com> wrote: > >> I agree that a minimum 5 years old possible bug, quite small, causing > >> BC breaks is not good. As far as

Re: [PHP-DEV] BC break in master (7.2) - Distinguish between unmatched subpatterns and empty matches in preg_*()

Thanks Pierre, 2017-05-15 12:12 GMT+02:00 Pierre Joye <pierre@gmail.com>: > hi Nicolas, > > On Mon, May 15, 2017 at 1:57 PM, Nicolas Grekas > <nicolas.gre...@gmail.com> wrote: > > Hi, > > > > in master, feature request https://bugs.php.net/6

[PHP-DEV] BC break in master (7.2) - Distinguish between unmatched subpatterns and empty matches in preg_*()

Hi, in master, feature request https://bugs.php.net/61780 has been implemented and merged into master thanks to https://github.com/php/php-src/pull/1303 But as noted in the PR and even in the UPGRADING file, this is a BC break: . preg_match() and other PCRE functions now distinguish between

Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

Actually, there is a very nasty side effect to the "b" prefix: it complicates using the output from token_get_all. You have to be very experienced (i.e. have feel the pain really) to know about this rare edge case - yet it must be dealt with if you want a correct parser in userland. See e.g.

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

> > As noted in the RFC, this isn't possible due to ambiguities with array > keys and yield expressions with keys. > There are not ambiguities technically, so it is possible if we want to: $a = [ $y => 'b', ($x) => $x + 1, // key, value pair ]; $a = [ $y => 'b', (($x) => $x +

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

Or just drop any "fn" or "function" keyword, eg ($x, $y) => foo($x, $y); array_map(($x) => $x + 1); ?

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

Hi Nikita, hi all, https://wiki.php.net/rfc/deprecations_php_7_2 I just realized that in Symfony, we use the $errcontext argument of error handlers to work around the limitation of __toString not being able to throw. Excerpt from

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

Hi everyone, having worked a bit with anonymous classes these days, the current boilerplate is really high to inject some local context into them. So big +1 from me for the target. On the proposed syntax, I really prefer Nikita's proposal: return new class { > private $a = $var; >

Re: [PHP-DEV] Missing reflection info about strict types?

Hello, back on this topic: 2016-09-08 6:51 GMT+02:00 Rasmus Lerdorf <ras...@lerdorf.com>: > On Sep 5, 2016, at 13:13, Nicolas Grekas <nicolas.gre...@gmail.com> wrote: > > > > It's not specifically me but Symfony's ClassCollectionLoader::load() > > meth

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

Le 1 oct. 2016 01:20, "Marco Pivetta" a écrit : > > On Mon, Sep 26, 2016 at 7:44 AM, Pierre Joye wrote: >> >> Also follow the discussion here >> >> https://github.com/php/php-src/pull/2137#issuecomment-249353056 > > > Follow-up on this, since RC3 was

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> > See https://github.com/php/php-src/pull/2136 > > On a technical note this is a potentially breaking change for C > extensions. Since it is a currently a `zend_bool` its value is > truthy/falsy; you are now applying specific meaning to values. > > Maybe someone else will have more insight into

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> To handle this in code written around current __toString seems pretty simple Yes it is, but that's not what we're talking about: BC is about having perfectly fine code working in e.g. 7.0 be still working fine on 7.1 *without any change*. Right now, we have red test suites on php7.1rc2. This

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> > I'm not so sure its a BC though. Technically nullable types don't exist in > 7.0 and as such would be impossible to return said question mark. Its only > adding support for a new feature, not changing how an existing feature > works IMO. If nullable types had been in 7.0 its highly probably,

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> > See https://github.com/php/php-src/pull/2136 >> > > I don't like this. > I understand, really. I do have to deal with BC on Symfony side also and it's a really hard constraint. Yet, we stick to it as much as possible, in order to not add pain to others. Sometime, we have to be pragmatic and

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> Curious: Why do you depend on the string representation? __toString is the only public interface on ReflectionType that allows getting the type name, so people already build things on top. See http://php.net/ReflectionType

[PHP-DEV] Fix ReflectionType::__toString() BC break

Hello, our turn to be hit by this 7.1 BC break in Symfony: `ReflectionType::__toString()` now adds a `?` in front of type hints where `null` is allowed by their default values. But since `zend_bool` is really an `unsigned char`, we have plenty of room to store and forward this semantic subtlety

Re: [PHP-DEV] Missing reflection info about strict types?

> Why do you concatenate these files in the first place? > > It's not specifically me but Symfony's ClassCollectionLoader::load() method, which generates a single file with common classes inlined for faster bootstrapping (the perf gain is objectively measurable). You give this method a list of

Re: [PHP-DEV] Missing reflection info about strict types?

> > being strict type it should not matter, at all > It doesn't, except when trying to concatenate several source files into a single bigger one. Then we're stuck because declare(strict_type=0/1) is specifically *not* allowed in the middle of a file, and *not* allowed to use the block syntax

Re: [PHP-DEV] Missing reflection info about strict types?

Thanks for trying Julien I guess what you miss for what you want to do, is to detect if strict > types are activated into the current scope, at runtime. > >From the inside, the author of the code knows if they added the declare or not. I'd need to know from the outside, before concatenating it,

[PHP-DEV] Missing reflection info about strict types?

Hello, It looks like we miss a way to check by reflection if a function/method has strict types enabled or not. We'd need to do this in Symfony to generate a file with concatenated classes, but split "declare_strict=1" classes out so that they don't break (because there is no way to create a

[PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter 1 to be object, string given

Hello, now that the BC break on ReflectionType has been reverted, another one remains in ReflectionMethod::invoke(): the method doesn't accept a string as first argument anymore, see e.g.: https://3v4l.org/pImmv As you can see, this worked since 5.0 and even in HHVM. It would be great to fix

Re: [PHP-DEV] Re: [RFC] [DRAFT]: Consistent callables

> https://wiki.php.net/rfc/consistent_callables Personally, I do use "colon separated string" to e.g. put callables as keys in an array (when of course the array definition I'm writing is fine with static callables). The reasons written in the RFC seem very weak compared to breaking code that

RE: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break ***

Hi, I can check early next week, I'm almost AFK currently. Thanks, Nicolas

Re: [PHP-DEV] realpath() on MacOSX doesn't normalize the case of characters

For windows, there is no path normalization either btw. It would makes realpath more expensive. I don't know what you mean by no path normalization, but as far as the case is concerned, there IS normalization: var_dump(realpath(strtolower(__FILE__))); var_dump(realpath(strtoupper(__FILE__)));

[PHP-DEV] realpath() on MacOSX doesn't normalize the case of characters

Hello, I reported this bug one year ago (https://bugs.php.net/67220) and it is now closed as not a bug. I'd like this to be reconsidered. The documentation of realpath() says: realpath() expands all symbolic links and resolves references to '/./', '/../' and extra '/' characters in the input

Re: [PHP-DEV] Exposing object handles to userland

So, yes, just to make it more human friendly. In which case, the actual value doesn't matter, and rather than reverse-engineering the hash, you could just make up your own ID: function my_object_id($obj) { static $hash_to_id=[]; $hash = spl_object_hash($obj); if ( !

Re: [PHP-DEV] Exposing object handles to userland

2015-08-02 20:03 GMT+02:00 Rowan Collins rowan.coll...@gmail.com: On 02/08/2015 18:41, Bob Weinand wrote: Some suspicious use of spl_object_hash() out there... https://github.com/symfony/symfony/blob/master/src/Symfony/Component/VarDumper/Cloner/VarCloner.php Not sure what this one

Re: [PHP-DEV] Exposing object handles to userland

- more importantly for users, these ids couldn't be compared to var_dumps'. Why do you need to compare the output of two dump functions? Just add a note to the documentation that these are not the same IDs. That's not a strong feature, but still, it makes the tool a little bit more

Re: [PHP-DEV] Exposing object handles to userland

Hi Stas, thanks for hooking into this thread However, committing to having specific object ID (e.g. as integer) as part of public API is pretty big commitment This is already part of the public API: var_dump and debug_zval_dump do expose object IDs to userland. It's just inefficient to get

Re: [PHP-DEV] Exposing object handles to userland

I also know people that print_r($an_object) and parse the output just to extract the object handle from there... Crazy isn't it ? I plead guilty for doing this, but php let me no better choice for now ;) The attached patch removes the XOR hashing for the object handle (it's useless, the

Re: [PHP-DEV] Exposing object handles to userland

Have you checked the impact of changing the existing function? Yes I did, and this breaks absolutely nothing: the spl_object_hash output has exactly the same format (otherwise it's a bug). https://github.com/sebastianbergmann/phpunit/search?utf8=%E2%9C%93q=spl_object_hash

Re: [PHP-DEV] Exposing object handles to userland

Anthony's argument about exposing the mem layout is crucial, though. Yes it is! The patch I attached un-xors only the part for the object's handle. The memory pointer is kept xored.

Re: [PHP-DEV] Add support $object::class

Systems that depend on `get_class()` a lot would An for non-objects types, I suggest that $var::class could return the same as get_type($var). That would allow saving ref mismatches when $var is a ref.

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

Foo::bar(); // OK ['Foo', 'bar'](); // OK 'Foo::bar'(); // FATAL ERROR Hi, does this topic need to be addressed before PHP7 goes feature freeze? Or is it a bugfix? (Julien already provided a patch) I'm not familiar with writing RFCs. I fear I won't be able to handle it on schedule if one

Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference

function myErrorHandler($errno, $errstr, $errfile, $errline) {...} It would be awesome to also pass $errfile and $errline by reference. This would allow mapping compiled source to real source code and have meaningful error file+line information. By compiled, I mean e.g. inlined classes (like

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

I'm not sure though if it should be done by adding 'foo::bar' to $a() or removing it from call_user_func(). call_user_func('foo::bar') work since 5.2.2 (see http://3v4l.org/k2SOU). Is there a serious reason to break code that is perfectly fine since 2007. Breaking BC needs a serious reason

Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()

Hi this is a proposal to add new function to PHP core: spl_object_id() IMHO this is a good idea: currently, var_dump has this super-power (and super-useful) capability of outputting a number that ease recognizing identical objects in dumps. This power should be transferred to userland devs so

Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()

Hi Rowan, In order to get an object's id, I use a trick that works for now: https://github.com/symfony/symfony/blob/2.6/src/Symfony/ Component/VarDumper/Cloner/VarCloner.php#L258-L282 This seems like a very elaborate piece of reverse engineering Right, and I made the claim for this being a

Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()

t would not be a BC break to completely change the output I agree! This could be as simple as removing the XOR for the first part of the hash string (the first 16 chars) and expose the internal object's handle there. This is already leaked by the output of var_dump so not a pb imho. And BC is

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

For the record, from https://bugs.php.net/bug.php?id=68475 : call_user_func($a) is **almost** equivalent to $a(): A foo::bar string is OK for call_user_func(), but KO for the pure syntax way. See http://3v4l.org/rbQ4P To me, this looks like a whole in the implementation that should be fixed.

Re: [PHP-DEV] [RFC] UString

aware string handling: https://github.com/nicolas-grekas/Patchwork-UTF8/blob/master/class/Patchwork/Utf8.php and the same but turkish variant: https://github.com/nicolas-grekas/Patchwork-UTF8/blob/master/class/Patchwork/TurkishUtf8.php About unicode equivalence: For all the string matching

Re: [PHP-DEV] Unicode support

alphabet https://github.com/nicolas-grekas/Patchwork-UTF8/blob/master/class/Patchwork/TurkishUtf8.php also... This is required IMHO to have what user expects for str_replace, strpos, strcmp, etc. I wrote a quite successful PHP lib to deal with this in PHP: https://github.com/nicolas-grekas/Patchwork-UTF8

Re: [PHP-DEV] RFC: Anonymous Classes

If you need access to the methods in AProxifier then why does the anonymous class extend A, you should extend AProxifier as you would with any other class. Because A has the behavior I want to extend? An other example: class A {...} class B {...} class Factory { protected function

Re: [PHP-DEV] RFC: Anonymous Classes

I think what Terence was talking about is more like this: class A { } class AProxifier { protected function protectedMethod() {...} function getAProxy() { return new class extends A { /* How do you call AProxifier-protectedMethod() here? */ }; } } This is possible with

Re: [PHP-DEV] RFC: Anonymous Classes

What about allowing a use statement on these methods? $someFoo = bar; $object = new class{ function method() use ($someFoo) { return $someFoo;} } $object-method(); // bar;

Re: [PHP-DEV] [RFC] Keywords as identifiers

Hi Bob, thanks for the RFC! For those of us that use token_get_all(), will the newly allowed token appear as T_STRING or as T_%KEYWORD%? May I suggest you add a word about it in the RFC? As Ryan pointed out in the other thread, a T_%KEYWORD% has a high chance to break existing documentation

Re: [PHP-DEV] Re: Function autoloading

namespace foo { something(); // autoloaded as something } That makes sense *for me* for many reasons, but IMHO that's too confusing for a wider adoption. Because this doesn't work for function foo\strlen, the only reasonable way to work with such an autoloader would be to avoid using

Re: [PHP-DEV] Re: Function autoloading

My previous message didn't push the point I wanted raise: don't we have a major problem related to at-run-time namespace resolution for functions and constants? Take this code: namespace foo { strlen(bar); } Will you trigger an autoload for foo\strlen? I believe not because that would hurt

Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

Hi The only regression can be where autoloaders are defined, and people are relying on the legacy undefined constant behavior (which triggers an E_NOTICE). that makes me think about this code : ?php namespace foo; bar(); ? What autoload should be triggered? foo\bar or bar? Both are valid

Re: [PHP-DEV] Proposal for better UTF-8 handling

Btw, I hit a bug on grapheme_substr() that got no attention: https://bugs.php.net/bug.php?id=62759 There is also https://bugs.php.net/bug.php?id=61860 that waits for a fix. Nicolas On Mon, May 27, 2013 at 8:40 AM, Pierre Joye pierre@gmail.com wrote: hi! On Fri, May 24, 2013 at 3:17

[PHP-DEV] How about adding PHPass compatibility to the password hashing API

Hi, What do you think about adding PHPass compatibility to the password hashing API ? We could add two new algos : PASSWORD_MD5 and PASSWORD_EXT_DES. That way, existing password crypted using phpass ($P$*, $H$*, _* prefix) could be verified using the password hashing API. PHPass implementation

Re: [PHP-DEV] How about adding PHPass compatibility to the password hashing API

With respect to adding those algorithms for generating hashes, I'm 100% dead set against it. Ok, I understand and agree, generating hashes for weaker algos is not a good idea. The point I wanted to address was forward/backward compatibility with existing password databases that use PHPass :

Re: [PHP-DEV] Error handling brainstorming

** The overall mood seems to be that since PHP has an error handler, everyone is free to handle errors any way they want. 2) When everyone starts handling errors in their own way with error handlers, you can't reliably use third party code. You are in your own universe. I think that's the

<    1   2   3   4   >