Re: [PHP-DEV] Autoloading functions/consts without a performance impact

On Sun, Jan 5, 2020 at 7:48 PM Rowan Tommins wrote: > On 05/01/2020 18:03, tyson andre wrote: > >> Yes, I'm saying that the autoloader should be called for each lookup, so > >> autoloading of Foo\strlen should come between checking if Foo\strlen is > >> defined, and checking if \strlen is

Re: [PHP-DEV] Autoloading functions/consts without a performance impact

On Fri, Jan 3, 2020 at 10:35 AM Nikita Popov wrote: > On Fri, Jan 3, 2020 at 2:51 AM tyson andre > wrote: > > > After a quick search, it turns out I've mostly reinvented > > https://wiki.php.net/rfc/autofunc which I hadn't remembered. > > The `spl_autoload_*()` changes it mentions is what I had

Re: [PHP-DEV] [RFC] Object Initializer

I'd like to address the examples - and why I think they don't demonstrate that this feature is really useful in practice. There are several examples similar to this one: class Car { public int $yearOfProduction; public string $vin; } This is either lacking a constructor to initialize the

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

On Thu, Jul 25, 2019 at 3:34 PM Nikita Popov wrote: ... > Based on the received feedback, I plan to change this proposal from being > "namespace-scoped" to being "directory-scoped" instead ... I think that's a better approach. But please consider doing this without adding another global

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

On Thu, Jul 18, 2019 at 4:28 PM Dan Ackroyd wrote: > On Thu, 18 Jul 2019 at 11:08, Rasmus Schultz wrote: > > > > What about ... > > Although there might be real problems for this, please can you > describe a concrete problem that will occur, in a library people us

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

On Tue, Jul 16, 2019 at 2:34 PM Bishop Bettini wrote: > On Tue, Jul 16, 2019 at 3:51 AM Nikita Popov wrote: > > > 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

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

For the record, we're a mid-size organization, building a modern product on PHP 7 with a PSR-based stack. We've shunned template engines and rely heavily on short open tags and alternative control-structures - mainly because we insist on static analysis and IDE support, which we get by manually

[PHP-DEV] unload/reload classes?

Hello internals, How hard would be to add an unload (or reload) feature for classes/interfaces? I'm wondering with regards to running PHP as a deamon (with Swoole or ReactPHP, etc.) could it be made possible to hot-reload e.g. for controllers and view-models? Of course, the other option is to

Re: [PHP-DEV] [RFC] JIT

> 1.3-1.5 times speed-up Dare I ask. But is this even worth while? This does not bring PHP to the level of performance where you could reasonably implement, say, interpolated image resampling or a JPEG decoder/encoder, correct? This is still orders of magnitude slower than C, am I wrong?

Re: [PHP-DEV] proper anonymous classes?

existing string type-hints for class-names. (?) On Wed, Feb 13, 2019 at 9:16 AM Joe Watkins wrote: > What you describe is first class support for classes, nothing much to do > with anonymous classes. > > On Wed, 13 Feb 2019, 09:01 Rasmus Schultz >> The fact that the

[PHP-DEV] proper anonymous classes?

The fact that the anonymous class syntax defines a class *and* immediately constructs an instance is quite annoying. For one, this is quite incompatible with DI containers' ability to resolve constructor arguments. Lets say you DI container can register a named component by merely referencing a

[PHP-DEV] Mixed type-hint

Regarding the mixed type-hint RFC: https://wiki.php.net/rfc/mixed-typehint > When no native type is present, it is unclear what type is expected Regarding variance - in the examples shown in the RFC, it is still unclear whether your intention was variance, or if you just omitted the type-hint

[PHP-DEV] Possible bug in the implementation of php://input streams?

We've noticed something odd about the "php://input" stream. This type of stream resource reports itself as seekable: assert(stream_get_meta_data(fopen("php://input", "r"))["seekable"] === true); https://3v4l.org/EFLiO If you attempt to rewind() it after reading the stream, rewind() returns

Re: [PHP-DEV] deprecation of set_error_level() callback $errcontext argument

On Tue, Oct 2, 2018 at 11:37 PM Rowan Collins wrote: > While I can understand the desire to have debugging feature built into > the language "out of the box", it may be best left to extensions which > can capture the information to a log or wherever without providing the > full flexibility of

[PHP-DEV] deprecation of set_error_level() callback $errcontext argument

I understand the $errcontext argument to the set_error_level() callback was deprecated in 7.2. Apparently, this was deemed "not useful", but what's the alternative? I understand that debug_backtrace() reports the arguments on the call-stack, but... just the arguments - no local vars. I

Re: [PHP-DEV] Re: Pre proposal for "Class extension functions"

On Mon, Sep 24, 2018 at 11:24 PM Andrew Gromov wrote: > > Bring a little Javascript into PHP? > > In fact, I looked at Kotlin :) Kotlin does not modify classes. This sort of thing is sound in compiled languages like Kotlin and C#, where this is really syntactic sugar for calling user-defined

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

ich is to guarantee that the type enforces it's own state specification. I understood the analogy, and I don't agree. On Sun, Sep 23, 2018, 00:42 Rowan Collins wrote: > On 22 September 2018 20:32:04 BST, Rasmus Schultz > wrote: > >if you read my last post (especially the last part) carefully

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

pe (uninitialized); I honestly don't care about that level of > implementation detail. I am only trying to offer suggestions for how to > tighten the guarantees further without violating the basic facts of how > PHP > works. > > On Saturday, September 22, 2018 12:12:48 PM CD

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

I apologize for the long posts, but Larry asked me to comment on this. On Thu, Sep 20, 2018 at 5:52 PM Larry Garfield wrote: > I think the distinction here is that one group is arguing for "state of the > data assertions" while the RFC as implemented is "setter assertion shorthand". The point

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

On Fri, Sep 21, 2018 at 10:24 AM Lester Caine wrote: > Ignoring the debate on uninitialized/null ... not all objects ARE > invariant hence nullable types. > and there are very good reasons for not setting values for > everything, but it seems that these types of object are deemed to be > 'bad

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

On Thu, Sep 20, 2018 at 4:50 PM Levi Morrison wrote: > > This will be my last reply to this thread. Fundamentally: > > class User { > public ?int $id; > public ?string $preferred_name; > public ?string $username; > } > > ^ This permits null properties at all times. This is

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

On Wed, Sep 19, 2018 at 10:04 PM Levi Morrison wrote: > I think this code should be allowed: > >class User { > public int $id; > public string $preferred_name; > public string $username; > } This code is broken - by making the properties non-nullable, you're

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

On Wed, Sep 19, 2018 at 7:43 PM Rowan Collins wrote: > I agree that this is a hard problem, but I don't agree that this decision > is being made "for now". If we allow "non-nullable but uninitialized" > properties now, it will be extremely hard to change their behaviour in > future. I'm with

Re: [PHP-DEV] [RFC] Mixed type

Nikita, I think we'll need the mixed type-hint in any case if we're to move ahead with generics? On Sat, Jun 30, 2018 at 10:30 PM, Nikita Popov wrote: > On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon wrote: > >> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev >> wrote: >> >> Together

Re: [PHP-DEV] Better types without runtime checking

On Tue, Jun 5, 2018 at 9:22 AM, Rudolph Gottesheim wrote: > ... > Has there ever been a discussion about adding some of those features > syntactically, but ignoring them during runtime? That's what Hack does, and one of the main reasons we dropped Hack in favor of PHP. PHP is a reflective

Re: [PHP-DEV] Parse error: Invalid body indentation level

> > Yes, this is an expected result under the flexible heredoc RFC. To avoid > > issues, please use a heredoc label that does not occur within the string. > > Hmkay, so code that worked fine with PHP 7.1 and PHP 7.2 breaks with PHP > 7.3. This breaking change should at least be prominently

Re: [PHP-DEV] Re: [RFC] Fiber support (again)

I've used Swoole, and it is in deed a very high quality extension - both in terms of performance and stability. I haven't used the low-level co-routines, but the HTTP server was rock steady, no memory leaks, easy to implement and CRAZY fast :-) Kind of turns PHP into a better version of Node tbh

Re: [PHP-DEV] [RFC] Fiber support (again)

- Using Fiber::resume() to initialize the fiber and resume feels >>> awkward. Separate methods again would be better here, perhaps >>> Fiber::init(...$args) and Fiber::resume($send). >>> >>> All Fiber created with a suspended status. So make resume to do both the >>> init and resume >>> do

Re: [PHP-DEV] GD vs Imagick

Yeah, I keep thinking about this. I'm not sure there's a really good reason why PHP shouldn't come with best-in-class image support, if it's available - which it sounds like it is; libvips looks more modern, lower memory and CPU overhead, better overall really, and appears to be stable and

Re: [PHP-DEV] GD vs Imagick

that libraries like Intervention Image can deliver predictable results. I'm not a C developer though, so I can't help with that. On Thu, Aug 17, 2017 at 7:03 AM, Pierre Joye <pierre@gmail.com> wrote: > hi Rasmus, > > On Tue, Aug 15, 2017 at 5:52 PM, Rasmus Schultz <ras...@mi

[PHP-DEV] GD vs Imagick

The following GD issue is all-too common: https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images Basically anyone who's ever accepted uploaded images and resized or converted them, has bumped into this. Only Imagick makes it possible to

[PHP-DEV] Binary (msgpack) serialize/unserialize

Back in 2014 there was an informal proposal on the mailing list to replace PHP serialization with an efficient binary (msgpack) format. https://www.mail-archive.com/internals@lists.php.net/msg69870.html As argued back then, breaking serialize() and unserialize() is unacceptable for many reasons.

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

On 21/06/2017 15:04, Rasmus Schultz wrote: > > > For me (and I am not alone), this feature is NOT a new syntax for > closures > > > > Regardless of why you want it, that's exactly what it is though - > another way to declare a closure. > > > > Even if it has di

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

:19 PM, Stephen Reay <step...@bobs-bits.com> wrote: > > > On 21 Jun 2017, at 21:04, Rasmus Schultz <ras...@mindplay.dk> wrote: > > > > Once people see the nicer, shorter syntax, > > For anything but the most basic of closures, the shorter syntax just makes >

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

w type of object that isn't an instance of Closure, in which case I'd say this whole feature is guaranteed to do considerably more harm than good? On Tue, Jun 20, 2017 at 7:52 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 19 June 2017 21:22:53 BST, Rasmus Schultz <ras...@

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

> I just think your example is an exaggeration to what happens in practice. I think it's an example of what happens with any inconsistent feature in any language. On Tue, Jun 20, 2017 at 9:53 AM, Markus Fischer <mar...@fischer.name> wrote: > Hello Rasmus, > > On 19.06.17 22:

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

worth doing it right. On Mon, Jun 19, 2017 at 10:12 PM, Larry Garfield <la...@garfieldtech.com> wrote: > > > On 06/19/2017 03:45 PM, Rasmus Schultz wrote: > >> Or maybe it'll look okay if you format the code? >> >> $things->forEach({$v =>

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

Or maybe it'll look okay if you format the code? $things->forEach({$v => { foo($v); bar($v); }}); Still looks kinda crazy with the closing "}})" though... On Mon, Jun 19, 2017 at 9:43 PM, Rasmus Schultz <ras...@mindplay.dk> wrote: > I

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

I actually like this syntax, but what would it look like for multi-statement closures? A nested set of curly braces around the body would look pretty messy. $things->forEach({$v => { foo($v); bar($v); }}); On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison wrote: > On Sun, Jun

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

e fn keyword solves the ambiguity problem - it looks > > exactly like a function call. > > > Right. But it does solve the ambiguity if `fn` is a keyword which is what > the RFC suggests. > > > > On 18 Jun 2017, at 18:40, Rasmus Schultz <ras...@mindplay.dk> wrote:

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

I don't agree that the fn keyword solves the ambiguity problem - it looks exactly like a function call. As for the backslash, my honest reaction is, ugh, please, no more backslashes - PHP (and every other language) uses backslashes for escaping in strings, it already looks pretty awkward in

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

used in these contexts? On Thu, Jun 8, 2017 at 5:56 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 6/7/2017 9:45 PM, Rasmus Schultz wrote: > >> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable > > compromise. > > > > I have to sec

Re: [PHP-DEV] preg_match() option for anchored offset?

at 10:03 PM, Rasmus Schultz <ras...@mindplay.dk> > wrote: > >> What do you think about adding another option to preg_match() to allow the >> $offset parameter to be treated as the start anchor? >> >> The manual proposes to do this: >> >> $subjec

[PHP-DEV] preg_match() option for anchored offset?

What do you think about adding another option to preg_match() to allow the $offset parameter to be treated as the start anchor? The manual proposes to do this: $subject = "abcdef"; $pattern = '/^def/'; $offset = 3; preg_match($pattern, substr($subject, $offset), $matches); In

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

> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable compromise. I have to second that. I might even propose to shorten it from "fn" to just "f" - the resulting syntax then resembles a mathematical predicate :-) On Wed, Jun 7, 2017 at 5:20 PM, Stephen Reay

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

Ugh, you're right, that's totally unreadable... the => is far too ambiguous with array syntax, I agree. How about just a thin arrow? (params) -> expr If the parens around params were required, it's not ambiguous with the trailing -- operator, is it? $foo->bar(($baz) -> $baz + 1);

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

Of the proposed options, I'd prefer the double fat-arrow ==> However, I remain of the opinion that all of those syntaxes are work-arounds to ambiguity concerns for cases that likely don't actually occur in real-world codebases. I don't understand the motivation to design or optimize based on

Re: [PHP-DEV] Parameter type widening RFC

!) both major and minor versions, which doesn't sound easy at all. On May 29, 2017 00:53, "Dan Ackroyd" <dan...@basereality.com> wrote: > On 28 May 2017 at 14:25, Rasmus Schultz <ras...@mindplay.dk> wrote: > > > > To me, that's a setback that leads to harder-t

Re: [PHP-DEV] Parameter type widening RFC

ler <m...@kelunik.com> wrote: > 2017-05-28 12:30 GMT+02:00 Rasmus Schultz <ras...@mindplay.dk>: > >> > > So this breaks the expected behavior of interfaces. >> > >> > No it doesn't. It allows interfaces to use contravariance within PHP's >> &

Re: [PHP-DEV] Parameter type widening RFC

w problem case of accidental type-hint omission. Is there a very good reason we shouldn't address that, if it's at all possible? On Thu, May 25, 2017 at 12:32 PM, Dan Ackroyd <dan...@basereality.com> wrote: > On 25 May 2017 at 10:21, Rasmus Schultz <ras...@mindplay.dk> w

Re: [PHP-DEV] Parameter type widening RFC

> > The feature, as implemented, will allow accidental omission of type-hints, > > will it not? > > Yes, correct. So this breaks the expected behavior of interfaces. This will be harmful to everyone, but especially harmful to new programmers, who may never even learn how to correctly implement

[PHP-DEV] Parameter type widening RFC

This parameter type widening RFC, I didn't know about, but I have a remark. The feature, as implemented, will allow accidental omission of type-hints, will it not? Previously, the implements keyword guaranteed a correctly type-hinted implementation - it's now possible to (purposefully,

Re: [PHP-DEV] scalar type-casting

Hi Rasmus, > > Although DbC is not what you need, but DbC could solve your issue > more efficiently. i.e. Faster execution, not shorter code. > > https://wiki.php.net/rfc/dbc2 > > With DbC, caller has responsibility to pass correct parameters. > > On Sun, Apr 9,

Re: [PHP-DEV] scalar type-casting

:07 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 9 April 2017 10:30:02 BST, Rasmus Schultz <ras...@mindplay.dk> wrote: > >Example: > > > >class Foo { public function __toString() { return "foo"; } } > >function append_to(string &$str) { $st

[PHP-DEV] scalar type-casting

Since PHP 7.0, I've started using scalar type-hints a lot, and it got me thinking about scalar type-casting. After poking through existing RFC's, it turns out, I was going to propose precisely the thing that Anthony Ferrara proposed in 2012: https://wiki.php.net/rfc/object_cast_to_types In the

Re: [PHP-DEV] Directory separators on Windows

10 thumbs up ;-) But this really demonstrates how badly we need this function - I bet any number of those points may or may not be covered by any number of implementations in the wild. It would be so nice to have this done "right", once and for all. On Sat, Apr 1, 2017 at 2:42 PM, Fleshgrinder

Re: [PHP-DEV] Directory separators on Windows

network file-system paths on Windows with a different syntax to consider? I don't know much about that... On Fri, Mar 31, 2017 at 11:40 AM, Pierre Joye <pierre@gmail.com> wrote: > On Fri, Mar 31, 2017 at 3:32 PM, Rasmus Schultz <ras...@mindplay.dk> > wrote: >

Re: [PHP-DEV] Directory separators on Windows

ituation of > > "\\host\share/path/to/file" <--- wat? > > > > Overall, it smells of magic. > > > > -Sara > > > > On Thu, Mar 30, 2017 at 8:25 AM, Rasmus Schultz <ras...@mindplay.dk> > wrote: > > > Today, I ran into a very hard-to-debug

[PHP-DEV] Directory separators on Windows

Today, I ran into a very hard-to-debug problem, in which paths (to SQL files, in a database migration script) were kept in a map, persisted to a JSON file, and this file was moved from a Windows to a Linux file-system - because the paths on the Linux system had forward slashes, the files appeared

Re: [PHP-DEV] PCRE caching

ar 3, 2017 at 10:28 PM, Nikita Popov <nikita@gmail.com> wrote: > On Wed, Mar 1, 2017 at 4:35 PM, Rasmus Schultz <ras...@mindplay.dk> wrote: > >> Hey internals, >> >> I was wondering whether or how PCRE regular expression get parsed and >> cac

Re: [PHP-DEV] New constants in DateTime

FWIW, these constants are not universal. In Postgres (and MySQL since 5.7) the date+time types have optional sub-second precision - which the "Y-m-d H:i:s" pattern will fail to parse. Another common case in Postgres is date+time with timezone, e.g. used for scheduling/calendar applications etc.

[PHP-DEV] PCRE caching

to cache between requests in long-running apps or under FPM. I think most apps use quite a lot of regular expression for validation etc. so maybe there's a missed optimization opportunity here? Cheers, Rasmus Schultz

Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint, now with added variance

In the light of this, maybe enums (assuming this feature comes first) should be implemented as immutable objects rather than values? Type-checking for enums would be important, so in PHP terms, an enum "instance" would likely be closer to an object than a value in nature anyway. The way I look

Re: [PHP-DEV] Namespaces in Core

Just my two cents, but moving and aliasing core PHP classes/interfaces/functions sounds like an absolutely horrible idea. My biggest question is WHY would you do that? Writing user-space code today that uses the global namespace would be considered extremely bad practice - no one should do that.

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

I'd strongly prefer a syntax without the introduction of "fn" keyword - e.g. similar to closures in other languages. I also feel that there's a feature missing - something that was possible with closures: $total = 0; $add = function ($value) use (&$total) { $total += $value; }; Per the

Re: [PHP-DEV] PHP's support to contravariance and covariance

We were talking about this exact issue at work today. Supporting this for interfaces would be particularly useful - if an implementation better than satisfies the requirements defined by an interface, it should be able to implement that interface. I'd be very happy to see an RFC for this :-)

Re: [PHP-DEV] Fwd: Type Collection

> Basically Foo[] to indicate an array of objects of type Foo I would be fine with that, as long as it's sugar for array On Sun, Jan 29, 2017 at 4:51 PM, Sebastian Bergmann wrote: > Am 28.01.2017 um 17:10 schrieb Niklas Keller: > > sounds like everything you want is typed

Re: [PHP-DEV] Fwd: Type Collection

> The Collection is Iterable, Traversable, Countable like an array to be > compatible with foreach and other Traversable-compatibles functions. Right, so it's an array. Except, it's an object-type, rather than a value-type like arrays. (I'm guessing - I don't think you specified?) And it's

Re: [PHP-DEV] Not autoloading functions

> old applications could maintain compatibility only > by adding a simple autoloader that would alias the global function/constant > into the calling namespace So as a side-effect of calling any function, my namespace would get polluted with all sorts of random names? That sounds like a messy

Re: [PHP-DEV] Pipe Operator v2

com> wrote: > As a userland developer I feel $$ (or some variation starting with $) is > reasonably natural - it's a variation on a regular variable. > > > > Sent from my iPhone > > > On 25 Jan 2017, at 03:53, Levi Morrison <le...@php.net> wrote: > > > >

Re: [PHP-DEV] Re: Not autoloading functions

> if you choose to use static methods instead of functions It's not a choice - functions are practically useless in a Composer context, and most everything PHP is now Composer packages. > why do you need this special syntax for calling them then? Yeah, but the same logic applies to namespaces

Re: [PHP-DEV] Re: Not autoloading functions

tly implemented as public static functions, and in my opinion, this is starting to sound less like a stop-gap and more like a simple solution to a problem we've been solving with a stop-gap for, oh, 10 years or so... On Jan 26, 2017 10:05 AM, "Andrea Faulds" <a...@ajf.me> wrote: >

Re: [PHP-DEV] Pipe Operator v2

Isn't `_` more generally used as a "discard" placeholder in most languages? At least in Swift, Go, Scala, Dart and C# (starting with v7) I think? I don't recall having seen it mean "fill in the blank". In what languages? On Fri, Jan 20, 2017 at 4:26 PM, Levi Morrison wrote: >

Re: [PHP-DEV] Not autoloading functions

> How hard is it to write Foo::bar? You never have to go more than one level. I don't see a point in mixing internal function namespace with class methods for the sake of saving typing couple of characters. I'm not suggesting we mix namespaces - this of course would be file-local, same as

[PHP-DEV] Not autoloading functions

Just a quick thought. Since the autoloading functions proposal is stalled, how about allowing for import of static functions instead? use function Foo::bar; bar(); // calls Foo::bar() There are two benefits to this approach: 1. There is immediate support for autoloading without any

Re: [PHP-DEV] Typed properties problems

On regular PHP 7, the array weirdness (Dmitry's last example) doesn't even produce a warning: class Shit { public $yo = false; } $shit = new Shit(); $shit->yo[] = "what"; // quitly turns $yo into an array! echo gettype($shit->yo); // array That's pretty messed-up right there. At least in

Re: [PHP-DEV] [RFC] Parameter No Type Variance

But this leads to code that can't pass static inspections? interface Joiner { public function join(array $array): string; } class WideJoiner implements Joiner { public function join($iterable): string { $array = is_array($iterable) ? $array : iterable_to_array($iterable);

Re: [PHP-DEV] Immutability RFC

Reading through the RFC and the replies, I'm confused about this question. Why would the comparison operators work any differently on immutable objects? If these were value objects, the question would make sense, but it doesn't sound like that's what you're proposing? With regards to the

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

> if you've hired developers that care more about trends than your application then you've hired the wrong developers. A consistent, complete type-system is not a "trend". In my experience, good developers notice things like inconsistency - and they generally do not like it. I am personally

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

Heh, so, this week, a coworker of mine started using PHP 7, and he calls me over, and he's like, "I don't get it, I had heard PHP 7 was supposed to have type-hints now - it worked for return-types, but what am I doing wrong, I can't seem to get this to work for properties?" He actually had

Re: [PHP-DEV] Allow Iterator to be used with current, next, reset, key functions

t() and array_last() for consistency with other array-only functions. Perhaps better to make people be explicit, rather than trying to hide side-effects to achieve shorter syntax... On Sun, Oct 30, 2016 at 2:14 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 10/30/2016 1:59 PM, Rasmus Sc

Re: [PHP-DEV] Allow Iterator to be used with current, next, reset, key functions

On 10/30/2016 1:31 PM, Rasmus Schultz wrote: >> On second thought, I agree with that - changing reset() and end() >> doesn't make sense, because people know them and expect them to work >> in a certain way. Likely a lot of people would actually continue to >> use them wi

Re: [PHP-DEV] Allow Iterator to be used with current, next, reset, key functions

6 12:45 PM, Nikita Popov wrote: >> On Sun, Oct 30, 2016 at 12:24 PM, Rasmus Schultz <ras...@mindplay.dk> wrote: >> >>> With regards to deprecating array-functions that operate on the >>> internal pointer - I'd like to just remind you of the fact that some &

Re: [PHP-DEV] Allow Iterator to be used with current, next, reset, key functions

With regards to deprecating array-functions that operate on the internal pointer - I'd like to just remind you of the fact that some of these functions, reset() and end() in particular, are often used not because someone cares about moving the internal pointer, but as a means of getting the

Re: [PHP-DEV] SQLite 3.14

On Wed, Aug 10, 2016 at 4:08 PM, Christoph M. Becker wrote: > Sounds reasonable, Anotol. Thanks. So I'm going to update 7.1+ ASAP. Are you going to include any plugins? I noticed today, SQLite has interesting optional features - in particular, the "json1" plug-in looks

Re: [PHP-DEV] Function auto-loading

On Tue, Aug 9, 2016 at 6:17 PM, Rowan Collins wrote: >> In other words, calls to substr() does not trigger the resolve - a >> statement like "use function substr" on the other hand, does. > > Ah, I see. The problem with that is, you still have to explicitly list every >

Re: [PHP-DEV] Function auto-loading

On Tue, Aug 9, 2016 at 12:04 AM, Rowan Collins wrote: > I don't quite follow what you're suggesting here. When does this "function > resolver" get called? I'm suggesting the use-statement be the trigger, rather than actually calling the function. In other words, calls

Re: [PHP-DEV] Function auto-loading

On Mon, Aug 8, 2016 at 10:54 PM, Lester Caine wrote: > I can understand a little the overwhelming desire to wrap everything in > it's own set of name spaces, but is that REALLY essential to make PHP > 'work better'. What is wrong with a simple 'include_once' of the library >

Re: [PHP-DEV] Function auto-loading

and would make them effectively "autoload" - I imagine it's no more costly to pre-register the protocol/class-name than e.g. pre-registering some other form of auto-loader? On Mon, Aug 8, 2016 at 10:23 PM, Davey Shafik <da...@php.net> wrote: > On Mon, Aug 8, 2016 at 1:15 PM, Ra

Re: [PHP-DEV] Function auto-loading

t; > > return compare_on($comparison, $keyFunction); > > Although interestingly, at the top of the file there is a (technically > unnecessary) "use function Functional\compose;" If there was a "use > function Functional\compare_on;" as well, we'd be fine.

Re: [PHP-DEV] Function auto-loading

> If not, I don't see why we ever need to be able to autoload global functions Well, for consistency. For one, if you're refactoring a global function to a namespaced one, this inconsistency is going to be surprising. In general, any inconsistency in a language is surprising. Why only

Re: [PHP-DEV] Function auto-loading

. On Sun, Aug 7, 2016 at 1:29 PM, Nikita Popov <nikita@gmail.com> wrote: > On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz <ras...@mindplay.dk> wrote: > >> I'd really like to see the function auto-loading proposal revived and/or >> possibly simplified. >> >>

[PHP-DEV] Function auto-loading

I'd really like to see the function auto-loading proposal revived and/or possibly simplified. The fact that functions are hard (in some cases impossible) to reach by manually issuing require/include statements is, in my opinion, half the difficulty, and a much more deeply rooted language problem

Re: [PHP-DEV] [RFC][VOTE] New operator (short tag) for context-dependent escaping

Looks like it's unanimously a No. Michael, don't be discouraged - I think that everyone agrees that there is a problem to be solved, it's just that no one except you thinks this is a good solution; many of us are of the opinion that it's not a solution that really addresses the problem at all:

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> the problem IS NOT that we don't have a solution > The problem IS that developer > must call these functions everywhere manually. What you don't seem to get, is your proposal doesn't change that fact? It changes the syntax and means by which you select and call the function, but it still

Re: [PHP-DEV] optionally return class name from gettype

I agree, an argument that essentially turns it into a different function is not a good practice. Suggestions for a function-name? typeof() or vartype() maybe? On Fri, Jul 29, 2016 at 8:17 PM, Niklas Keller wrote: > > > > Niklas Keller wrote: > > > I'm not sure on the

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

Just a thought, but I can't help thinking that "improved escape facilities and syntax" are a mere patch for a more than superficial problem. The problem of differentiating HTML strings, which to not require escaping, from other string, which do, could actually be viewed as a deeper problem, which

Re: [PHP-DEV] Pipe Operator v2

FWIW, I've read the manual page for the Hack page, and the RFC, a couple of times now, and I simply don't understand it. Are most PHP developers going to understand this feature, the meaning of $$, and when/how to use this? Are they going to be able to read code written in this way? To your

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

This is a really good point, Marco. Of course, this would be much cleaner with a set of functions, since $this (whatever it is) is not truly a dependency for any of these functions - they're likely sharing no context or state; they've likely been placed in the class solely to make them available

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> Registry of functions - is exactly how escaping is performed in Symfony and Twig. For one, that does not mean it's a good idea. For another, the registry in Symfony (at least, I don't know about Twig) is inside an instance - it's not global state. Do you get my point that a reference to a

  1   2   3   >