> -Ursprüngliche Nachricht-
> Von: Ryan Pallas [mailto:derokor...@gmail.com]
> Gesendet: Sonntag, 5. Juni 2016 14:22
> An: Robert Stoll
> Cc: Bob Weinand; Andrea Faulds; internals@lists.php.net
> Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
>
>
>
Hi Andrea, Bob
> -Ursprüngliche Nachricht-
> Von: Bob Weinand [mailto:bobw...@hotmail.com]
> Gesendet: Sonntag, 5. Juni 2016 01:00
> An: Andrea Faulds
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
>
>
> > Am 05.06.2016 um 00:55 schrieb Andrea Fau
> > In this case I would suggest to use class A which leaves room
> > open to define lower bounds later on
>
> IMHO that is bordering on unreadable - all those brackets are really
> confusing and hard on the eyes.
>
I agree, it looks quite ugly :-)
Therefore another suggestion:
class A [Foo <
> -Ursprüngliche Nachricht-
> Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
> Gesendet: Montag, 25. April 2016 18:09
> An: Josh Di Fabio
> Cc: Dominic Grostate; Guilherme Blanco; Mathieu Rochette; Ben Scholzen
> 'DASPRiD'; Sara Golemon; PHP internals; Mathieu
> Rochette
> Betreff: Re:
Hi Rasmus
> Hello internals,
>
> I'd like to introduce an RFC proposing the addition of generic types and
> functions:
>
> https://wiki.php.net/rfc/generics
>
> Ben Scholzen started this RFC as a quick draft with a few code samples in
> August last year, and I have since then worked
> with
Hi Andrea
I am writing you in private since I think this is rather out of scope.
-Ursprüngliche Nachricht-
> Von: Pierre Joye [mailto:pierre@gmail.com]
> Gesendet: Montag, 18. Januar 2016 05:54
> An: Andrea Faulds
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Allow specifying ke
Hi,
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Montag, 28. Dezember 2015 00:21
> An: Julian Rhind; internals@lists.php.net
> Betreff: Re: [PHP-DEV] RFC proposal for alternative list syntax
>
> Hi!
>
> > // With the new array syntax this
Hi Larry,
> -Ursprüngliche Nachricht-
> Von: Larry Garfield [mailto:la...@garfieldtech.com]
> Gesendet: Samstag, 24. Oktober 2015 00:36
> An: internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöpening)
>
> On 10/16/2015 11:56 A
Anthony,
> -Ursprüngliche Nachricht-
> Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Gesendet: Freitag, 16. Oktober 2015 17:23
> An: Robert Stoll
> Cc: Andrea Faulds; internals@lists.php.net
> Betreff: Re: [PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöp
Hi Andrea
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Donnerstag, 15. Oktober 2015 23:04
> An: internals@lists.php.net
> Betreff: [PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöpening)
>
> Hi everyone,
>
> Andrea Faulds wrote:
> > I'm reviving my Voi
> > I would like to see a short syntax for closures in PHP but would
> > suggest to use different symbols for the operator. Why not use --> ?
> >
>
> --> is a shift-reduce conflict. It's undecidable if this expression
> --> should
> return boolean or a closure:
> `$foo-->$bar` (is it `$foo --> $ba
Hi Bob
> -Ursprüngliche Nachricht-
> Von: Bob Weinand [mailto:bobw...@hotmail.com]
> Gesendet: Montag, 31. August 2015 21:29
> An: PHP Internals
> Betreff: [PHP-DEV] [RFC] [Discussion] Short Closures
>
> I had this RFC in draft since some time, but delayed it due to all the
> ongoing PHP
Hi Stas
> -Ursprüngliche Nachricht-
> Von: Joe Watkins [mailto:pthre...@pthreads.org]
> Gesendet: Montag, 7. September 2015 09:15
> An: Stanislav Malyshev
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility
> modifiers in PHP 7.1+
>
> > However, I h
> -Ursprüngliche Nachricht-
> Von: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Gesendet: Montag, 13. Juli 2015 02:12
> An: Larry Garfield; internals@lists.php.net
> Betreff: Re: [PHP-DEV] PHP7 and types
>
> On 07/12/2015 12:37 PM, Larry Garfield wrote:
> > I don't know why we're even ta
Borrowing from C#, I would suggest the names implicit and explicit argument
> types. There is nothing "weak" about them,
> they just do an implicit conversion which can be quite powerful if used
> correctly.
>
[Robert Stoll]
It's probably hard to come up with something wh
> -Ursprüngliche Nachricht-
> Von: Pierre Joye [mailto:pierre@gmail.com]
> Gesendet: Montag, 23. März 2015 06:57
> An: Juan Basso
> Cc: Stanislav Malyshev; PHP Internals
> Betreff: Re: [PHP-DEV] Serializing exceptions
>
> On Mon, Mar 23, 2015 at 12:31 PM, Juan Basso wrote:
> > Maybe
> -Ursprüngliche Nachricht-
> Von: Matthew Leverton [mailto:lever...@gmail.com]
> Gesendet: Sonntag, 15. März 2015 20:46
> An: Anthony Ferrara
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Voting irregularities
>
> On Sun, Mar 15, 2015 at 9:19 AM, Anthony Ferrara wrote:
> > All,
> -Ursprüngliche Nachricht-
> Von: Patrick Schaaf [mailto:p...@bof.de]
> Gesendet: Samstag, 7. März 2015 08:22
> An: Philip Sturgeon
> Cc: internals; Robert Stoll
> Betreff: Re: [PHP-DEV] [RFC] Anonymous Classes
>
> Am 06.03.2015 20:14 schrieb "Philip Sturgeo
Heya,
Does PHP store somewhere meta-information of all internal functions (and
operators) in a portable format such as XML?
I would like to extract information such as
- parameters including types
- return type
automatically. Preferably each overload of a function but I guess that does not
ex
> -Ursprüngliche Nachricht-
> Von: Philip Sturgeon [mailto:pjsturg...@gmail.com]
> Gesendet: Mittwoch, 4. März 2015 16:49
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Anonymous Classes
>
> On Tue, Mar 3, 2015 at 12:03 PM, Robert Sto
s
>
> There's a little RFC + patch that Joe Watkins put together, and as before
> with the ArrayOf RFC, I'll be helping out.
>
[Robert Stoll]
I like the RFC +1 :)
Can I also use traits in combination with anonymous classes?=3D20
--
PHP Internals - PHP Runtime Dev
> -Ursprüngliche Nachricht-
> Von: julienpa...@gmail.com [mailto:julienpa...@gmail.com] Im Auftrag von
> Julien Pauli
> Gesendet: Donnerstag, 26. Februar 2015 10:27
> An: Dmitry Stogov
> Cc: Alexander Lisachenko; PHP internals list
> Betreff: Re: [PHP-DEV] [Discussion] Last chance for cas
Hi Nikita
> -Ursprüngliche Nachricht-
> Von: Nikita Popov [mailto:nikita@gmail.com]
> Gesendet: Montag, 6. Oktober 2014 23:54
> An: PHP internals
> Betreff: [PHP-DEV] [RFC] Exceptions in the engine
>
> Hi internals!
>
> During the PHP 5.6 development cycle I have proposed an RFC [1]
Hey Anthony,
> -Ursprüngliche Nachricht-
> Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Gesendet: Montag, 23. Februar 2015 15:28
> An: Robert Stoll
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
>
> Robe
Heya Anthony,
> -Ursprüngliche Nachricht-
> Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Gesendet: Montag, 23. Februar 2015 14:53
> An: Robert Stoll
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
>
> Rob
Hey all,
tl;dr
Just one point which JIT/AOT people should consider when dealing with PHP. PHP
is highly dynamic and there are enough use cases which makes it impossible for
a static analyser to infer types accurately without using a top type like mixed.
How would you deal with variable function
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 22:18
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015 at 9:42
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 20:02
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015 at 7:30
Hi Pavel,
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 15:54
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015
Hi Zeev,
> -Ursprüngliche Nachricht-
> Von: Zeev Suraski [mailto:z...@zend.com]
> Gesendet: Samstag, 21. Februar 2015 18:22
> An: PHP internals
> Betreff: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> All,
>
>
>
> I’ve been working with François and several other people from internals@
Hi Nikita,
> -Ursprüngliche Nachricht-
> Von: Niktia Nefedov [mailto:inefe...@gmail.com]
> Gesendet: Freitag, 20. Februar 2015 22:43
> An: internals@lists.php.net
> Betreff: [PHP-DEV] Allow to use argument unpacking at any place in
> arguments list
>
> Hey folks,
>
> Currently argument
Hi Dmitry and Anthony,
I was skimming through your conversation about JIT/AOT and that type hints
would allow to optimise few things.
I do not know if you are aware of the following but type hints can be passed
by. Hence neither weak or strict type hints allow to predict the type (even if
only
Hey Anthony,
> -Ursprüngliche Nachricht-
> Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Gesendet: Mittwoch, 18. Februar 2015 21:45
> An: internals@lists.php.net
> Betreff: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
>
> Dear Internals,
>
> Since the resignation of Andrea
> -Ursprüngliche Nachricht-
> Von: Zeev Suraski [mailto:z...@zend.com]
> Gesendet: Mittwoch, 18. Februar 2015 14:03
> An: Robert Stoll
> Cc: Sara Golemon; PHP internals
> Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
>
> > -Original Message-
>
> -Ursprüngliche Nachricht-
> Von: Zeev Suraski [mailto:z...@zend.com]
> Gesendet: Mittwoch, 18. Februar 2015 08:00
> An: Nikita Popov; Rasmus Lerdorf
> Cc: Sara Golemon; PHP internals
> Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
>
> > -Original Message-
> > From: Nikita Popov [
Hi François
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net]
> Gesendet: Sonntag, 15. Februar 2015 11:43
> An: 'Robert Stoll'; 'Yasuo Ohgaki'
> Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav M
Hi Yasuo
> -Ursprüngliche Nachricht-
> Von: yohg...@gmail.com [mailto:yohg...@gmail.com] Im Auftrag von Yasuo Ohgaki
> Gesendet: Samstag, 14. Februar 2015 23:54
> An: Robert Stoll
> Cc: francois; Dmitry Stogov; Joe Watkins; Stanislav Malyshev; PHP Internals
> Betreff: Re
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Samstag, 14. Februar 2015 22:38
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Void Return Type
>
> Hi Robert,
>
> > On 14 Feb 2015, at 21:23, Rober
Hi Andrea,
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Samstag, 14. Februar 2015 04:18
> An: PHP Internals
> Betreff: [PHP-DEV] [RFC] Void Return Type
>
> Hi everyone,
>
> I’ve written a small RFC and patch to add a “void” return type:
>
> https://w
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net]
> Gesendet: Samstag, 14. Februar 2015 07:17
> An: 'Yasuo Ohgaki'
> Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav Malyshev'; 'PHP Internals'
> Betreff: RE: [PHP-DEV] Design by Contract
>
> I will try to explain
Hi François,
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@tekwire.net]
> Gesendet: Donnerstag, 12. Februar 2015 18:01
> An: 'Robert Stoll'; 'Nikita Nefedov'; 'Andrea Faulds'
> Cc: 'Pavel Kouřil'; 'PHP
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Donnerstag, 12. Februar 2015 17:50
> An: Robert Stoll
> Cc: Nikita Nefedov; Pavel Kouřil; PHP Internals
> Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Hey Robert,
>
&
> -Ursprüngliche Nachricht-
> Von: Nikita Nefedov [mailto:inefe...@gmail.com]
> Gesendet: Donnerstag, 12. Februar 2015 15:54
> An: Andrea Faulds
> Cc: Pavel Kouřil; PHP Internals
> Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Hi,
>
> 2015-02-12 18:31 GMT+04:00 Andrea Faulds :
>
>
We could provide an Invariant class in order to support invariant cases at
least to a certain degree:
http://3v4l.org/vjBRG
Of course, that does not provide the same support as native invariants but
maybe better than nothing. At least we would have a consistent Invariant class
throughout the c
> -Ursprüngliche Nachricht-
> Von: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Gesendet: Sonntag, 8. Februar 2015 04:53
> An: Andrea Faulds
> Cc: Pavel Kouřil; PHP Internals
> Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> On 02/07/2015 09:51 PM, Andrea Faulds wrote:
> >> tan(1);
>
> -Ursprüngliche Nachricht-
> Von: julienpa...@gmail.com [mailto:julienpa...@gmail.com] Im Auftrag von
> Julien Pauli
> Gesendet: Donnerstag, 5. Februar 2015 13:10
> An: Andrea Faulds
> Cc: Hannes Magnusson; Nikita Popov; PHP internals
> Betreff: Re: [PHP-DEV] Allow dropping typehints dur
Hi Dimitry
> -Ursprüngliche Nachricht-
> Von: Dmitry Stogov [mailto:dmi...@zend.com]
> Gesendet: Donnerstag, 5. Februar 2015 12:14
> An: Yasuo Ohgaki; PHP Internals
> Betreff: [PHP-DEV] Design by Contract
>
> Hi Yasuo,
>
> Following our conversation, I tried to imagine how DbC should loo
> -Ursprüngliche Nachricht-
> Von: Robert Stoll [mailto:p...@tutteli.ch]
> Gesendet: Mittwoch, 4. Februar 2015 20:24
> An: 'Nikita Popov'; 'PHP internals'
> Betreff: AW: [PHP-DEV] Allow dropping typehints during inheritance
>
>
> > -Urs
> -Ursprüngliche Nachricht-
> Von: Nikita Popov [mailto:nikita@gmail.com]
> Gesendet: Mittwoch, 4. Februar 2015 19:50
> An: PHP internals
> Betreff: [PHP-DEV] Allow dropping typehints during inheritance
>
> Hi internals!
>
> Currently we do not allow [1] removing a typehint during in
> -Ursprüngliche Nachricht-
> Von: Dmitry Stogov [mailto:dmi...@zend.com]
> Gesendet: Mittwoch, 4. Februar 2015 10:26
> An: Sebastian Bergmann
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for?
>
> hi Sebastian,
>
> Do you like the proposal with dec
> -Ursprüngliche Nachricht-
> Von: Lester Caine [mailto:les...@lsces.co.uk]
> Gesendet: Montag, 2. Februar 2015 21:06
> An: internals@lists.php.net
> Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for?
>
> On 02/02/15 09:12, Dmitry Stogov wrote:
> > could you please write
> -Ursprüngliche Nachricht-
> Von: Dmitry Stogov [mailto:dmi...@zend.com]
> Gesendet: Montag, 2. Februar 2015 20:14
> An: Robert Stoll
> Cc: PHP Internals; Andrea Faulds; Nikita Popov
> Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for?
>
> On Mon
Hi Dimitry,
> -Ursprüngliche Nachricht-
> Von: Dmitry Stogov [mailto:dmi...@zend.com]
> Gesendet: Montag, 2. Februar 2015 10:13
> An: PHP Internals; Andrea Faulds; Nikita Popov
> Betreff: [PHP-DEV] What do we need strict scalar type hints for?
>
> hi,
>
> could you please write down few
> from that change? Maybe you can expand on
> that in the RFC.
>
> sincerely,
> - Markus
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php
[Robert Stoll]
I agree with Markus, the benefits for users whic
I would like to pick up this discussion again - now that the return type hint
RFC has passed, congratulations :)
As a quick reminder, this discussion should not be whether we want to put the
return types on the left or on the right but mainly if we want to have
consistency (I do not want to dow
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Freitag, 16. Januar 2015 21:35
> An: Robert Stoll; 'Marc Bennewitz'; internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] [RFC] Skipping parameters take 2
>
> H
Hi Stas,
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Mittwoch, 14. Januar 2015 21:26
> An: Marc Bennewitz; internals@lists.php.net
> Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2
>
> Hi!
>
> > Is it possible to use the default
Hi Andrea
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Mittwoch, 14. Januar 2015 01:17
> An: PHP Internals List
> Betreff: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RF
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Dienstag, 23. Dezember 2014 19:34
> An: Robert Stoll; 'Leigh'; guilhermebla...@gmail.com
> Cc: 'PHP internals'
> Betreff: Re: AW: [PHP-DE
s define instantiation
> usage, rather than a strict visibility.
>
> I haven't looked at your patch in detail. My PoC code revolved around
> comparing the start of class names with the current
> namespace. Is yours the same? How do you feel about extending this to
> functi
> -Ursprüngliche Nachricht-
> Von: Josh Watzman [mailto:jwatz...@fb.com]
> Gesendet: Mittwoch, 10. Dezember 2014 19:43
> An: Robert Stoll
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Nullsafe calls
>
> On Dec 10, 2014, at 8:17 AM, Robert Stoll wrote:
>
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Mittwoch, 10. Dezember 2014 20:21
> An: Josh Watzman
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Nullsafe calls
>
> Hi again.
>
> > On 10 Dec 2014, at 19:11, Josh Watzman wrote:
> >
> > On Dec 10,
> -Ursprüngliche Nachricht-
> Von: Robert Stoll [mailto:p...@tutteli.ch]
> Gesendet: Mittwoch, 10. Dezember 2014 17:20
> An: 'Josh Watzman'; 'PHP internals'
> Betreff: AW: [PHP-DEV] [RFC] Nullsafe calls
>
> > -Ursprüngliche Na
> -Ursprüngliche Nachricht-
> Von: Robert Stoll [mailto:p...@tutteli.ch]
> Gesendet: Mittwoch, 10. Dezember 2014 17:17
> An: 'Josh Watzman'; 'PHP internals'
> Betreff: AW: [PHP-DEV] [RFC] Nullsafe calls
>
> Hi,
>
> > -Ursprüngliche
Hi,
> -Ursprüngliche Nachricht-
> Von: Josh Watzman [mailto:jwatz...@fb.com]
> Gesendet: Mittwoch, 10. Dezember 2014 00:08
> An: PHP internals
> Betreff: [PHP-DEV] [RFC] Nullsafe calls
>
> Hey internals! A useful feature that Hack picked up in the last few months
> are "nullsafe calls",
Heya,
I would like to know If it is somehow possible to overload existing functions
by extensions. And if it is possible, are
there already some extension doing it?
I am not talking about the magic __call function. I am talking about something
like: let's assume GMP has overloaded the
funct
Hi Guilherme,
I read your updated RFC:
https://wiki.php.net/rfc/abstract_final_class
IMO the RFC as such makes sense now (abstract final confusion is eliminated. In
addition to turn methods implicitly into static methods, the __construct of a
static class should be implicitly private as well.
I
> -Ursprüngliche Nachricht-
> Von: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] Im Auftrag von
> Levi Morrison
> Gesendet: Dienstag, 25. November 2014 18:09
> An: internals
> Betreff: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
>
> Dear Internals,
>
> As you may
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Dienstag, 18. November 2014 10:21
> An: PHP Internals
> Betreff: [PHP-DEV] [RFC] Default constructors
>
> Hi!
>
> I'd like to propose the following RFC, which in short would allow any method
>
> -Ursprüngliche Nachricht-
> Von: are.you.winn...@gmail.com [mailto:are.you.winn...@gmail.com] Im Auftrag
> von Chris Wright
> Gesendet: Donnerstag, 13. November 2014 13:13
> An: Johannes Schlüter
> Cc: Robert Stoll; Adam Harvey; PHP Internals
> Betreff: Re: AW:
> -Ursprüngliche Nachricht-
> Von: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Gesendet: Donnerstag, 13. November 2014 11:57
> An: internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] forbid use declaration outside of a namespace in
> PHP 7
>
> Robert Stoll w
> Sorry, I apparently missed this the first time. Would this mean that this
> sort of script (where we're using use statements
> without a
> namespace) would no longer work?
>
> use GuzzleHttp\Client;
>
> include __DIR__.'/vendor/autoload.php';
>
> $client = new Client;
> // $client is a Guz
> -Ursprüngliche Nachricht-
> Von: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Gesendet: Mittwoch, 12. November 2014 17:21
> An: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Annotation PHP 7
>
> Marco Pivetta wrote on 05/11/2014 14:02:
> > For example, this alternative approach pe
> -Ursprüngliche Nachricht-
> Von: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Gesendet: Mittwoch, 12. November 2014 00:45
> An: Andrea Faulds; Robert Stoll
> Cc: Chris Wright; PHP Internals
> Betreff: Re: [PHP-DEV] forbid use declaration outside of a namespac
> I would say that the lack of anyone saying "no, don't do this" probably means
> everyone is OK with it. Suggest you work up a
> patch and PR it, then ping the list to highlight it for further discussion.
>
Sounds reasonable but unfortunately I do not have time at the moment to work up
a patch
> -Ursprüngliche Nachricht-
> Von: Robert Stoll [mailto:p...@tutteli.ch]
> Gesendet: Mittwoch, 29. Oktober 2014 20:55
> An: 'PHP Internals'
> Betreff: [PHP-DEV] forbid use declaration outside of a namespace in PHP 7
>
> Heya,
>
> I always found it ve
> I guess it's worth noting that my *personal* opinion is that I'd also rather
> have the function return type declaration on the
> left (I'd also like to drop the requirement for the "function" keyword in
> method declarations), but since there are a number
> of reasons why this no longer makes
> -Ursprüngliche Nachricht-
> Von: are.you.winn...@gmail.com [mailto:are.you.winn...@gmail.com] Im Auftrag
> von Chris Wright
> Gesendet: Dienstag, 4. November 2014 12:51
> An: Andrea Faulds
> Cc: Stas Malyshev; Robert Stoll; PHP Internals
> Betreff: Re: AW: [PHP-DE
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Montag, 3. November 2014 16:40
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] Types on the right or on the left
>
>
> > On 3 Nov 2014, at 15:07, Robert Sto
> -Ursprüngliche Nachricht-
> Von: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] Im Auftrag von
> Levi Morrison
> Gesendet: Montag, 3. November 2014 19:54
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] Types on the right or on the left
&g
Heya,
Its seems to me that more and more RFC are proposed to augment PHP's syntax
with some form of additional type hints.
The following RFC proposes to add a type hint for the return type of a
function/method:
https://wiki.php.net/rfc/returntypehinting
It adds the type hint on the right hand s
Heya,
I always found it very ugly that it is possible to define a use outside of a
namespace. Consider the following:
namespace{ //default namespace
}
use foo\Bar;
namespace test{
new Bar(); //error, test\Bar not found
}
After some thoughts it is quite clear that Bar is test\Bar and not fo
> -Ursprüngliche Nachricht-
> Von: Weinand Bob [mailto:bobw...@hotmail.com]
> Gesendet: Mittwoch, 22. Oktober 2014 16:16
> An: Dmitry Stogov
> Cc: Andrea Faulds; PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
> If we really want an integer at all price we just can u
Hi Joe,
I have not devoted myself to unicode and thus cannot give you a feedback on
your implementation.
Nevertheless, I was wondering whether string interpolation is still supported
by your solution (couldn't find anything in the RFC about it but maybe you
thought that is implicit given).
Che
> In your given example, $this is defined when A::bar() is called;
> interestingly, when this class is extended it will
still only call
> A::bar() as opposed to calling $this->bar(). Whether this is useful behaviour
> is irrelevant :)
>
Right, I completely forgot that. So calling it with self
Hey,
I just stumbled over a method call of a non-static method with self and was
asking myself again, why does PHP support
this behaviour. An example to outline what I am writing of:
class A{
function foo(){
self::bar();
}
function bar(){}
}
IMO it should not be allowed
> >
> > I do not think it makes sense to take the number of commits as metric.
> > People's commit behaviour is different. Some commit only once after
> > everything is done and others commit regularly after each achieved
> > small step towards the goal.
> > I belong rather to the second group. Why
> one of your pr's did not keep the author info, it seems as it was squashed
> into a single commit:
> http://git.php.net/?p=php-src.git;a=commit;h=ec2fff80e768dfb04aa393c06a2b1a42a9e871ff
> so it isn't a problem with the list, but how your PR was merged.
> ofc. probably there are other similar c
> -Ursprüngliche Nachricht-
> Von: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Gesendet: Mittwoch, 17. September 2014 18:01
> An: internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] Renaming type-hints to something else?
>
> Robert Stoll wrote (on 16/09/201
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Dienstag, 16. September 2014 17:26
> An: Levi Morrison
> Cc: internals
> Betreff: Re: [PHP-DEV] Renaming type-hints to something else?
>
>
> On 16 Sep 2014, at 16:24, Levi Morrison wrote:
>
> > On Tue, Se
Heya,
I remember that some people were complaining about the inconsistencies
between normal conversions and the one applied in Andrea's RFC about "Scalar
Type Hinting With Casts".
https://wiki.php.net/rfc/scalar_type_hinting_with_cast
As an example:
$i = (int) "a"; //fine without errors
functio
> -Original Message-
> From: Alain Williams [mailto:a...@phcomp.co.uk]
> Sent: Wednesday, July 16, 2014 11:17 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> On Wed, Jul 16, 2014 at 09:31:46AM +0100, Rowan Collins wrote:
>
>
gt; I'm not much into Perl or Ruby, either, but I agree that an unless keyword
> would be a very nice thing to have. However, I'm still not sure how that
> would solve the isset problem. If the variable doesn't exist, are you
> saying that encapsulating it within the unless arg w
little sense.
>
> Besides that, I am not sure what is the goal of this thread. Adding aliases
> to copy cat ?
[Robert Stoll]
I really don't see what you have against copy cat if this
language has actually solved a problem nicely (hence PHP could benefit from the
idea).
And in my case
least "not_null".
> "isset" seems to be a different category, if only because the verb is not
> visually separated from the condition.
>
> So "if (isnull($a))" would again be more natural. But because the verb is
> visually separated using the underscore, you g
Heya,
Just to be sure, this feature would not allow nested classes in functions,
right?
Cheers,
Robert
> -Original Message-
> From: Joe Watkins [mailto:krak...@php.net]
> Sent: Sunday, September 29, 2013 11:12 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] RFC: Draft: Nested Clas
Heya
I would like to have some opinions on the topic inconsistency between
methods and __construct
See the following code:
class A {
function __construct($a) {}
function foo($a) {}
}
class B extends A {
function __construct($a, $b) {}
ler.
> >
>
> People express themselves in different ways ...
>
> It is mostly just about expressing the same thing in different ways, we
can
> find justification for it when pushed, because we are being pushed ...
>
> I'm a bit confused by this idea that every
applications for both), so I'd
> > appreciate some more opinions on the topic.
>
> Although it might allow users to shoot into their foot, I prefer having it
> instead of introducing a limitation that is not technically necessary. So
+1
>
> cu,
> Lars
[Robert Stoll]
> -Original Message-
> From: Robert Stoll [mailto:rst...@tutteli.ch]
> Sent: Sunday, September 08, 2013 12:36 AM
> To: 'Adam Harvey'; 'Dan Ackroyd'
> Cc: 'Nikita Popov'; 'PHP internals'
> Subject: RE: [PHP-DEV] [RFC] Name
1 - 100 of 120 matches
Mail list logo
