Re: [PHP-DEV] New functions: string_starts_with(), string_ends_with()

lete phrases like str_ends_with, str_has_ending(), str_has_suffix(). Instead of just str_end(), or str_ends(). On the other hand, shorter function names have their benefits. So.. no strong opinion here. -- -- Andreas On Tue, Aug 1, 2017 at 8:29 AM, Michał Brzuchalski <mic...

Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax

Hello list, I found this RFC, describing a feature I wanted for a long time: https://wiki.php.net/rfc/list_default_value https://marc.info/?l=php-internals=144707619509724 (I don't know how to correctly reply to old emails that are not in my inbox, sorry for that. I don't like mailing lists.) I

Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax

I don't have a strong opinion about the nested list() construct which is also part of the RFC. I never had a situation where I wanted this. On Thu, Aug 10, 2017 at 11:21 PM, Andreas Hennings <andr...@dqxtech.net> wrote: > Hello list, > > I found this RFC, describing a feature I wa

Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax

On Fri, Aug 11, 2017 at 12:01 AM, Devnuhl Unnamed wrote: > Would isset($suffix) not suffice here? You mean like so? list($prefix, $suffix) = explode(':', 'string_without_suffix'); if (!isset($suffix)) { .. } The isset() is too late here, because the list() will already

Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax

This is true, I remember having done it in the past. I still think it would be nice and feel natural to have the default values directly built into the list construct. It would be a bit faster, because it does not have to allocate a new temporary array. Whether this difference matters depends

[PHP-DEV] "Reader" as alternative to Iterator

- The naming of "Reader", "ReaderAggregate", "->read()". - Which return value to use for "end of data", so that FALSE would become a valid value. I currently don't see a better option than FALSE. - Andreas Hennings (https://github.com/donquixote)

[PHP-DEV] "Reader" as alternative to Iterator

ata", so that FALSE would become a valid value. I currently don't see a better option than FALSE. Maybe a sub-interface of ReaderAggregate can have an method "->getStopValue()", which would allow to specify something other than FALSE. - Andreas Hennings (https://github.com/donquixote) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] "Reader" as alternative to Iterator

The key will simply be a counter. Open questions: - The naming of "Reader", "ReaderAggregate", "->read()". - Which return value to use for "end of data", so that FALSE would become a valid value. I currently don't see a better option than FALSE. - Andreas Hennings (https://github.com/donquixote) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] "Reader" as alternative to Iterator

Well, on a current project I made an attempt to write different adapters in userland. I finally decided that the clutter is not worth. So for this project I wrote everything as "readers", and not as iterators. With a native solution, one could do this: function generate() { yield 'a'; yield

Re: [PHP-DEV] "Reader" as alternative to Iterator

Mon, Jul 3, 2017 at 3:42 PM, Sara Golemon <poll...@php.net> wrote: > On Sun, Jul 2, 2017 at 10:49 PM, Andreas Hennings <andr...@dqxtech.net> wrote: >> (I wanted dedicated reader classes for different return types, e.g. >> one "RowReader", one "AssocReader"

Re: [PHP-DEV] "Reader" as alternative to Iterator

On Mon, Jul 3, 2017 at 5:27 PM, Johannes Schlüter wrote: > > Wouldn't SPL's NoRewindIterator be enough? > > $nit = new NoRewindIterator($it); > > foreach ($nit as $row) { > break; > } > foreach ($nit as $row) { > // continues same iteration > } I had not noticed this

Re: [PHP-DEV] "Reader" as alternative to Iterator

On Mon, Jul 3, 2017 at 9:09 AM, Niklas Keller wrote: > > Hey Andreas, > > what you're trying to do here seems to be premature optimization. While you > save a bunch of method calls, your I/O will be the actual bottleneck there. > It's entirely fine to implement such logic in

Re: [PHP-DEV] "Reader" as alternative to Iterator

On Mon, Jul 3, 2017 at 5:53 PM, Johannes Schlüter wrote: > On Mo, 2017-07-03 at 17:32 +0200, Niklas Keller wrote: > >> > That distinction is the reason why next() and valid() are different >> > methods in iterators. I would rather say this is the reason why current() and

Re: [PHP-DEV] "Reader" as alternative to Iterator

On Mon, Jul 3, 2017 at 6:08 PM, Andreas Hennings <andr...@dqxtech.net> wrote: > On Mon, Jul 3, 2017 at 5:53 PM, Johannes Schlüter > <johan...@schlueters.de> wrote: >> On Mo, 2017-07-03 at 17:32 +0200, Niklas Keller wrote: >> >>> > That distinction is the r

[PHP-DEV] New functions: string_starts_with(), string_ends_with()

Hello list, a quite common use case is that one needs to find out if a string $haystack begins or ends with another string $needle. Or in other words, if $needle is a prefix or a suffix of $haystack. One prominent example would be in PSR-4 or PSR-0 class loaders. Maybe the use case also occurs

Re: [PHP-DEV] Contravariance and the "empty type"

On Tue, Aug 22, 2017 at 10:39 AM, Nikita Popov <nikita@gmail.com> wrote: > On Tue, Aug 22, 2017 at 4:27 AM, Andreas Hennings <andr...@dqxtech.net> > wrote: >> >> Hello list, >> for a while I had this thought about contravariance and an "empty type"

Re: [PHP-DEV] fputcsv() and $escape character

On Thu, Sep 21, 2017 at 11:08 PM, Dan Ackroyd wrote: > On 21 September 2017 at 12:43, Christoph M. Becker wrote: >> Hi everybody! >> >> There are several bug reports regarding "broken" fputcsv() behavior in >> our tracker, namely, because the $escape

Re: [PHP-DEV] fputcsv() and $escape character

On Thu, Sep 21, 2017 at 1:43 PM, Christoph M. Becker wrote: > I don't think the current behavior is a bug, but rather the escape > character is an extension to the CSV "standard" (RFC 7111). Are you sure you mean RFC 7111 ? I was just parrotting the number in my previous

Re: [PHP-DEV] fputcsv() and $escape character

So empty string would enable the standard behavior RFC 7111 with no escape char. If so, I support this. I don't know if '' or true / false / null should be this "special value". It has to be something that was not legal before, and that people should use intentionally and not by accident. I guess

Re: [PHP-DEV] fputcsv() and $escape character

On Fri, Sep 22, 2017 at 1:20 PM, Christoph M. Becker wrote: >> please make sure the behaviour of common applications, most notably >> Excel, is considered and tested. In my experience it has its own quirks, >> and it's likely that a large proportion of users require >>

Re: [PHP-DEV] Contravariance and the "empty type"

gt; wrote: > Hi Andreas, > > 2017-08-22 21:11 GMT+02:00 Andreas Hennings <andr...@dqxtech.net>: > >> On Tue, Aug 22, 2017 at 10:39 AM, Nikita Popov <nikita@gmail.com> >> wrote: >> > On Tue, Aug 22, 2017 at 4:27 AM, Andreas Hennings <andr...@dqxtech.n

[PHP-DEV] Contravariance and the "empty type"

Hello list, for a while I had this thought about contravariance and an "empty type". I don't expect too much of it, for now I just want to share the idea. Maybe this concept even exists somewhere in a different language, and I am not aware of it. I think it has some overlap with generics,

[PHP-DEV] Covariance, again

There were discussions about covariance and contravariance in the past. https://externals.io/message/98085#98105 Unfortunately I was not subscribed back then, so I cannot respond to anything. So, here it goes again. WIth co- and contravariance, the following would be possible: -

Re: [PHP-DEV] Covariance, again

Let me address the simple example first. On 18 December 2017 at 15:45, Levi Morrison wrote: > > I believe your algorithm fails on this simple setup: > > > interface A { > function foo(): X; > } > > interface B extends A { > function foo(): Y; > } > > interface X { >

Re: [PHP-DEV] Covariance, again

generate similar circularity problems with class_exists() calls? On 18 December 2017 at 15:58, Andreas Hennings <andr...@dqxtech.net> wrote: > Let me address the simple example first. > > On 18 December 2017 at 15:45, Levi Morrison <le...@php.net> wrote: >> >&g

Re: [PHP-DEV] Covariance, again

.net> wrote: > On Mon, Dec 18, 2017 at 11:52 AM, Andreas Hennings <andr...@dqxtech.net> > wrote: >>> I believe your algorithm fails on this simple setup: >> >> Another comment I want to make here: >> The examples you give each have multiple class declarations

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

Perhaps this is the same reason why we add "public" keyword, even though a member is implicitly public by default. On 19 December 2017 at 12:34, Andreas Hennings <andr...@dqxtech.net> wrote: > I agree with Michael Kliewe. > When looking at code, I want to distinguish between

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

I agree with Michael Kliewe. When looking at code, I want to distinguish between: - Developer forgot to add a type hint, or it was left out for legacy / BC reasons. - The function can really return various types, at least too many for any more specific type hint. On 19 December 2017 at 04:57,

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

On 19 December 2017 at 08:06, Fleshgrinder wrote: > What is really needed are `scalar`, `number`, union types, intersection > types, and all that together with generics. Do we have ongoing discussions or RFCs for those already? I know we have one for generics, which seems

Re: [PHP-DEV] Covariance, again

> I believe your algorithm fails on this simple setup: Another comment I want to make here: The examples you give each have multiple class declarations per file. I would personally not care much, if these result in fatal error. All of this code used to be illegal until now (because no covariance

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

naturally occuring union or meta types, which might deserve their own meta type name. On 19 December 2017 at 16:28, Levi Morrison <le...@php.net> wrote: > On Tue, Dec 19, 2017 at 4:47 AM, Andreas Hennings <andr...@dqxtech.net> wrote: >> On 19 December 2017 at 08:06, Fleshgrind

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

I think we do need to explain whether a feature "provides value", so Levi's question is not wrong. Simply "does no harm" is not enough. We just disagree on the answer, we actually do think it provides value. On 19 December 2017 at 18:30, Levi Morrison <le...@php.net> wrote: >

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

I agree with all of Stanislav's emails in this thread so far. On 12 December 2017 at 14:43, Nikita Popov wrote: > On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev > wrote: > >> Hi! >> >> > The idea is to allow specifying declare directives for a

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

functions we currently > have. > > On Tue, Dec 19, 2017 at 4:48 PM, Nikita Popov <nikita@gmail.com> wrote: > >> On Sat, Dec 9, 2017 at 7:28 AM, Andreas Hennings <andr...@dqxtech.net> >> wrote: >> >> > The following (https://3v4l.org/A2Tp6) is ok

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

On 13 December 2017 at 05:04, Michał Brzuchalski wrote: > > If we're going to introduce someday a namespace file, then IMO it should not > be putted outside namespace folder. > For eg class Acme\Animal\Cat in src/Acme/Animal/Cat.php should have > namespace file in

Re: [PHP-DEV] C++-like function-try-block proposal

So to summarize, this feature would save us brackets and one indentation level. Saving an indentation level can be quite useful to reduce a git commit footprint. On the other hand, it might confuse some people. It would blur the concept of a function body scope, and thus the mental model of how

[PHP-DEV] Reflection API: Add static factories on ReflectionType

Currently there is no (documented) way to directly create a \ReflectionType object. The class has no documented constructor. I propose that static factory methods shall be added for this purpose. This will be useful for code that wants to dynamically create and pass around reflection type

Re: [PHP-DEV] ReflectionContext for imports and namespace

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 > > -

Re: [PHP-DEV] ReflectionContext for imports and namespace

> > Documentation tools shouldn't run the code IMO, that means they won't have > access to that feature. By "documentation tools" do you mean libraries like phpDocumentor? You are right, those need to parse anyway, they cannot use reflection API. But tools for annotation discovery may want to

Re: [PHP-DEV] ReflectionContext for imports and namespace

>> 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

Re: [PHP-DEV] ReflectionContext for imports and namespace

On 11 December 2017 at 09:23, Andreas Hennings <andr...@dqxtech.net> 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 polyfil

[PHP-DEV] Add \Reflection*::getHash()

I propose to add a new method ::getHash() to reflection API classes. Such that: Two reflectors return the same hash, if and only if: 1. the reflected items have the same type (class, method, parameter etc), AND. 2. the reflected items have the same names, AND. 3. the reflected items have the

[PHP-DEV] Reflection API: Add ::getFullName() method.

I propose a new method ::getFullName() for all methods that implement \Reflector. (I would add it to the \Reflector interface, but this would be a BC break.) The full name would be, depending on the type: function: "str_replace()", "Acme\foo()". class: "Acme\Animal\Cat", "stdClass". method:

[PHP-DEV] Re: Add \Reflection*::getHash()

ReflectionClass. On 11 December 2017 at 03:11, Andreas Hennings <andr...@dqxtech.net> wrote: > I propose to add a new method ::getHash() to reflection API classes. > > Such that: > > Two reflectors return the same hash, if and only if: > > 1. the reflected items have t

[PHP-DEV] Re: Add \Reflection*::getHash()

On 11 December 2017 at 04:03, Andreas Hennings <andr...@dqxtech.net> 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 instantiat

[PHP-DEV] ReflectionContext for imports and namespace

TLDR: I propose to introduce a new class \ReflectionContext (or perhaps \ReflectionScope?), to give information about imported aliases and the namespace. ## Background / motivation Some libraries that parse doc comment annotations, e.g. phpDocumentor, need to know the class aliases and the

[PHP-DEV] Reflection API: Add ->getTerminatedNamespace() method

## Background / motivation Currently a number of reflection classes have a method ->getNamespaceName(). The namespace comes in a format that is not straightforward to work with. It requires the root namespace to be treated in a special way. $namespace = $relfClass->getNamespaceName();

[PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

The following (https://3v4l.org/A2Tp6) is ok, it simply returns false: $x = 1; $x instanceof \stdClass; The following (https://3v4l.org/IdSBu) gives a fatal error: 1 instanceof \stdclass; t think this behavior is inconsistent, and we should consider changing it. There are two

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

, Kalle Sommer Nielsen <ka...@php.net> wrote: > Hi > > We should just add a warning to the first example, it seems like an > oversight that it was left silent > > On 9 Dec 2017 07.29, "Andreas Hennings" <andr...@dqxtech.net> wrote: > >> The following

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

or broken usage is > a poor argument imo > > > > On 9 Dec 2017 07.38, "Andreas Hennings" <andr...@dqxtech.net> wrote: > >> Adding a warning to something that used to be ok would break existing >> code. >> I remember a number of cases where I

Re: [PHP-DEV] Reflection API: Add ::getFullName() method.

tring 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 AM, Andreas Hennings <andr...@d

Re: [PHP-DEV] Reflection API: Add ::getFullName() method.

>> > >> > 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

Re: [PHP-DEV] Reflection API: Add ::getFullName() method.

On 11 December 2017 at 10:16, Marco Pivetta <ocram...@gmail.com> wrote: > On Mon, Dec 11, 2017 at 10:03 AM, Andreas Hennings <andr...@dqxtech.net> > wrote: >> >> On 11 December 2017 at 09:16, Marco Pivetta <ocram...@gmail.com> wrote: >> > If you rea

Re: [PHP-DEV] Reflection API: Add static factories on ReflectionType

ir-pulling around the PHP lang. > > A small `InternalType` VO that throws on `InternalType::fromString() : self` > would be extremely beneficial to avoid the continuously growing list of edge > cases and additions required to accommodate for new internal types being > added to the lan

Re: [PHP-DEV] Reflection API: Add ::getFullName() method.

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

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

Oh wow, feature request already exists, with a link to this thread. On 10 December 2017 at 22:41, Andreas Hennings <andr...@dqxtech.net> wrote: > > > On 7 December 2017 at 03:04, Stanislav Malyshev <smalys...@gmail.com> > wrote: >> >> All this to achieve no

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

On 7 December 2017 at 03:04, Stanislav Malyshev wrote: > > All this to achieve no other benefit but a purely cosmetic one which a > good IDE could easily deliver to you for free without changing language > syntax. I do not think it is worth it. > I agree with Stanislav, this

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

On 9 December 2017 at 16:19, Aidan Woods wrote: > > where the three lines return `false`, the third [...] > > Oops, that should say "the first two lines return `true`, the third > `false`" (the point here being that they return something, as opposed to > the later three,

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On 3 January 2018 at 21:26, Rowan Collins wrote: > Hi Michael, > > On 02/01/2018 10:35, Michael Morris wrote: >> >> I would like to propose a clean way to add some strong typing to PHP in a >> manner that is almost fully backward compatible (there is a behavior >> change

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On 5 January 2018 at 11:35, Dan Ackroyd wrote: > On 5 January 2018 at 02:01, Michael Morris wrote: >> >> what if the underlying zval wasn’t a zval but a separate >> class specific to the data type but implementing the same interface as >> zval? > > I

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

Whether we work with runtime type checks or compile-time static analysis: The user-facing language design questions would still be the same, right? E.g. we would still have to distinguish type-locked parameter values vs dynamically typed parameter values. On 10 January 2018 at 20:23, Andreas

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On 10 January 2018 at 19:59, Rasmus Lerdorf wrote: > > Now if the RFC was a plan for baking a compile-time static analysis engine > into PHP itself, that would be interesting. But that is a *massive* project. Even with my limited understanding of the engine, I can imagine

[PHP-DEV] null coalesce addition assignment operator ??+=

The "Null Coalescing Assignment Operator" (or null coalesce assignment operator) was proposed and accepted in https://wiki.php.net/rfc/null_coalesce_equal_operator I propose even more such operators: null coalesce addition assignment ??+= (for strings and numbers) null coalesce subtraction

[PHP-DEV] Re: null coalesce addition assignment operator ??+=

018 at 23:52, Andreas Hennings <andr...@dqxtech.net> wrote: > The "Null Coalescing Assignment Operator" (or null coalesce assignment > operator) was proposed and accepted in > https://wiki.php.net/rfc/null_coalesce_equal_operator > > I propose even more such ope

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

I will not On 22 January 2018 at 22:11, Stanislav Malyshev wrote: > Hi! > >> I want to see strict typing as an option, not a requirement. > > You seem to be under impression that this somehow makes things easier. > It does not. To explain: let's say you design a strictly

Re: [PHP-DEV] var_export() array format

On 18 February 2018 at 02:04, David Rodrigues wrote: > I just think that is not responsability of PHP to care about output format > at core level (although we have the json pretty output support...). Why not? E.g. JSON_PRETTY_PRINT is something I use a lot, often in

[PHP-DEV] var_export() array format

I sometimes use var_export() to export a structured array and then copy+paste it into my code. And sometimes I use it as part of an automatic code generator. Unfortunately, the output is usually not in the format that I want, or that is common for most projects / code styles. - Indentation is 2

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

> I think that a "scalar" type that "groups together" bool, float, int, and > string would make more sense. This would allow the expression that something > is not an array, not an object, and not a resource. Why would this be an either/or? I don't mind a "scalar" type hint. But this could be a

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

This proposal contains some interesting ideas, which I see as separate: 1. A syntax to declare the type of local variables. 2. A syntax to declare the type of object properties. 3. Preventing local variables, object properties and parameters to change their type after initialization/declaration.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

d outside the range of the declare() statement. I only mention it here because it relates to the proposal. I do not have a strong opinion on it atm. On 3 January 2018 at 18:10, Andreas Hennings <andr...@dqxtech.net> wrote: > This proposal contains some interesting ideas, which I se

Re: [PHP-DEV] Re: [PATCH] Make var_export() output "(object)array(..." instead of"stdClass::__set_state(..." for stdClass

I do not disagree, just want to make an observation. If multiple properties or array keys reference the same instance of \stdClass, there will be multiple instances with identical values after a round-trip with var_export() + eval(). This is not necessarily a problem, just something to be aware

Re: [PHP-DEV] null coalesce addition assignment operator ??+=

On 19 January 2018 at 16:12, Sara Golemon wrote: > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker > wrote: >> On 18.01.2018 at 23:58, Stanislav Malyshev wrote: >> I propose even more such operators: null coalesce addition assignment ??+= (for

Re: [PHP-DEV] null coalesce addition assignment operator ??+=

As mentioned earlier: In hack (hhvm), operators like +=, *= etc do allow the left side to be undefined. (However, ++ and -- do not allow the left side to be undefined.) I wonder if this is intended, or by accident. On 20 January 2018 at 06:47, Andreas Hennings <andr...@dqxtech.net>

Re: [PHP-DEV] null coalesce addition assignment operator ??+=

On 20 January 2018 at 04:29, Aidan Woods <aidantwo...@gmail.com> wrote: > On 20 January 2018 at 01:25, Andreas Hennings <andr...@dqxtech.net> wrote: >> >> On 19 January 2018 at 16:12, Sara Golemon <poll...@php.net> wrote: >> > On Thu, Jan 18, 2018 at 7:13

Re: [PHP-DEV] null coalesce addition assignment operator ??+=

On 20 January 2018 at 12:02, Midori Koçak wrote: > What is going on here? I think I missed the original post. https://externals.io/message/101620 Here you can find all messages. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Traits with interfaces

> don't use traits Yes, in general, yes. Composition is great, and I use it most of the time. I still do have some cases where I think that base classes (with private properties) are justified, and then some cases where either traits or multiple inheritance would be justified. We could agree to

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

Hello, my thoughts. For me personally the proposed feature would not be very useful. i like immutable objects. But for me the pattern of choice is private properties + constructor + optional "wither" methods. The "wither" methods create a clone of the object, then set a property value on the

Re: [PHP-DEV] Bringing Peace to the Galaxy

On Fri, 30 Aug 2019 at 19:38, Chase Peeler wrote: > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings > wrote: > > The only way to make this possible is to either deny all progress, or > > to make a distinction on file level (or "package level", whatever that > >

Re: [PHP-DEV] Bringing Peace to the Galaxy

I would very much like to see "editions" or "generations". > I do plan to create an RFC on this topic. I am looking forward to this Proposal from Nikita. So, at the risk of repeating some ideas that Nikita already mentioned elsewhere, I am sharing my own thoughts.. ## Motivation In this

Re: [PHP-DEV] Bringing Peace to the Galaxy

PHP 7.n would already be more strict than it the non-opt-in flavor of PHP 7.n is now. Having the possibility to let files opt-in can allow for bolder and faster innovation, with less holding back. On Sat, 31 Aug 2019 at 03:52, Andreas Hennings wrote: > > On Sat, 31 Aug 2019 at 03:40, Reindl H

Re: [PHP-DEV] Bringing Peace to the Galaxy

On Sat, 31 Aug 2019 at 02:31, Larry Garfield wrote: > [..] > Whether editions is the "right" way to balance "don't break 1 million lines > of 15 year old code" with "this behavior is bad and we all know it" and with > "this behavior leads to sloppy code that is prone to bugs", I don't know. >

Re: [PHP-DEV] Bringing Peace to the Galaxy

. A project which nowadays would run a PHP version somewhere between the oldest and the newest, would now be able to run the latest PHP version most of the time. On Sat, 31 Aug 2019 at 02:31, Larry Garfield wrote: > > On Fri, Aug 30, 2019, at 1:56 PM, Andreas Hennings wrote: > > On Fr

Re: [PHP-DEV] Bringing Peace to the Galaxy

On Sat, 31 Aug 2019 at 03:40, Reindl Harald wrote: > > > > Am 30.08.19 um 20:56 schrieb Andreas Hennings: > > In one of -these modules I initially used the ?? null coalesce operator. > > Then I had to replace all of the instances of ?? with the more verbose >

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

I think we should distinguish two separate problems in the discussion: 1. Undeclared local variables in function scope. Some poeple here think this "lazy" way of coding is actually more productive. Fixing such places would be straightforward.. except that it may require patching some legacy 3rd

Re: [PHP-DEV] Mixed mode methods

In my experience, things that have different roles or behavior should be differently named. I have seen a lot of functions with dynamic return types based on a mode set in the parameter (e.g. the return type could be string, string[] or string[][] depending on whether some parameter is NULL or

Re: [PHP-DEV] RFC: var_export - short syntax for array

Avoiding disruption is indeed a concern. As an example, Drupal 7 features module uses a custom variation of var_export() to write configuration to code, which is then typically tracked in git. I am not sure if changing the native var_export() would have an impact here, and anyway the module can

Re: [PHP-DEV] Silent Types

In some other languages the mixed type is called "variant". https://en.m.wikipedia.org/wiki/Variant_type I mostly remember it from VisualBasic. Lynn schrieb am Mi., 4. Sep. 2019, 09:22: > Hi, > > Would this warrant a having mixed types? By making every variable of type > "mixed" when no type is

Re: [PHP-DEV] Silent Types

On Wed, 4 Sep 2019 at 09:22, Lynn wrote: > > Note that this behavior would require making some decisions whether or not > in the future this opt-in behavior should change when a default value is > given, such as with C# and type inference when declaring a variable, based > on its assigned value.

Re: [PHP-DEV] Silent Types

On Wed, 4 Sep 2019 at 18:09, Ben Ramsey wrote: > > > Andreas Hennings wrote: > > > > In some other languages the mixed type is called "variant". > > https://en.m.wikipedia.org/wiki/Variant_type > > I mostly remember it from VisualBasic. > >

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

I would like to make a wild proposal. ## Proposal Similar to spl_autoload_register(), we would provide a function that allows to register a callback to provide the declares / edition / compatibility information for a given file, before this file is loaded. To address performance concerns: - The

Re: [PHP-DEV] Changing fundamental language behaviors

Indeed, for the case of local variables that were undefined before, this can usually be fixed in a straightforward way by initializing to NULL. The goal here is to get rid of the error or notice while preserving the original behavior (even if it was buggy). This is IF this is your own custom

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

In the past I suggested operators like ??++ ??+= for this purpose. But the [? $key] is even better, because it makes it explicit which array keys we expect to already exist and which we don't. $var[$k0][? $k1][? $k2]++; This is great but the second "?" is redundant isn't it? Marco Pivetta

Re: [PHP-DEV] Features related to Object Initializers

On Tue, 17 Sep 2019 at 00:21, Larry Garfield wrote: > [..] > I think everyone's in agreement about: > > 1) Making objects easier to work with. > 2) Devs should use objects more. > > (Side note: I have an article submitted to php[architect] entitled "Never* > use arrays" that goes into this topic

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

I am not a voting member, but I agree with Sara Golemon. This is just too big a BC break. I had similar questions in my own projects, and always chose to find a solution that does not break BC. The strategy was: - Keep existing classes and interfaces stable. - Introduce new classes or interfaces

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

To have any information content, a variable (or return value, or parameter) needs to have more than one possible value. If one of those values is TRUE, the most natural alternative value would be FALSE. But should this really be baked into the language? Should really "try to be smart" here? Isn't

Re: [PHP-DEV] Optional pre-compiler for PHP8?

On Wed, 30 Oct 2019 at 22:06, Rowan Tommins wrote: > > Hi Dik, > > On 29/10/2019 21:44, Dik Takken wrote: > > Opcache already performs type inference. [...] > > Here is an interesting read on the subject: > > > > https://depositonce.tu-berlin.de/bitstream/11303/7919/3/popov_etal_2017.pdf > > >

Re: [PHP-DEV] [RFC] anti-coalescing-operator

On Fri, 25 Oct 2019 at 12:27, Andreas Hennings wrote: > > On Fri, 25 Oct 2019 at 12:21, Rowan Tommins wrote: > > > > On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote: > > > > > But I think this functionality should be of something like pipeline > > >

Re: [PHP-DEV] [RFC] anti-coalescing-operator

On Fri, 25 Oct 2019 at 12:21, Rowan Tommins wrote: > > On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote: > > > But I think this functionality should be of something like pipeline > > operator: > > > > // send tmp variable to the next expression unconditionally > > $ret = $_SERVER['fname'] |>

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

I agree with the distinction described by Nikita. There are definitely cases where a special return value is still the best option. In addition I would say in some cases it can be useful to have both versions available: One that returns FALSE or NULL, another that throws an exception. This is for

Re: [PHP-DEV] [RFC] anti-coalescing-operator

On Thu, 24 Oct 2019 at 20:59, Ken Stanley wrote: > > On Thu, Oct 24, 2019 at 1:33 PM Dan Ackroyd wrote: > > > On Thu, 24 Oct 2019 at 18:21, Ken Stanley wrote: > > > > > > Since PHP 7.0 brought forward the Null Coalescing Operator (??), writing > > > more succinct code for how to handle null

  1   2   3   >