On Wed, Nov 5, 2014 at 10:49 PM, Ferenc Kovacs wrote:
> 2014.11.06. 2:46 ezt írta ("Andrea Faulds" ):
> >
> >
> > > On 5 Nov 2014, at 20:34, Ferenc Kovacs wrote:
> > >
> > > Regardless of those, I think it would be worse from the users POV than
> our
> > > current policy where we target no BC br
> The HTTP specification doesn't restrict how the request body is encoded
> based on the request verb.
I never said it did... please don't put words in my mouth.
As Will notes, you're sidestepping the point, which standards-savvy
people have been driving at for years: the semantic differences (==
On 06/11/14 02:27, Andrea Faulds wrote:
>> We have minor BC breaks (new errors. Slight behavior changes due to bug
>> fixes).
>> >
>> > But globally no, it makes end users work harder for migration, even worst
>> > for distros.
>> >
>> > See Debian f.e., they boost the adoption speed now, we fi
It's clear, that covariant types are more smart, but not supporting them,
won't prevent access to more specific type properties and methods.
We are not C++ or Java, and we don't need to cast objects to more specific
types.
On the other hand covariance requires all return types to be defined before
Oh, and thanks to @SaraMG for pointing me to the write direction on writing
an e-mail to the internals :)
Daniel Ribeiro
http://danielribeiro.org
On Thu, Nov 6, 2014 at 11:41 AM, Daniel Ribeiro wrote:
> Good morning, internals!
>
> I would like to present to you an idea that I have for a synta
Good morning, internals!
I would like to present to you an idea that I have for a syntax improvement
for PHP.
The basic idea is to allow arbitrary expressions when using the instanceof
operator. Currently, the second operand can only be a constant reference or
a string:
$foo instanceof stdClass;
Hi Ferenc,
On Thu, Nov 6, 2014 at 3:28 PM, Ferenc Kovacs wrote:
> Ps: and dont forget/ignore that originally only the read only/lazy write
> parts were accepted, the other two proposals did not.
I think the branch has only read only and lazy write parts. I'll double
check.
The branch seems to
2014.11.06. 2:46 ezt írta ("Andrea Faulds" ):
>
>
> > On 5 Nov 2014, at 20:34, Ferenc Kovacs wrote:
> >
> > Regardless of those, I think it would be worse from the users POV than
our
> > current policy where we target no BC breaks in minor/micro versions.
> > The only exception should be security
2014.11.06. 6:02 ezt írta ("Yasuo Ohgaki" ):
>
> Hi Damian,
>
> On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley wrote:
>
> > https://bugs.php.net/bug.php?id=68331
> >
>
> I've reverted incomplete patch for the RFC.
Thanks!
>
> Since the RFC patch
> https://github.com/yohgaki/php-src/compare/PHP-5
2014.11.06. 7:10 ezt írta ("Yasuo Ohgaki" ):
>
> Hi all,
>
> The RFC https://wiki.php.net/rfc/session-lock-ini was accepted and the
> patch for this was ready to merge, but it wasn't merged to 5.6 by mistake.
>
> The patch is this.
> https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-session-lo
Hi Andrey,
Sorry but I think you're wrong. Domain != hostname. Underscore are allowed
in domains (RFC 2181) but not in hostnames (RFC 1123 and next). To quote
Wikipedia:
"While a hostname may not contain other characters, such as the underscore
character (_), other DNS names may contain the under
Hi all,
The RFC https://wiki.php.net/rfc/session-lock-ini was accepted and the
patch for this was ready to merge, but it wasn't merged to 5.6 by mistake.
The patch is this.
https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-session-lock
(It's been a while and it has to be updated for current
Hi Damian,
On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley wrote:
> https://bugs.php.net/bug.php?id=68331
>
I've reverted incomplete patch for the RFC.
Since the RFC patch
https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-session-lock
was not merged yet, it has to be removed for now.
We h
On Wed, Nov 5, 2014 at 10:53 PM, Will Fitch wrote:
>
> > On Nov 5, 2014, at 10:00 PM, Sherif Ramadan
> wrote:
> >
> >
> >
> > On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote:
> >
> >
> >
> > Easy - you have no idea what the input type is from PUT without checking
> the incoming type. With POS
> On Nov 5, 2014, at 10:00 PM, Sherif Ramadan wrote:
>
>
>
> On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote:
>
>
>
> Easy - you have no idea what the input type is from PUT without checking the
> incoming type. With POST, you know exactly what it is. PUT input code be
> JSON, multipar
On Wed, Nov 5, 2014 at 10:03 PM, Sanford Whiteman
wrote:
> For the umpteenth time, *in what situation must you PUT
> multipart/form-data or multipart/x-www-form-urlencoded only to treat it,
> semantically, as a POST*? Which UA cannot send a POST? It's like we're
> completely upside down on this t
For the umpteenth time, *in what situation must you PUT multipart/form-data or
multipart/x-www-form-urlencoded only to treat it, semantically, as a POST*?
Which UA cannot send a POST? It's like we're completely upside down on this
thread.
If you're PUTing such POSTful content-types for any reas
On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote:
>
>
>
> Easy - you have no idea what the input type is from PUT without checking
> the incoming type. With POST, you know exactly what it is. PUT input code
> be JSON, multipart mime, a file or a whatever the dev wants.
>
That's not necessarily
After the comments I see about deprecating the constant. Makes completely
sense to keep it. Thanks for the clarification.
I like the idea to have it enabled by default on 7.0, but since it is not a
major issue, probably keeping it as optional would makes more sense and
doesn't introduce another un
> On Nov 5, 2014, at 9:23 PM, Sherif Ramadan wrote:
>
> On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds wrote:
>
>>
>>> On 6 Nov 2014, at 01:29, Sherif Ramadan wrote:
>>>
>>> So you're actually describing two semi-different problems here. One is
>> that PHP doesn't actually inform you of the
> On 6 Nov 2014, at 02:00, Pierre Joye wrote:
>
> We have minor BC breaks (new errors. Slight behavior changes due to bug
> fixes).
>
> But globally no, it makes end users work harder for migration, even worst for
> distros.
>
> See Debian f.e., they boost the adoption speed now, we finally
On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds wrote:
>
> > On 6 Nov 2014, at 01:29, Sherif Ramadan wrote:
> >
> > So you're actually describing two semi-different problems here. One is
> that PHP doesn't actually inform you of the HTTP request VERB strictly
> through the naming of the super glob
HI all,
On Thu, Nov 6, 2014 at 6:30 AM, Yasuo Ohgaki wrote:
> On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley wrote:
>
>> Apparently this caused
>> problems for some people as they made 68331 a few days ago.
>>
>
> Just a quick note for this. The user would like to access session
> data(session
To demonstrate the value of covariance and why `static` alone is not
sufficient, here is a small example:
interface Enumerable extends \IteratorAggregate {
function getIterator(): Enumerator;
}
class Vector implements Enumerable, \ArrayAccess, \Countable {
function getIterator(): VectorEn
On Nov 6, 2014 11:46 AM, "Andrea Faulds" wrote:
>
>
> > On 5 Nov 2014, at 20:34, Ferenc Kovacs wrote:
> >
> > Regardless of those, I think it would be worse from the users POV than
our
> > current policy where we target no BC breaks in minor/micro versions.
> > The only exception should be securi
> On 5 Nov 2014, at 20:34, Ferenc Kovacs wrote:
>
> Regardless of those, I think it would be worse from the users POV than our
> current policy where we target no BC breaks in minor/micro versions.
> The only exception should be security concerns (see the unserialize changes
> in 5.6 for such an
Hi Andrey,
On Thu, Nov 6, 2014 at 8:23 AM, Andrey Andreev wrote:
> Short-term fix for 5.6 is obviously to revert the commit. I was vocal
> mostly because of principle at the time, but this issue is an example
> why.
>
Did you? I don't think so.
The reason that I didn't provide that user land "
Hi,
On Thu, Nov 6, 2014 at 3:20 AM, Florian Margaine wrote:
> Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good
> idea?
Have you missed:
https://wiki.php.net/rfc/releaseprocess
?
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Dev
> On 6 Nov 2014, at 01:29, Sherif Ramadan wrote:
>
> So you're actually describing two semi-different problems here. One is that
> PHP doesn't actually inform you of the HTTP request VERB strictly through the
> naming of the super global variables $_POST and $_GET. However, $_POST being
> pop
On Wed, Nov 5, 2014 at 7:31 PM, Andrea Faulds wrote:
>
> > On 5 Nov 2014, at 22:29, Sherif Ramadan wrote:
> >
> > From all the people I've spoken with that have a problem with handling
> PUT
> > requests in PHP, it seems that they'd rather have PHP populate
> > $_FILES/$_POST automatically in th
> On 6 Nov 2014, at 00:26, Andrea Faulds wrote:
>
>> Also, it is kind of weird that arguments require exact match but return
>> types do not. Not that we care for consistency anymore…
>
> Yeah, we should probably have arguments be contravariant or covariant.
>
> I was going to argue that covar
> On 5 Nov 2014, at 22:29, Sherif Ramadan wrote:
>
> From all the people I've spoken with that have a problem with handling PUT
> requests in PHP, it seems that they'd rather have PHP populate
> $_FILES/$_POST automatically in this case. Which would be relatively easy
> to do by modifying the de
> On 5 Nov 2014, at 22:15, Stas Malyshev wrote:
>
> Hi!
>
>>No, classes are not loaded for type checks, since it would be pointless
>>- if the class is not loaded, you could not have a value of that type,
>>so if the class is not present, the answer is "no".
>>
>>
>> It's not true
Hi,
On Wed, Nov 5, 2014 at 11:57 PM, Kévin Dunglas wrote:
>
> - Added a new FILTER_VALIDATE_DOMAIN filter validating domain names
> - Added a FILTER_FLAG_HOSTNAME flag to allow checking hostnames (_ are
> forbidden in hostname but not in domains)
This doesn't make any sense. A domain *is* a host
Hi,
On Wed, Nov 5, 2014 at 11:30 PM, Yasuo Ohgaki wrote:
>
> BTW, anyone know the reason why the user need to call
> session_write_close()/session_commit()
> unconditionally? Accounting, perhaps?
Releasing locks is one example. In userland implementations though, it
could be all kinds of applica
Hi all,
On Wed, Nov 5, 2014 at 9:52 PM, Ferenc Kovacs wrote:
>
> Hi,
>
> thanks for the report.
> first let me clarify a couple of things:
>
> 1, neither of https://wiki.php.net/rfc/session-lock-ini or
> https://wiki.php.net/rfc/session-read_only-lazy_write made into 5.6 in their
> proposed forms
2014-11-04 20:48 GMT+01:00 Dmitry Stogov :
> I agree with Nikita.
> Adding an extra argument for one particular security related case looks
> weird.
Same opinion here.
Unfortunately, I can't propose something more robust instead, but I
have the feeling that this RFC tries to solve the symptoms of
Me as a user and developer PHP RESTful, enough auto filling the global
variable.
Make an abstract variable names (_BODY or _FORM), and filled with the value
in all the HTTP methods.
Perhaps it makes sense to do lazy loading of data in these variables, it is
simply done through an ArrayAccess inter
I'm not keen on the idea of adding more superglobals to PHP, although I
certainly understand the grave concern of breaking people's code and as
such I've chosen not to pursue the idea of removing superglobals.
I will, however, revisit the idea of exposing the underlying SAPI
callbacks, for handlin
I would also prefer to use the same return type hinting compatibility rules
as for argument type-hinting.
May be it's less smart, but more practical.
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
Thanks. Dmitry.
On Thu, Nov 6, 2014 at 1:15 AM, Stas Malyshev
w
Hi!
> No, classes are not loaded for type checks, since it would be pointless
> - if the class is not loaded, you could not have a value of that type,
> so if the class is not present, the answer is "no".
>
>
> It's not true anymore, with this proposal.
This is not good. The base pr
> On 5 Nov 2014, at 21:43, Dmitry Stogov wrote:
>
> On Thu, Nov 6, 2014 at 12:05 AM, Stas Malyshev
> wrote:
>
>> Hi!
>>
>>
>>> Do we always load the class in the hint? We could perhaps only do it
>>> for inheritance checks?
>>
>> No, classes are not loaded for type checks, since it would be
Hi,
According to the discussion on GitHub, I've made some changes on this PR:
- Added a new FILTER_VALIDATE_DOMAIN filter validating domain names
- Added a FILTER_FLAG_HOSTNAME flag to allow checking hostnames (_ are
forbidden in hostname but not in domains)
- Changed FILTER_VALIDATE_URL to use th
On Thu, Nov 6, 2014 at 12:05 AM, Stas Malyshev
wrote:
> Hi!
>
>
> > Do we always load the class in the hint? We could perhaps only do it
> > for inheritance checks?
>
> No, classes are not loaded for type checks, since it would be pointless
> - if the class is not loaded, you could not have a val
Hi all,
On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley wrote:
> Apparently this caused
> problems for some people as they made 68331 a few days ago.
>
Just a quick note for this. The user would like to access session
data(session handler)
regardless of data modification. I suppose it could be s
> On 5 Nov 2014, at 21:05, Stas Malyshev wrote:
>
> Hi!
>
>
>> Do we always load the class in the hint? We could perhaps only do it
>> for inheritance checks?
>
> No, classes are not loaded for type checks, since it would be pointless
> - if the class is not loaded, you could not have a value
Hi!
> Do we always load the class in the hint? We could perhaps only do it
> for inheritance checks?
No, classes are not loaded for type checks, since it would be pointless
- if the class is not loaded, you could not have a value of that type,
so if the class is not present, the answer is "no".
2014.11.05. 21:21 ezt írta ("Florian Margaine" ):
>
> Hi list,
>
> I'd like to introduce thresholds of backwards compatibility breaks, i.e.
> maximum numbers of allowed BC breaks per version.
>
> Lester's mail from a couple days ago had me thinking about the BC breaks
> that occur now and then in a
Hi list,
I'd like to introduce thresholds of backwards compatibility breaks, i.e.
maximum numbers of allowed BC breaks per version.
Lester's mail from a couple days ago had me thinking about the BC breaks
that occur now and then in all the RFCs or all the mails I see these days.
Now, take what I
On Wed, Nov 5, 2014 at 6:49 PM, Mark Caudill
wrote:
> > https://bugs.php.net/bug.php?id=68331
> >
> > I was hoping the submitter (or one of their coworkers who commented on
> > it) would reach out to the list themselves to get more information
> > since I don't know the whole situation. I did ask
On Wed, Nov 5, 2014 at 6:24 PM, Andrea Faulds wrote:
>
> > On 5 Nov 2014, at 17:01, Ferenc Kovacs wrote:
> >
> > 2, there is a chance that there are some exotic apps/systems which are
> > already depending on the fact that php will/was used to send out 1
> instead
> > of 1.0, and while we can br
> https://bugs.php.net/bug.php?id=68331
>
> I was hoping the submitter (or one of their coworkers who commented on
> it) would reach out to the list themselves to get more information
> since I don't know the whole situation. I did ask them to...
Sorry, I had an email written up to send out to the
> On 5 Nov 2014, at 12:51, Lester Caine wrote:
>
> On 05/11/14 11:29, Andrea Faulds wrote:
>
Perhaps something does already exist that I'm missing?
>>>
>>> https://github.com/asmblah/uniter
>>
>> There's also http://phpjs.hertzen.com and
>> https://code.google.com/p/php-to-js/ and some
On 5 November 2014 17:21, Jakub Zelenka wrote:
>
>
> On Wed, Nov 5, 2014 at 4:52 PM, Chris Wright wrote:
>
>>
>> I'm sorry, but I don't understand why it would need to be deprecated. For
>> me "making it the default behaviour" would mean "changing the default value
>> of the $flags argument to J
> On 5 Nov 2014, at 17:01, Ferenc Kovacs wrote:
>
> 2, there is a chance that there are some exotic apps/systems which are
> already depending on the fact that php will/was used to send out 1 instead
> of 1.0, and while we can break BC in a major release, the migration for
> those people would b
On Wed, Nov 5, 2014 at 4:52 PM, Chris Wright wrote:
>
> I'm sorry, but I don't understand why it would need to be deprecated. For
> me "making it the default behaviour" would mean "changing the default value
> of the $flags argument to JSON_PRESERVE_FACTIONAL_PART". The flag would
> still functio
On 5 November 2014 11:43, Chris Wright wrote:
> On 5 November 2014 11:22, Leigh wrote:
>
>> On 4 November 2014 18:14, Rowan Collins wrote:
>> >
>> > If anything, I think I would expect the keys of splatted arrays to be
>> discarded, since it seems most natural to use this in a list context, but
On Wed, Nov 5, 2014 at 5:34 PM, Jakub Zelenka wrote:
>
>
> On Wed, Nov 5, 2014 at 4:23 PM, Juan Basso wrote:
>
>>
>> I also prefer to use different flags if we enable by default. So if this
>> behavior is enabled by default in 7.0 the JSON_PRESERVE_FRACTIONAL_PART
>> is deprecated and a new fla
On 5 November 2014 16:45, Jakub Zelenka wrote:
>
> On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright wrote
>>
>>
>> I'm afraid I have to disagree here, I don't like the idea of changing
>> this behaviour without making it controllable
>>
>
> If we make it default, then we could of course add a new co
On 11/5/14, 9:15 AM, Alexander Lisachenko wrote:
2014-11-05 17:02 GMT+03:00 Marco Pivetta :
For example, this alternative approach perfectly fits the current
doctrine/annotations use-case:
use Doctrine\ORM\Mapping\Entity;
use Doctrine\ORM\Mapping\Table;
use Doctrine\ORM\Mapping\Id;
use Doctrin
> On 5 Nov 2014, at 16:45, Jakub Zelenka wrote:
>
> On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright wrote
>>
>>
>> I'm afraid I have to disagree here, I don't like the idea of changing this
>> behaviour without making it controllable
>>
>
> If we make it default, then we could of course add a
On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright wrote
>
>
> I'm afraid I have to disagree here, I don't like the idea of changing this
> behaviour without making it controllable
>
If we make it default, then we could of course add a new constants that
would allow the old behaviour.
What I'm trying
On Wed, Nov 5, 2014 at 4:23 PM, Juan Basso wrote:
>
> I also prefer to use different flags if we enable by default. So if this
> behavior is enabled by default in 7.0 the JSON_PRESERVE_FRACTIONAL_PART
> is deprecated and a new flag is created to disable it.
>
> In resume of this thread, seems ev
> On 5 Nov 2014, at 16:23, Juan Basso wrote:
>
> Andrea, I see your concerns about the bigint changes, but I am not sure if
> they are related. The PR just affect the encoding, not the decoding part.
Yes, I realise that.
> So if some Python system encodes a JSON using the decimal part it will
On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright wrote:
>
> I'm afraid I have to disagree here, I don't like the idea of changing this
> behaviour without making it controllable, and your logic is also slightly
> flawed - it's not that you'd have to do an & ~ to disable, it's that it
> wouldn't be en
I also prefer to use different flags if we enable by default. So if this
behavior is enabled by default in 7.0 the JSON_PRESERVE_FRACTIONAL_PART is
deprecated and a new flag is created to disable it.
In resume of this thread, seems everyone if fine in having the flag
JSON_PRESERVE_FRACTIONAL_PART
On 11/4/14, 3:31 PM, Stas Malyshev wrote:
Hi!
Primarily, I do not see docblocks as the right place to store class'
metadata information. Metadata != Comments.
I personally regard this as a kind of superstition. There's nothing
wrong with extending what can be in comments. In fact, Javascript
I think keeping this just like an array definition in a property would make
this both simple and flexible.
You can even improve on Marcos example with a class having constants:
namespace Doctrine\ORM\Mapping\Annotations;
class ORM
{
const ENTITY = 'Doctrine\ORM\Mapping\Annotations\Entity';
2014-11-05 17:02 GMT+03:00 Marco Pivetta :
> For example, this alternative approach perfectly fits the current
> doctrine/annotations use-case:
>
> use Doctrine\ORM\Mapping\Entity;
> use Doctrine\ORM\Mapping\Table;
> use Doctrine\ORM\Mapping\Id;
> use Doctrine\ORM\Mapping\GeneratedValue;
> use Doc
On 4 November 2014 17:07, Jakub Zelenka wrote:
> On Tue, Nov 4, 2014 at 2:57 PM, Ferenc Kovacs wrote:
>
> > On Tue, Nov 4, 2014 at 4:13 AM, Juan Basso wrote:
> >
> > > Hi,
> > >
> > > I opened a pull request[1] in order to solve the bug 50224[2] and it
> > ended
> > > creating this pull request
> On 5 Nov 2014, at 14:02, Marco Pivetta wrote:
>
> I'm not sure if we need that sort of syntax and opinionated approach: I like
> Benjamin's approach better, and it is also simpler and still very easy to use
> even in our context (doctrine).
>
> For example, this alternative approach perfect
Hi Guilherme,
On 4 November 2014 23:47, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Sorry, I forgot to add references to how we fixed emails handling. It got
> split in 2 places:
>
> - Initial root level annotation
>
> https://github.com/doctrine/annotations/blob/master/lib/Do
On 05/11/14 11:29, Andrea Faulds wrote:
>
>> On 5 Nov 2014, at 11:14, Leigh wrote:
>>
>>> On 5 November 2014 10:57, Lester Caine wrote:
>>> Before you fall of your chairs let me expand on that ...
>>>
>>> Many of the sites I'm supporting are being chased by the we want your
>>> work mob, and bei
> On 5 Nov 2014, at 11:53, Dmitry Stogov wrote:
>
> Hi Levi,
>
> The patch is here https://gist.github.com/dstogov/8deb8b17e41c1a5abf88
>
> I improved memory consumption and unified return type-hinting error
> behavior with existing argument type-hinting.
> The main semantic must be unchanged.
Hi Levi,
The patch is here https://gist.github.com/dstogov/8deb8b17e41c1a5abf88
I improved memory consumption and unified return type-hinting error
behavior with existing argument type-hinting.
The main semantic must be unchanged.
I also removed part of Reflection changes. I think we should remov
On 5 November 2014 11:22, Leigh wrote:
> On 4 November 2014 18:14, Rowan Collins wrote:
> >
> > If anything, I think I would expect the keys of splatted arrays to be
> discarded, since it seems most natural to use this in a list context, but I
> can imagine always having to check in the manual.
> On 5 Nov 2014, at 11:14, Leigh wrote:
>
>> On 5 November 2014 10:57, Lester Caine wrote:
>> Before you fall of your chairs let me expand on that ...
>>
>> Many of the sites I'm supporting are being chased by the we want your
>> work mob, and being told they "Must have apps to stay in busines
On 4 November 2014 18:14, Rowan Collins wrote:
>
> If anything, I think I would expect the keys of splatted arrays to be
> discarded, since it seems most natural to use this in a list context, but I
> can imagine always having to check in the manual.
I agree on this point. Duplicate keys should
On 5 November 2014 10:57, Lester Caine wrote:
> Before you fall of your chairs let me expand on that ...
>
> Many of the sites I'm supporting are being chased by the we want your
> work mob, and being told they "Must have apps to stay in business". Of
> cause that means both an android and an appl
Hi,
On Wed, Nov 5, 2014 at 11:57 AM, Lester Caine wrote:
> Before you fall of your chairs let me expand on that ...
>
> Many of the sites I'm supporting are being chased by the we want your
> work mob, and being told they "Must have apps to stay in business". Of
> cause that means both an androi
Before you fall of your chairs let me expand on that ...
Many of the sites I'm supporting are being chased by the we want your
work mob, and being told they "Must have apps to stay in business". Of
cause that means both an android and an apple one with a discount on the
pair. BUT in most cases a r
Hi Dmitry
On 4 November 2014 20:13, Dmitry Stogov wrote:
> I like the idea, especially list($a, $b, ...$c) = ...
> Looks like Prolog's [A, B | C] = ..., unfortunately it won't provide the
> same semantic and performance.
> Implementation needs to be reviewed, but I think it must not affect
> exi
On 4 November 2014 18:14, Rowan Collins wrote:
> On 3 November 2014 22:45:11 GMT, Chris Wright wrote:
> >Good evening list,
> >
> >I'd like to open discussion a relatively simple and clear-cut RFC,
> >either
> >people will like it or they won't, there isn't a lot more to say here
> >than
> >what
On Wed, Nov 5, 2014 at 9:35 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Andrea Faulds [mailto:a...@ajf.me]
>> Sent: Wednesday, November 05, 2014 1:59 AM
>> To: PHP internals
>> Subject: [PHP-DEV] RFC Process: Should we hold two different votes?
>>
>>Why not hold two
>> different
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Wednesday, November 05, 2014 1:59 AM
> To: PHP internals
> Subject: [PHP-DEV] RFC Process: Should we hold two different votes?
>
>Why not hold two
> different votes on an RFC, similar to how legislation is passed in the
Le 05/11/2014 00:58, Andrea Faulds a écrit :
Good evening,
A lot of RFCs have been rejected because, while they proposed a feature people
would like, the details were problematic. This has lead to these features
sometimes being considerably delayed.
So, in order to do something about this,
86 matches
Mail list logo
