Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

On Mon, Jan 25, 2016 at 6:05 AM, Stanislav Malyshev wrote: > Hi! > >> Now, if we are still adamant on coming up with a CoC first I would like >> to put forward the following 3 documents as alternatives for the >> Contributor Covenant: >> >> >> [A contribution policy for open

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

On Wed, Jan 20, 2016 at 10:20 PM, Derick Rethans <der...@php.net> wrote: > On Wed, 20 Jan 2016, Pavel Kouřil wrote: > >> On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans <der...@derickrethans.nl> >> wrote: >> > >> > I've decided t

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans wrote: > Hi, > > I've decided to re-propose the CoC RFC. There are many reasons for it, > but there are a few points I want to make. > > > cheers, > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

/unsub.php >> >> Hello, and what about changing the empty ctor of Closure to __construct(callable $callable)? And the usage would be new Closure([$this, 'abc']);? Regards Pavel Kouřil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

ce. Althought I'd honestly really prefer the Bob's syntax, but I understand that you don't want to make some engine hacks to make it working - but from userland developer's POV, that one was the best (speaking as someone, who would use the syntax daily). -- Regards Pavel Kouřil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Arrow function expressions in PHP

On Tue, Sep 29, 2015 at 11:55 PM, Levi Morrison wrote: > Reading over the list I don't think people "are torn about" it. There > are some detractors, sure, but there seem to be more detractors about > symbol choice (~) and lack of type declarations. Personally, I feel that

Fwd: [PHP-DEV] Arrow function expressions in PHP

> > How does hack solve this? Do they have backtracking in their parser? > > It was discussed earlier & Bob answered it, a T_LAMDA_OP is inserted > by a token token-pre-parser before hitting the real parser, see: > > Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures > Date: Sun, 6 Sep 2015

Re: [PHP-DEV] Arrow function expressions in PHP

On Tue, Sep 29, 2015 at 12:52 AM, Levi Morrison wrote: > > I do not think it is feasible to make the parser do backtracking or > anything of that sort. How do others feel? > >> PS: the [fn($x) => $x * 2] seems ambigous, from reader's POV; key of >> the item is result of fn($x) and

Re: [PHP-DEV] Arrow function expressions in PHP

the correct one. Also not introducing any more "stuff" (like new parameter types syntax) would be a plus. For the need to have a single parameter enclosed with ( ) - by thinking more and more about it, I think that having the one special case for not requiring parenthesis around parameters is pretty uselss, since it would have to be there anyways if you wrote the typehint. PS: the [fn($x) => $x * 2] seems ambigous, from reader's POV; key of the item is result of fn($x) and value is $x * 2? Also, it would be a huge BC break with not allowing you to name functions fn(), wouldn't it? -- Regards Pavel Kouřil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

is with single parameter. I was thinking about this, and with the type hints, it would be probably better anyways to have the ( ) required, so that would be just a single use case where they wouldn't be required - so is there a point in keeping this special use case? Regards Pavel Kouřil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implementing Generics, and none scalar default properties.

ail.com > Since there is no reason not to call parent ctor, maybe PHP should somehow make every class have default empty ctor, if it doesn't have one defined already - so you can write automatically parent::__construct() everywhere? Regards Pavel Kouřil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

+ $scores[$type]" seems pretty confusing to me. Also, if we look at the example from RFC - with your "as" suggestion, it would look like this: function reduce(callable $fn) { return $initial as $input as { $accumulator = $initial; foreach ($input as $value) {

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

ere; on the other hand, we don't know why the rest of those ~30 people voted no, so it's really hard to say. Anyways, thanks for sending the Ressurecting rejected proposals info. :) Regards Pavel Kouřil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

able to assign numeric value to each element (and have them implicit if not specified). This is imho better for serialization (but it can be done with names as well, yeah) - but more importantly, it also allows usage with bitwise operators, so you could use them as a "flags" (ie. $weekend

Re: [PHP-DEV] Re: [RFC] [Discussion] Short Closures

On Mon, Sep 7, 2015 at 8:24 AM, Marco Pivetta wrote: > > The same usually applies to ~, {, }, [ and ]. > I personally stopped buying non-en_US keyboards and that's it. > Basically, if you code you kinda want to use en_US layout anyway (or dvorak > if you had too much free

Re: [PHP-DEV] Re: [RFC] [Discussion] Short Closures

On Sun, Sep 6, 2015 at 11:54 PM, Andrea Faulds wrote: > Hi Bob, > > This has probably already come up, but I'd like to weigh in on the symbol > choice. > > On the subject of syntax, ~> (let's call it the squiggle arrow) seems like a > very poor choice compared to ==> (let's call it

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind <peter.e.l...@gmail.com> wrote: > On 4 September 2015 at 08:44, Pavel Kouřil <pajou...@gmail.com> wrote: > > You're arguing that, subjectively, to you - parentheses make things harder > to read. For others they clarify things

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Thu, Sep 3, 2015 at 11:56 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Pavel Kouřil wrote on 03/09/2015 07:32: >> >> Amendment 2. Make the ~> operator non-associative > > >> Why? Once you read documentation about how the operator works and what >

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Thu, Sep 3, 2015 at 12:48 AM, Rowan Collins wrote: > > So I would like to put forward for consideration these amendments to the > proposal, in the spirit of compromise (in no particular order; numbers are > just for reference in future discussion): > > Amendment 1.

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Tue, Sep 1, 2015 at 10:45 AM, Tony Marston wrote: > > This argument is irrelevant for several reasons: > (1) I am not familiar with any of those languages, nor are many PHP users. > (2) Just because other languages have such a feature is not a good reason > for adding

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Tue, Sep 1, 2015 at 10:44 AM, Anthony Ferrara wrote: >> I'm not sure about the "auto using" of all variables though; wouldnt >> it be possible to statically check for the used variables and only >> import what's needed, for performance reasons? > > That's precisely what's

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand wrote: > I had this RFC in draft since some time, but delayed it due to all the > ongoing PHP 7 discussions. Also we have no master branch to merge features in > until 5.4 EOL. Thus I'm reviving this now. > > Time for the first

Re: [PHP-DEV] Generic classes and methods RFC

On Mon, Aug 31, 2015 at 10:31 PM, Ben Scholzen 'DASPRiD' wrote: > Hello, > > I've written up an RFC for supporting generic classes and methods in PHP, > and I'd love to hear your thoughts about it. > > https://wiki.php.net/rfc/generics > > Cheers, > -- > Ben Scholzen 'DASPRiD' >

Re: [PHP-DEV] [VOTE] Exceptions in the engine

On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann sebast...@php.net wrote: Am 13.05.2015 um 08:30 schrieb Pierre Joye: Why don't you do it? You have access and you are a very good writer. No big C knowledge required either in this case :) There was/is consensus on what I proposed back in

Re: [PHP-DEV] Naming of 'weak' type hints

On Mon, Mar 30, 2015 at 4:16 PM, Zeev Suraski z...@zend.com wrote: All, One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- PHP

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com wrote: On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote: On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net wrote: Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit : Hello, how will these examples work btw? // a.php ?php declare(strict_types=1); function foo($fn) { $fn(1); }; // b.php ?php

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote: Pavel, On Wed, March 18, 2015 11:05, Pavel Kouřil wrote: On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com wrote: On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote: On Mon, Mar 16

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote: Pavel, On Wed, March 18, 2015 11:05, Pavel Kouřil wrote: On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com wrote: On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote: On Mon, Mar 16

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On Wed, Mar 18, 2015 at 1:13 PM, Nikita Nefedov inefe...@gmail.com wrote: On 18 Mar 2015 14:32, Pavel Kouřil pajou...@gmail.com wrote: On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net wrote: Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com wrote: On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote: Hello, I made that conclusion because in the first example, the library kinda forces strict mode rules on the caller, even if he doesn't want to use strict

Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)

On Mon, Mar 16, 2015 at 8:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I think this is important, but not many people realize the importance. Therefore I created this as a new thread at the last minutes of vote. On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz den...@birkholz.biz

Re: [PHP-DEV] About declare(strict_types = 1)

This RFC will have serious consequence. We made mistake with safe_mode. The main reason it failed is it did not force caller to have responsibility to make it work as it should. This RFC does the same for how declare(strict_types=1) works. Aren't we learned from safe_mode lessons? I am

Re: [PHP-DEV] About declare(strict_types = 1)

On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd dan...@basereality.com wrote: On 16 March 2015 at 11:49, Pavel Kouřil pajou...@gmail.com wrote: Seriously, think about it for a while - when some setting that changes how code behaves was a good idea? The problem is that there are two

Re: [PHP-DEV] About declare(strict_types = 1)

On Mon, Mar 16, 2015 at 11:04 PM, Pierre Joye pierre@gmail.com wrote: On Mar 16, 2015 11:16 PM, Pavel Kouřil pajou...@gmail.com wrote: I can't speak for anyone who voted, but personally, if I could vote, I would voted no - not because I don't want to block people from getting what

Re: [PHP-DEV] About declare(strict_types = 1)

On Monday, March 16, 2015, Derick Rethans der...@php.net wrote: On Mon, 16 Mar 2015, Jordi Boggiano wrote: On 16/03/2015 11:49, Pavel Kouřil wrote: it's similiar to the safe_mode though. Sure, it's not as bad as INI setting, but the intent is the same - a switch changing how code behaves

Re: [PHP-DEV] Re: A plea for unity on scalar types

On Fri, Mar 13, 2015 at 8:51 PM, Scott Arciszewski sc...@arciszewski.me wrote: Pavel_Kouřil wrote: - It is a setting that changes the language's behavior; I don't think that it matters whether or not it would be an INI setting or the declare() one, because both of them are bad. It allows

Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7

On Sat, Mar 14, 2015 at 12:38 PM, Bob Weinand bobw...@hotmail.com wrote: Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajou...@gmail.com: On Saturday, March 14, 2015, Levi Morrison le...@php.net wrote: RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7 The proposal has changed

Re: [PHP-DEV] Re: A plea for unity on scalar types

On Sun, Mar 15, 2015 at 9:56 AM, Leigh lei...@gmail.com wrote: On 15 March 2015 at 08:42, Pavel Kouřil pajou...@gmail.com wrote: Sure, per-file is better than ini setting, but better doesn't mean good (because it is still a pretty bad approach). The ini setting at least has the option

Re: [PHP-DEV] [VOTE] Exceptions in the engine

On Sun, Mar 15, 2015 at 8:27 AM, Sebastian Bergmann sebast...@php.net wrote: Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann: So who will draft the RFC for * Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that

Re: [PHP-DEV] [RFC] Basic Scalar Types

On Sun, Mar 15, 2015 at 6:48 PM, Anthony Ferrara ircmax...@gmail.com wrote: Zeev, Zeev, allow me to understand how this goes. Bob's discussions on the RFC started 2 days ago. Based on the current rules, the RFC can only go to vote after 2 weeks. That means in 12 days starting now. So we

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

On Sun, Mar 15, 2015 at 5:55 PM, Zeev Suraski z...@zend.com wrote: Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

On Sun, Mar 15, 2015 at 10:11 PM, Philip Sturgeon pjsturg...@gmail.com wrote: I am sorry for hurting your feelings but you are being manipulative and I am not a fan of that. I have no agenda, I just want to see you put an end to this weird rule bending, definition changing, rule ignoring

Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7

On Saturday, March 14, 2015, Levi Morrison le...@php.net wrote: RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7 The proposal has changed from the original. It no longer reserves the aliases out of the interest of reserving the smallest useful, uncontroversial subset. Some

Re: [PHP-DEV] A plea for unity on scalar types

On Fri, Mar 13, 2015 at 10:01 PM, Philip Sturgeon pjsturg...@gmail.com wrote: Pavel, On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com wrote: On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote: But for today, I firmly believe that the Dual-Mode proposal

Re: [PHP-DEV] A plea for unity on scalar types

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote: But for today, I firmly believe that the Dual-Mode proposal is the only one that stands a chance of passing. I think it's the best chance for the language, and it's the only one that tries to unite the different

Re: [PHP-DEV] [RFC] Basic Scalar Types

It shouldn't prevent any future improvements and still give use all the advantages of scalar types. Besides what I think of proposing yet another RFC, -1 because it is basically what the initial idea from the opponents of optional strict mode wanted before they go with the latest one. It

Re: [PHP-DEV] [RFC] Basic Scalar Types

On Wednesday, March 11, 2015, Bob Weinand bobw...@hotmail.com wrote: Am 11.03.2015 um 23:29 schrieb Pavel Kouřil pajou...@gmail.com: It shouldn't prevent any future improvements and still give use all the advantages of scalar types. Besides what I think of proposing yet another RFC, -1

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

On Fri, Feb 20, 2015 at 8:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com wrote: I think that naming the new parent exception something like Throwable or Catchable (as Nikita previously suggested) would be a bit more

Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting

On Wed, Feb 25, 2015 at 10:09 AM, Zeev Suraski z...@zend.com wrote: -Original Message From: Leigh [mailto:lei...@gmail.com] Sent: Tuesday, February 24, 2015 2:56 PM To: Albert Casademont Filella Cc: Benjamin Eberlei; PHP Internals Subject: Re: [PHP-DEV] The Game Theory of Scalar Type

Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

On Tue, Feb 24, 2015 at 8:48 AM, Alexander Lisachenko lisachenko...@gmail.com wrote: Morning! I want to ask this question one more time before PHP7 feature freeze: can we the engine case sensitive from PHP=7.0? There is a draft for that: https://wiki.php.net/rfc/case-sensitivity (mostly

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

On Mon, Feb 23, 2015 at 10:28 AM, Joe Watkins pthre...@pthreads.org wrote: Zeev, If you can infer the type with confidence, you can do away with coercion code altogether. Maybe I'm ignorant of something, but isn't the only way you can begin to infer the type with real confidence is by

Re: [PHP-DEV] [VOTE] Exceptions in the engine

On Tue, Feb 24, 2015 at 12:03 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Nikita, On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov nikita@gmail.com wrote: Voting on the engine exceptions RFC, which proposes to convert existing fatal and recoverable fatal errors into exceptions, has

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Sun, Feb 22, 2015 at 2:09 PM, Robert Stoll p...@tutteli.ch wrote: I see the migration plan roughly as follows: PHP 7.0: - reserve keywords: bool, int, float including alternatives - deprecate alternative type names such as boolean, integer etc. - introduce new conversion functions

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Sun, Feb 22, 2015 at 7:30 PM, Robert Stoll p...@tutteli.ch wrote: Hi Pavel, Yes, I am suggesting to make conversions behave the same regardless if it is implicit or explicit. The only difference between the two should be that one is stated explicitly by the user where the other is

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Sun, Feb 22, 2015 at 9:42 PM, Robert Stoll p...@tutteli.ch wrote: Probably it is a philosophical question how to look at it. IMO the only difference in C# (as well as in Java) lies in the way the conversions are applied. Implicit conversions are applied automatically by the compiler where

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski z...@zend.com wrote: There’s a fundamental difference between the two RFCs that goes beyond whether using a global INI setting and the other per-file setting. The fundamental difference is that the endgame of the Dual Mode RFC is having two modes

Re: [PHP-DEV] Reviving scalar type hints

On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre franc...@php.net wrote: De : Pavel Kouril [mailto:pajou...@gmail.com] Hello, I know this is probably a pretty unpopular opinion in PHP (based on the replies I got in the other thread), but different values for parameters should be IMHO

Re: [PHP-DEV] Annotations in PHP7

On Wed, Feb 18, 2015 at 9:45 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil pajou...@gmail.com wrote: As a Doctrine user, I find this way worse than current state. This syntax looks UGLY and contains a lot of useless clutter. And yeah, adding

Re: [PHP-DEV] Annotations in PHP7

On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi Dmitry, Are you (and Doctrine team) interested in this annotation idea? I'd say that Benjamin nailed in our possible usage: orm(new Entity(foo)) class Foo { } Now I do feel we need to

Re: [PHP-DEV] Reviving scalar type hints

On Mon, Feb 16, 2015 at 5:42 PM, François Laupretre franc...@php.net wrote: Hi, - the fact that the RFC supports single types only, like the previous 'return type' RFC. While it is easier to implement, it opens several issues as multiply-typed arguments are an integral part of the PHP

Re: [PHP-DEV] Annotations in PHP7

On Mon, Feb 16, 2015 at 1:33 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 1:17 PM, Pavel Kouřil pajou...@gmail.com wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@zend.com wrote: hi, During discussion of different ways of implementing Design

Re: [PHP-DEV] Reviving scalar type hints

On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre franc...@php.net wrote: De : Pavel Kouril [mailto:pajou...@gmail.com] Hello, I know this is probably a pretty unpopular opinion in PHP (based on the replies I got in the other thread), but different values for parameters should be IMHO

Re: [PHP-DEV] Annotations in PHP7

On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@zend.com wrote: hi, During discussion of different ways of implementing Design by Contract we got an idea of using annotations. BTW: annotations are useful by their own and may be used for different purposes. Support for annotations was

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 12, 2015 at 3:31 PM, Andrea Faulds a...@ajf.me wrote: Hi Pavel, On 12 Feb 2015, at 13:48, Pavel Kouřil pajou...@gmail.com wrote: C# does have dynamic typing. No it doesn’t, it’s a statically-typed language. I don’t understand why you say it has dynamic typing - there is some

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Pavel Kouřil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 12, 2015 at 1:45 PM, Andrea Faulds a...@ajf.me wrote: Hi Pavel, C# also doesn’t have dynamic typing. Plus, adding overloading to an existing language is more difficult. C# does have dynamic typing. Adding method overloading to an existing language may be more difficult than

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 12, 2015 at 12:44 PM, Andrea Faulds a...@ajf.me wrote: PHP already has polymorphism through its dynamic typing. I don’t see method overloading happening any time soon. We have optional parameters and dynamic typing, which all but eliminate the main needs for overloading. We’re a

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds a...@ajf.me wrote: A number (or numeric, or num, or some other name) type hint is something I plan to propose in a future, follow-up RFC. Hello, wouldn't polymorphism (via method overloading) solve the use cases and be much more useful in the

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

On Tue, Feb 10, 2015 at 1:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike.

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Wed, Feb 11, 2015 at 7:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/10/2015 07:57 PM, Xinchen Hui wrote: am I wrong?! seems I am wrong with this, it's a false alarm... it can restore automatically. Yeah, declare() doesn't span files so that isn't a problem. My worry is still

Re: [PHP-DEV] Design by Contract

On Tue, Feb 10, 2015 at 1:30 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: 2015-02-10 15:20 GMT+03:00 Dmitry Stogov dmi...@zend.com: I thought about this way, and you are welcome to start composing another RFC. it makes sense and has its advantages. Unfortunately, it relays on many

Re: [PHP-DEV] Design by Contract

There are a lot of researches in this field. PHP has a great opportunity to not close the doors by forcing a language. I suggest you to offer an API to hook on the runtime and “control” it, like AOP does. It will open the doors to so many interesting contributions! Hello, after reading

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Mon, Feb 9, 2015 at 9:04 AM, Dmitry Stogov dmi...@zend.com wrote: this is more or less true. :( The proposal is presented in an unfair way to include strict typing without the ability to vote for weak types only. Despite of semantic arguments, the implementation is a bit immature and

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Mon, Feb 9, 2015 at 9:22 AM, Pierre Joye pierre@gmail.com wrote: I am not saying I want one or the other (I have voted and now only focus on solving possible tech issues we may find) but trying to be fair with Andrea's RFC and amazing effort: What you ask is basically part of the RFC

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Sat, Feb 7, 2015 at 11:11 PM, Andrea Faulds a...@ajf.me wrote: Hi, On 7 Feb 2015, at 22:03, Pavel Kouřil pajou...@gmail.com wrote: Yeah, but you say in the RFC that With this approach, an argument is only accepted if its type is exactly the same as the parameter. when speaking about C

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds a...@ajf.me wrote: Good evening, At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. Hello, I just realized it now (I brought it up in a different

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds a...@ajf.me wrote: Hi, On 7 Feb 2015, at 20:47, Andrea Faulds a...@ajf.me wrote: On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote: I just realized it now (I brought it up in a different manner when there was discussion about

Re: [PHP-DEV] What do we need strict scalar type hints for?

On Thu, Feb 5, 2015 at 9:59 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! However I feel like the fact that it only affects your app (even if you use a library relying on strictness) if you want to is not clear for everyone replying here. Is this point clear for you? I was

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

On Wed, Feb 4, 2015 at 6:17 PM, Andrea Faulds a...@ajf.me wrote: Hey, On 4 Feb 2015, at 17:10, Crypto Compress cryptocompr...@googlemail.com wrote: I would go with Http\ Why not the reserved Php\Http\? This sounds good to me. php\ is already reserved, and it’s similar to the common

Re: [PHP-DEV] [VOTE] Combined Comparison (Spaceship) Operator

On Mon, Feb 2, 2015 at 11:50 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I personally would use spaceship operator often, but only if PHP had operator overloading for classes. So I hope it will pass and operator PHP has operator overloading for classes, but just for internal ones.

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

On Wed, Feb 4, 2015 at 2:00 PM, Michael Wallner m...@php.net wrote: Hi! Do we want to discuss anything further before I put this to vote again? https://wiki.php.net/rfc/pecl_http Points explicitely marked for discussion in the RFC itself: * pecl/propro Proxies for properties

Re: [PHP-DEV] [VOTE] Combined Comparison (Spaceship) Operator

Hello, I personally would use spaceship operator often, but only if PHP had operator overloading for classes. So I hope it will pass and operator overloading will pass someday as well (but operator overloading would probably require method overloading first and that's a thing you guys oppose,

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye pierre@gmail.com wrote: There is zero reason to discuss what has been approved and followed for years already. I will simply post the link to our CS as a reminder and ask everyone to read it if they never did:

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner m...@php.net wrote: Hi, Discussion has been very low on this topic since it was proposed on August 19th, so I just opened the vote on the RFC whether to add pecl_http to the core. The vote will be open until about 12:00 UTC on Friday, February

Re: [PHP-DEV] [RFC] Scalar Type Hints

On Sun, Jan 25, 2015 at 5:02 AM, Andrea Faulds a...@ajf.me wrote: Hi everyone, Just a few small updates. I’ve made a small change to this RFC. Instead of the strict mode syntax being declare(strict_typehints=TRUE), it’s now declare(strict_types=1) instead. This makes it a bit quicker to

Re: [PHP-DEV] [RFC] Scalar Type Hints

On Sun, Jan 25, 2015 at 5:05 PM, Andrea Faulds a...@ajf.me wrote: Hi Pavel, Hi, thanks for explaining some things. It can *sometimes* be a lossless conversion. Only sometimes. For float to int conversion: * Floats have the special values INF, NAN and -NAN, which cannot be preserved *

Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list

On Fri, Jan 23, 2015 at 10:18 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): master branch. propro, raphf and pecl_http do not compile with the master branch. You'll have to checkout the phpng branch. These extensions did compile

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggi...@seld.be wrote: Reading the thread at this point shows so much confusion, it seems half the people reading the spec misunderstood that the declare() line affects function calls only and not the API/implementation level. As much I

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

On Thu, Jan 15, 2015 at 4:35 PM, Jordi Boggiano j.boggi...@seld.be wrote: I mean that if someone wants strict typing they won't want to use weak hints because that would coerce the data before they can verify it and ensure their code is strictly typed. Therefore the best course of action is

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano j.boggi...@seld.be wrote: Right now, or with only weak hints, if a library decides to implement strict typing, they'll skip the scalar hints and check types with something like the assert lib [1]. A user calling it with random data would *always*

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

On Thu, Jan 15, 2015 at 9:29 AM, Lester Caine les...@lsces.co.uk wrote: One of the nice features of PHP when I started using it all those years ago was that I did not have to create separate functions different types did exist in the source data. int/float/num/double and others all needed

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

On Wed, Jan 14, 2015 at 11:28 PM, Andrea Faulds a...@ajf.me wrote: From what I can see, the larger PHP community is generally in favour of strict typing, and among them, the previous RFC revision was received quite poorly. Myself, I might have been somewhat happy with just weak hints, but it

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

Hello, personally, as a language user, I really dislike the idea of both options for scalar type hinting to be the part of the language. Especially since you would have to declare the strict typing in each file (if you are going by 1 class per file in a bigger project, that's a LOT of declare