Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
On 11 Sep 2016 10:04 am, "Lester Caine" wrote: > > On 10/09/16 19:47, Stanislav Malyshev wrote: > > In fact, Windows does have command-line interface, moreover - Microsoft > > recently invested significant resources into making this interface more > > powerful and flexible. Moreover, many of the professional programmers > > routinely use command-line tools on Windows. It is true that average > > Windows user does not spend much time in command-line, but we need also > > to remember that PHP developer is not exactly an average Windows user. > > Having been working off a Linux command line for many years, I'm > naturally typing 'ls -la' for 'dir' where initially it was the other way > around. Having just been playing with the new tools on Windows 10 I was > somewhat surprised when having hit return on 'ls -la' and thought bugger > ... it listed the directory ... I'd heard rummers that Microsoft was > making a Unix style option, but had not realised it was already active > in W10. Except it isn't. It was the ARM tool stack that I had installed > last year that and when I disabled that to get PHP to compile it was > lost. Microsoft does not need to put resources in as other users have > often already done the work. > > That said, it's not PHP developers who need the help here It's the end > user of a developers work who needs an easy way to install it. The vast > majority of users still stuck on PHP5.2/3 would probably not even know > what PHP code they are running, even if they knew what a command line was. > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Hi Lester, The Unix option in Windows 10 that you may be thinking of is part of the new anniversary update. It's in beta and you have to enable it in the windows settings. It actually runs a Ubuntu VM (from memory).
Re: [PHP-DEV] header() removes all header of the same name.
FWIW Yasuo, I also think this is a bad idea. If you remove the ability to set cookie _headers_ with the header function then the function needs a more appropriate name - perhaps headerExceptCookie. That makes 5 people opposed - 100% of the individuals who have responded in this thread. On Fri, Oct 21, 2016 at 10:41 AM, Yasuo Ohgaki wrote: > Hi Stats, > > On Fri, Oct 21, 2016 at 5:54 AM, Stanislav Malyshev > wrote: > > > >> The idea is to separate HTTP header handling functions. > >> > >> - header*() for any HTTP headers except 'Set-Cookie' > >> - cookie*() for only 'Set-Cookie' header > > > > This does not look like a good design. First of all, HTTP spec allows > > multiple instances of any header. Second, making function with unobvious > > gotcha branch is usually bad design. Third, we are solving non-existing > > problem here - people should just use existing functions correctly and > > everything would be fine. > > Let's not spend any more time on this. > > OK. 4 people not in favor of Set-Cookie restriction for header*(). > > What about API clean up? > Since we have setcookie()/setrawcookie() already, we may clean up > current cookie API > > e.g. > - cookie_set/setcookie($name, [$value, [array $options]]) > (Keep current signature also) > - cookie_set_raw/setrawcookie($name, [$value, [array $options]]) > (Keep current signature also) > - cookie_remove($name), cookie_list() > (These may be optional to you) > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Type locked variables
I think it would make more sense for typed properties to exist first, and it so happens that there was a recent RFC for this: https://wiki.php.net/rfc/typed-properties. That RFC failed by a very small margin. I would suggest you read through the discussions on the mailing list regarding that RFC for some common arguments to typing in PHP. On Wed, Nov 16, 2016 at 12:44 PM, Michael Morris wrote: > Perhaps it's time to revisit the idea of allowing variables to have their > types locked down. The keywords needed are already reserved. So... > > string $a = "hello"; > int $b = 5; > > Once declared this way the variable's type won't change unless it gets > unset. In normal mode PHP will coerce any assignment to the variable to the > desired type. If declare strict types is on then assigning the wrong type > to a variable would raise a type error. > > Note this would simplify one of the use cases of setters - insuring the > class member is of a valid type. > > The idea of function overloading reminded me of this. I'd consider being > able to do this sort of type lockdown to be prerequisite to having > overloaded functions. > > Since this approach is entirely opt in I don't think it would make the > language harder to learn. >
Re: [PHP-DEV] [RFC][VOTE] Trailing commas in all list syntax
On Mon, Jan 30, 2017 at 4:17 PM, Yasuo Ohgaki wrote: > > > I would have voted yes, but I missed the vote. > Unless there is critical reason not to implement it that I don't know of, I > prefer to allow > trailing commas like array universally/consistently. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net Not that I can vote but AFAICS the vote is still open as per Sammys mail: https://wiki.php.net/rfc/list-syntax-trailing-commas
Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
On Tue, Jan 31, 2017 at 7:42 AM, Niklas Keller wrote:
> Levi Morrison schrieb am Mo., 30. Jan. 2017, 18:55:
>
> > Bob Weinand and I are happy to announce that the [Arrow Functions][1]
> > RFC is moving into the public discussion phase. We have been
> > collaborating on this RFC for many months now and finally have a
> > proposal we are happy to discuss in the open.
> >
> > Here is an example of an existing closure:
> >
> > function ($x) use ($arr) {
> > return $arr[$x];
> > }
> >
> > This RFC proposes syntax and semantics to simplify this common usage to:
> >
> > fn($x) => $arr[$x]
> >
> > More details are in the RFC. The [implementation][2] currently has no
> > known issues and is ready for you to download, build and test, which
> > we encourage you to do.
> >
>
> https://3v4l.org has a feature branch for arrow functions, you can find
> it
> in the preview select box for playing around and in the RFC tab after a
> full execution.
>
> We look forward to a productive discussion period and are happy to
> > answer questions.
> >
> > For historical purposes, the revision of this RFC is currently at
> > [1485798604][3].
> >
> > [1]: https://wiki.php.net/rfc/arrow_functions
> > [2]: https://github.com/morrisonlevi/php-src/tree/arrow_functions
> > [3]: https://wiki.php.net/rfc/arrow_functions?rev=1485798604
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
Looking good. Really excited for something like this in PHP.
Just a heads up, the section in the introduction that refers to other
languages having similar syntax still has a TODO in it. I agree that some
references to other languages' implementations (ES6 comes to mind) would be
a nice addition.
Awesome work,
Guy
