Re: [PHP-DEV] Re: Checkout phpdoc

workflow it's not as easy as we all thought to do the actual move. For more infos feel free to head over to https://github.com/phpdoctest/meta Cheers Andreas -- ,,,

Re: [PHP-DEV] The real world ...

things. Cheers Andreas > > Cheers, > Sjon > > On Thu, Jun 13, 2019 at 9:56 AM Andreas Heigl wrote: > >> Hey All >> >> Am 13.06.19 um 09:41 schrieb Nikita Popov: >>> On Thu, Jun 13, 2019 at 9:35 AM Lester Caine wrote: >>> >>>> Seen

Re: [PHP-DEV] The real world ...

Hey Lester, hey All Am 13.06.19 um 10:36 schrieb Lester Caine: > On 13/06/2019 08:55, Andreas Heigl wrote: >>> display_errors=Off in production. > > Which give a white screen ... fine for security but useless for people > using the site! > >> While that makes a

Re: [PHP-DEV] The real world ...

thinking whether there is a way to mark password-parameters in core-functions and hide them in Stack-traces might improve security as that would also hide user-provided credentials in log-files. That would not target userland methods/functions. Though having a Core-Value-object fo

Re: [PHP-DEV] Wiki display problem

r NNTP (nntp.php.net). I'd need to check how much reconfiguration that'd mean though... And that might mean that others will need to change their endpoints from news.php.net to nntp.php.net. IIRC externals.io f.e. uses NNTP to retrieve the messages Cheers A

Re: [PHP-DEV] Wiki display problem

Looks like the stylesheets are loaded from shared.php.net which still seems to be on an old certificate. Therefore the styles are not loaded Who can have a look into that? Cheers Andreas Am 03.06.19 um 12:52 schrieb Joe Watkins: > I think this may be related to the ssl issues from earl

Re: [PHP-DEV] Re: [RFC] Allow throwing exceptions from __toString()

hnically a BC-break (as you state in the RFC) I wondered why the target is PHP7.4 and not 8. So far I didn't find a discussion on that but I might not have dug deep enough. So if this has already bee

Re: [PHP-DEV] RFC Process: more productive conversations

way all the information would be readily available in the RFC and no one would need to add comments after an RFC was voted upon. Because IMO that information as well as the process that lead to acceptance of the RFC are also important to afterwards make clear why that feature was implememted

Re: [PHP-DEV] Old style constructors in PHP-8

f PHP > sometime > this year (no promises, but that's the scuttlebutt), which would let > them > convert to __construct() universally and safely well before PHP 8 > becomes an > issue. AFAIK WP requires PHP5 already as the minimum PHP-Version. And AFAIK __construct worked with tha

Re: [PHP-DEV] bugs.php.net usability, migration to a different tool

s that the package names are indented by category, > which makes it impossible to autocomplete a package name using your > keyboard. > > The correct way to do this is to surround each category in an > tag, which distinguishes category names from package names. > > -- > Zach Hoffman Feel free to open a PR against https://github.com/php/web-bugs  Thanks for helping out! Cheers Andreas

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] [PATCH] new function for real local date

ocale); > > return $date; > } May I ask what you actually mean by "real local date for day names and month names"? Or is this something like this: Cheers Andreas -- ,,,

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

elsewhere. -- Why not a userland implementation? E.g. https://packagist.org/packages/riimu/kit-phpencoder var_export() is often used in experimental code or when just playing around, situations where developers usually prefer to avoid adding a 3rd party dependency. Also there is no way t

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

[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

[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

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

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

le (there is a behavior >> change >> with PHP 7 type declarations). As I don't have access to the add RFC's to >> the wiki I'll place this here. > > > Thanks for putting this together. Perhaps unlike Andreas, I think it is good > to look at typing changes as a unified

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] [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] Mailing list moderation

an one doc whose letter or spirit can be debated. But debating is one thing, taking action is another one. Just my 0.02€ Cheers Andreas [0] http://php.net/mailing-lists.php [1] http://git.php.net/?p=php-src.git;a=blob_plain;f=README.MAILINGLIST_RULES;hb=HEAD [2]

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

t combine different scalar typehints. And it could even allow typehinting different Objects in one function. Yes, it allows people to shoot themselfes into their own feet. And I'd only allow that for parameter types and never ever for return types. But it might be an idea. Cheers Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

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

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

[PHP-DEV] Covariance, again

o, this behavior is the same as today, except for the case of return type hints that differ from the parent, which currently result in fatal error. Does this sound doable? Am I missing something else? -- Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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] [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] 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.

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.

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

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

[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

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

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

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

Re: [PHP-DEV] Re: PHP's mail servers suck

>> someone should be up for one, but not both tasks. >> > > In this case I believe that they are one and the same Peter. As the > issues with the mailing list(s), are actually issues with the mail server > itself.And Andreas is correct. Multiple times in the past

Re: [PHP-DEV] Re: PHP's mail servers suck

offer noted, we might come back to you". Even better with actually getting back… But as it is currently the chances are that we will have to live with a messy list-server and over time probably move somewhere else for discussions as the old system becomes more and more unreliable… Just my (f

[PHP-DEV] Proposal: Rename image functions

For a better readability of the gd functions I would like to rename them so that they contain underscores to separate the words. The only exception is image2wbmp which is renamed to image_to_wbmp. The order of the parameters of all functions whould be unchanged. Due to the unchanged

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

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

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

[PHP-DEV] Re: [RFC] Match expression

Hi, Something like: function match($x) { switch(true) { case $x === 1: return 'Tiny'; case is_numeric($x) && $x <= 10: return 'Small'; case is_numeric($x) && $x <= 20: return 'Medium'; case is_numeric($x) && $x <= 30:

Re: [PHP-DEV] Consider only ignoring newlines for final ?> in a file

I always assumed that this is the reason why we do this in the first place. I think the main reason was that old versions of ie go into quirksmode if the doctype is not in the first line of the output e.g.: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [VOTE] UUID

Hey Richard Am 05.09.17 um 19:29 schrieb Fleshgrinder: > On 9/5/2017 7:01 PM, Andreas Heigl wrote: >> Hey Richard, Hey all. >> >> Thanks for putting up the RFC and the implementation! >> >> Having UUIDs in the core would be awesome. One of the reasons would be &g

Re: [PHP-DEV] [VOTE] UUID

ty and a naging feeling that the imlementation decides what I as a user actually need. That's why I can't vote "yes". Sorry. Thanks for putting in the effort and coming up with a first implementation. Cheers Andreas PS: Personally I don't like a "uuid_4_create" as that would also me

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

w Eater instanceof Eater); // => (bool) false var_dump(new Eater instanceof Eater); // => (bool) true The only supertype for all Eater<*> types would be Eater. This super-eater has the absolute fruit allergy. On Wed, Aug 23, 2017 at 9:18 AM, Michał Brzuchalski <mic...@brzuchalski.com&

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"

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

extends FruitEater { function eat(Banana $banana); } So, would the "empty type" become obsolete? Maybe. I did not arrive at a final conclusion yet. It still seems too interesting to let it go. -- Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Slow DateTimeZone::getTransitions with no argument

Hi, Is the first entry in the return value of http://php.net/manual/en/datetimezone.gettransitions.php with the timestamp PHP_INT_MIN / ZEND_LONG_MIN intended? The difference with no arguments is over 100 times slower on 64 bit systems: DateTimeZone::getTransitions() Duration: 0.075577

Re: [PHP-DEV] Happy World Elephant Day

rest… And some back-story for the WorldElephantDay: http://worldelephantday.org Cheers Andreas > > Happy world elephant day again, > Midori Kocak > -- ,,,

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

at 7:46 PM, Andreas Treichel <gmb...@gmail.com> wrote: > You can merge the result with default values like this: > > [$foo, $bar, $foobar] = explode(':', 'foo:bar') + [23, 42, 1337]; > var_dump($foo, $bar, $foobar); > > > > > -- > PHP Internals - PHP Runtime Devel

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

You can merge the result with default values like this: [$foo, $bar, $foobar] = explode(':', 'foo:bar') + [23, 42, 1337]; var_dump($foo, $bar, $foobar); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

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

Sometimes I use a workaround like this: list($prefix, $suffix) = explode(':', $string . ':'); if ('' !== $suffix) { ... } Which works, but means a new string will be allocated in memory. I find the list() with default values to be a decent and understandable language feature. -- Andrea

[PHP-DEV] Re: [PHP-WEBMASTER] Subscribe Function Seems to be down for several days

Seems like the mailinglist needs some love… again… Cheers Andreas Am 03.08.17 um 17:02 schrieb Alan Feuerbacher: > I've been trying for several days to subscribe to a PHP mailing list, > but I keep getting the message "We were unable to subscribe you due to > some technical pr

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

much better guideline than following a wrong idea of consistency. - Finally, I don't know why everything needs to be abbreviated. Having str_* instead of string_* seems ok to me, and is consistent with existing string functions. But my first idea would have been more comp

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

t of php engine? - more C code to maintain - a new doc page. Did I miss something? -- -- Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

Hi, So I propose to make the gc_disable function accept one zval reference as parameter. And if gc_disable get that zval, gc_disable just drop the zval’s GC_COLLECTABLE flag, which will hint the PHP gc not to trace that zval. i dont know if this is a good idea or not. But for the "s" in

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

Hi Andrey, 1. The wording here implies that these are the *only* attributes allowed. In the interest of forward-compatibility, I'd allow arbitrary attributes as well. I just try to implement something like this, to allow arbitrary attributes. Is this what you prefer?

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

Hello Andrey, That's what I was afraid of, and what I suggested be changed. If we had a similar, array-of-attributes API that did NOT ignore or trigger warnings for unknown attributes, everybody using PHP would've been able to use SameSite already. I think it is necessary to trigger a notice

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

Hi Michał, As an average developer, I see providing new functions with http_ prefix more meaningful and their API more simple because of fewer parameters I need to pass. Although however, I see the naming convention you've used is rarely used. Looking in the docs, there are few other HTTP

[PHP-DEV] Request for karma

Hi, I registered my wiki account "Blar" and need some karma for my first RFC for new cookie functions. I already posted some infos about "http_cookie_set and http_cookie_remove" on the mailinglist. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] bugs.php.net website

-- Andreas Heigl andr...@heigl.org > Am 20.07.2017 um 14:03 schrieb Johannes Schlüter <johan...@schlueters.de>: > >> On Do, 2017-07-20 at 14:06 +0200, Niklas Keller wrote: >> I'm fine with no user registration required, but there should >> definitely be a

Re: [PHP-DEV] php.net website

it simple and stupid. But thats - as I said - just my 0.02€ Cheers Andreas PS: As it's a pretty massive change to the infrastructure I'd personally think there should be an RFC about that. > > > > > >> On 19 July 2017 at 21:12, Andreas Heigl <andr...@heigl.org&

Re: [PHP-DEV] php.net website

eem to be "PHP-approved" to people not that deep into the website (so about 99% of PHP-developers). So the PHP-website would - even though that might not be intended - recommend frameworks or libraries over others. And we would not want that! Just my 0.02 € Cheers Andreas >

<    1   2   3   4   5   6   >