On Mon, Jan 25, 2016 at 9:21 AM, Stanislav Malyshev wrote:
> Hi!
>
>> I already submitted it here once, so I'm skipping it - but I do
>> personally like how it says the project is about code.
>
> But it's not. Not only. Code is the result, sure, at least one of, but
> there's a lot of things invol
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 source that
>> works](
On Wed, Jan 20, 2016 at 10:20 PM, Derick Rethans wrote:
> On Wed, 20 Jan 2016, Pavel Kouřil wrote:
>
>> On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans
>> wrote:
>> >
>> > I've decided to re-propose the CoC RFC. There are many reasons for it,
>&
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 unsubscribe, visit: http://
>> Thanks to Joe and Bob for the assistance in the patch.
>>
>> cheers
>> Dan
>> Ack
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
Hello,
and what a
etty nice.
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
>
> 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 1
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 without the auto impor
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 value is $x * 2?
IMHO be 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
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
ince 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
ve parenthesis
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
arameter
$sum and parameter type as $sum + $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 = $ini
n 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 =
Days::S
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 time).
> I realize that t
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 Hack's arrow).
On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind wrote:
> On 4 September 2015 at 08:44, Pavel Kouřil wrote:
>
> You're arguing that, subjectively, to you - parentheses make things harder
> to read. For others they clarify things.
> It should be obvious to everyone that this pa
On Thu, Sep 3, 2015 at 11:56 AM, Rowan Collins 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
>> it does, you will know it
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. Only allow the single-express
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 it into PHP.
> (3) Introdu
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 happening. Not all var
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'
> Community Review T
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 RFC targeting PHP 7.1 (
On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann 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 February:
>
On Mon, Mar 30, 2015 at 4:16 PM, Zeev Suraski 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 this
>
On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski wrote:
> Pavel,
>
> On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
>> On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye
>> wrote:
>>
>>>
>>> On Mar 18, 2015 4:56 PM, "Pavel Kouřil" wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov wrote:
> On 18 Mar 2015 15:52, "Pavel Kouřil" 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&#x
On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski wrote:
> Pavel,
>
> On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
>> On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye
>> wrote:
>>
>>>
>>> On Mar 18, 2015 4:56 PM, "Pavel Kouřil" wrote:
On Wed, Mar 18, 2015 at 1:13 PM, Nikita Nefedov wrote:
>
> On 18 Mar 2015 14:32, "Pavel Kouřil" wrote:
>>
>> On Wednesday, March 18, 2015, Patrick ALLAERT
>> wrote:
>> > Le mer. 18 mars 2015 à 10:56, Pavel Kouřil a écrit
>> > :
>> &g
On Wednesday, March 18, 2015, Patrick ALLAERT
wrote:
> Le mer. 18 mars 2015 à 10:56, Pavel Kouřil a écrit :
>>
>> Hello,
>>
>> how will these examples work btw?
>>
>> // a.php
>> > declare(strict_types=1);
>> function foo($fn) {
>>
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye wrote:
>
> On Mar 18, 2015 4:56 PM, "Pavel Kouřil" wrote:
>>
>> On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
>> wrote:
>> > All,
>> >
>> > Voting has been closed on the scalar t
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara 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 Internals -
On Mon, Mar 16, 2015 at 11:04 PM, Pierre Joye wrote:
>
> On Mar 16, 2015 11:16 PM, "Pavel Kouřil" 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 blo
On Mon, Mar 16, 2015 at 8:53 PM, Yasuo Ohgaki 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
> wrote:
>
>> Am 16.03.2015 um 06
On Monday, March 16, 2015, Derick Rethans 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
On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd wrote:
> On 16 March 2015 at 11:49, Pavel Kouřil 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
>>
>> 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"
On Sun, Mar 15, 2015 at 10:11 PM, Philip Sturgeon 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 "convenient" interpr
On Sun, Mar 15, 2015 at 6:48 PM, Anthony Ferrara 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 ar
On Sun, Mar 15, 2015 at 5:55 PM, Zeev Suraski 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
> propose my own
On Sat, Mar 14, 2015 at 12:38 PM, Bob Weinand wrote:
>> Am 14.03.2015 um 10:21 schrieb Pavel Kouřil :
>>
>> On Saturday, March 14, 2015, Levi Morrison wrote:
>>> RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
>>>
>>> The proposa
On Sun, Mar 15, 2015 at 9:56 AM, Leigh wrote:
>
> On 15 March 2015 at 08:42, Pavel Kouřil 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 o
On Fri, Mar 13, 2015 at 8:51 PM, Scott Arciszewski 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 people w
On Sun, Mar 15, 2015 at 8:27 AM, Sebastian Bergmann 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 implements the
On Saturday, March 14, 2015, Levi Morrison 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 people want to
On Fri, Mar 13, 2015 at 10:01 PM, Philip Sturgeon wrote:
> Pavel,
>
> On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil wrote:
>> On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara wrote:
>>>
>>> But for today, I firmly believe that the Dual-Mode proposal is the
>
On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara 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 usages of PHP into a
On Wednesday, March 11, 2015, Bob Weinand wrote:
>> Am 11.03.2015 um 23:29 schrieb Pavel Kouřil :
>>
>>>> It shouldn't prevent any future improvements and still give use all the
>>> advantages of scalar types.
>>>
>>> Besides wha
>> 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.
On Fri, Feb 20, 2015 at 8:01 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez wrote:
>
>> I think that naming the new parent exception something like "Throwable" or
>> "Catchable" (as Nikita previously suggested) would be a bit more concise in
>> meaning than
On Wed, Feb 25, 2015 at 10:09 AM, Zeev Suraski 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 Hin
On Tue, Feb 24, 2015 at 8:48 AM, Alexander Lisachenko
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 empty), so I decid
On Tue, Feb 24, 2015 at 12:03 AM, Yasuo Ohgaki wrote:
> Hi Nikita,
>
> On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov wrote:
>
>> Voting on the engine exceptions RFC, which proposes to convert existing
>> fatal and recoverable fatal errors into exceptions, has opened:
>>
>> https://wiki.php.ne
On Mon, Feb 23, 2015 at 10:28 AM, Joe Watkins 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 having strict type
On Sun, Feb 22, 2015 at 9:42 PM, Robert Stoll 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
> explicit
On Sun, Feb 22, 2015 at 7:30 PM, Robert Stoll 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 applied implicitl
On Sun, Feb 22, 2015 at 2:09 PM, Robert Stoll 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 which r
On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski 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 – and wha
On Wed, Feb 18, 2015 at 9:45 PM, Benjamin Eberlei wrote:
>
>
> On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil 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,
>>
On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre 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 solved
On Wed, Feb 18, 2015 at 7:28 PM, 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:
>
>
> class Foo {
> }
>
> Now I do feel we need to elaborate some sort of named parameters. D
On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre 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 solved
On Mon, Feb 16, 2015 at 5:42 PM, François Laupretre 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 language (mostly
On Mon, Feb 16, 2015 at 1:33 PM, Benjamin Eberlei wrote:
>
>
> On Mon, Feb 16, 2015 at 1:17 PM, Pavel Kouřil wrote:
>>
>> On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov wrote:
>> > hi,
>> >
>> > During discussion of different ways of implementi
On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov 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 propos
od overloading problem
with either weak or strict typing. Could you expand that thought,
please?
Regards
Pavel Kouřil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Feb 12, 2015 at 3:31 PM, Andrea Faulds wrote:
> Hi Pavel,
>
>> On 12 Feb 2015, at 13:48, Pavel Kouřil 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 -
On Thu, Feb 12, 2015 at 1:45 PM, Andrea Faulds 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 creating a
On Thu, Feb 12, 2015 at 12:44 PM, Andrea Faulds 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
> weakl
On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds 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 long run
On Wed, Feb 11, 2015 at 7:36 AM, Rasmus Lerdorf 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 the lac
On Tue, Feb 10, 2015 at 1:30 PM, Alexander Lisachenko
wrote:
> 2015-02-10 15:20 GMT+03:00 Dmitry Stogov :
>
>> 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 unavailable features that has t
On Tue, Feb 10, 2015 at 1:52 AM, Yasuo Ohgaki 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.
>
> Thank y
On Mon, Feb 9, 2015 at 9:22 AM, Pierre Joye 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 already, your
On Mon, Feb 9, 2015 at 9:04 AM, Dmitry Stogov 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
> introduces slo
>
> 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 readin
On Sat, Feb 7, 2015 at 11:11 PM, Andrea Faulds wrote:
> Hi,
>
>> On 7 Feb 2015, at 22:03, Pavel Kouřil 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 param
On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds wrote:
> Hi,
>
>> On 7 Feb 2015, at 20:47, Andrea Faulds wrote:
>>
>>> On 7 Feb 2015, at 10:57, Pavel Kouřil wrote:
>>>
>>> I just realized it now (I brought it up in a different manner when
>>
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds 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 manner when
On Thu, Feb 5, 2015 at 9:59 AM, Stanislav Malyshev 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 addressing the idea
On Mon, Feb 2, 2015 at 11:50 PM, Stanislav Malyshev 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.
> See: https
On Wed, Feb 4, 2015 at 6:17 PM, Andrea Faulds wrote:
> Hey,
>
>> On 4 Feb 2015, at 17:10, Crypto Compress
>> 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 community convention of v
On Wed, Feb 4, 2015 at 2:00 PM, Michael Wallner 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 representing
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, righ
On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye 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:
>
> https://github.com/php/php-src/blob/master/C
On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner 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 6th.
>
On Sun, Jan 25, 2015 at 5:05 PM, Andrea Faulds 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
> * Float
On Sun, Jan 25, 2015 at 5:02 AM, Andrea Faulds 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 type -
On Fri, Jan 23, 2015 at 10:18 PM, Jan Ehrhardt 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
> and load:
>
On Thu, Jan 15, 2015 at 4:35 PM, Jordi Boggiano 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 to have no hi
On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano 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* get
> exceptio
On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano 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 think it was a sm
On Thu, Jan 15, 2015 at 9:29 AM, Lester Caine 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
> separate handling
> On Wed, Jan 14, 2015 at 11:28 PM, Andrea Faulds 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
> woul
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 dire
96 matches
Mail list logo
