I do not know their plan. but in china, we will happy in our holiday
till 2015.03.05 (The last important holiday The Lantern Festival )
then we will back to work.
This is traditional chinese holidays.
Learn mandarin should be fun, welcome you guys come to china . It's
now our very important holi
Hi Netroby,
> On 15 Feb 2015, at 04:00, Netroby wrote:
>
> The time range is Chinese lunar new year.
Oh! My bad, I was unaware of that. (I really should’ve noticed that, given I am
learning Mandarin.)
When do festivities etc. end? What would be a good time to extend it to?
Thanks!
--
Andrea
The time range is Chinese lunar new year. I am not sure @laruence and
@reeze be on holidays or not.
The vote time range can be extended ?
I have no the ability to vote. but i guess this RFC is very well for
PHP programmers.
Appreciate your time.
Netroby
--
PHP In
Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this
RFC. The implementation isn’t finished, but the remaining work isn’t impossible
to surmount (though help would certainly be appreciated). RFCs can be put to
vote without implementations (or so says https://
Hi, Ralph
2015-02-14 12:43 GMT-03:00 Ralph Schindler :
>
> 1. We aimed for maximum readability. The block syntax delimited with
>> bracket `{` ... `}` pairs is definitely easier to keep track in
>> comparison with a colon and semicolon `:`...`;`
>>
>> 2. A block delimited by a double colon and a
On Sun, Feb 15, 2015 at 8:17 AM, Yasuo Ohgaki wrote:
> I wrote simple D program "sample.d" to play with. Install D, then
>
> dmd sample.d && ./sample
>
> sample.d
> import std.stdio;
>
> class A {
> int x = 1;
> int y = 2;
>
> public:
> void set (int x, int y)
> in {
> assert(x > 0);
> a
Hi all,
On Sun, Feb 15, 2015 at 8:25 AM, Yasuo Ohgaki wrote:
> Both D and Eiffel has way to get around it.
> As I mentioned in previous mails, PHP may be get around with it by default
> because it's the nature of PHP. PHP may be extended to follow type theory
> in the future when strict_types is
Hi Robert,
On Sun, Feb 15, 2015 at 8:14 AM, Robert Stoll wrote:
> I think you misunderstood me, I did not have any questions, I merely
> wanted to explain to François what LSP means, but thanks anyway :)
I understood. You are correct.
Both D and Eiffel has way to get around it.
As I mentioned
Hi all,
On Sun, Feb 15, 2015 at 7:53 AM, Yasuo Ohgaki wrote:
> On Sat, Feb 14, 2015 at 8:06 PM, Robert Stoll wrote:
>
>> The theory is actually quite simple. Roughly it says that if you use a
>> type hint of a certain class then you can rely on all pre/post-conditions
>> of this class even if a
Hi Yasuo
> -Ursprüngliche Nachricht-
> Von: yohg...@gmail.com [mailto:yohg...@gmail.com] Im Auftrag von Yasuo Ohgaki
> Gesendet: Samstag, 14. Februar 2015 23:54
> An: Robert Stoll
> Cc: francois; Dmitry Stogov; Joe Watkins; Stanislav Malyshev; PHP Internals
> Betreff: Re: [PHP-DEV] Design
Hi Robert,
D and PHP differs a lot with respect to types. D is very strongly typed
while PHP is very weakly typed.
Therefore, we need a little different approach.
On Sat, Feb 14, 2015 at 8:06 PM, Robert Stoll wrote:
> The theory is actually quite simple. Roughly it says that if you use a
> type
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Samstag, 14. Februar 2015 22:38
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Void Return Type
>
> Hi Robert,
>
> > On 14 Feb 2015, at 21:23, Robert Stoll wrote:
> >
> > I think a vo
Hi Robert,
> On 14 Feb 2015, at 21:23, Robert Stoll wrote:
>
> I think a void type for PHP would make sense but only if the return value of
> such a function cannot be used.
Why? If the return value cannot be used, it prevents the function being used
with any API that stores the return value
Hi Andrea,
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Samstag, 14. Februar 2015 04:18
> An: PHP Internals
> Betreff: [PHP-DEV] [RFC] Void Return Type
>
> Hi everyone,
>
> I’ve written a small RFC and patch to add a “void” return type:
>
> https://w
On Sat, Feb 14, 2015 at 6:03 AM, Xinchen Hui wrote:
> Hey:
>
>
>
> On Sat, Feb 14, 2015 at 11:18 AM, Andrea Faulds wrote:
> > Hi everyone,
> >
> > I’ve written a small RFC and patch to add a “void” return type:
> >
> > https://wiki.php.net/rfc/void_return_type
> >
> > Please have a read over it.
Hi!
> How ignoring values is a perfectly valid scenario?
You are saying you're using return value for every function you're
calling, always? Please. How many times you used return value of sort()?
Every function with side effects can be used for its side effects, not
for its return value.
> new
Hi!
> One of the primary purposes of having typehints *is* documentation. This
Documentation causing fatal errors is something quite unusual. And wrong.
> applies both to our existing type annotations, to the newly introduced
That is not true, for existing types documentation is not the only an
On 14/02/2015 16:34, Philip Sturgeon wrote:
On Sat, Jan 31, 2015 at 8:27 PM, Andrea Faulds wrote:
I think the more important issue is the conflict with the
ReflectionTypeAnnotation RFC, which proposes something similar to
what was originally part of the Return Types RFC:
https://wiki.php.net/r
Hi
Am 13.02.2015 um 08:48 schrieb Stanislav Malyshev:
Hi!
there should be no bc break as the API doesn't change and the method
produces the exact same result as before.
Sorry, this makes no sense to me. You claim that if you changed the
method code to do different thing it should continue work
Hi Markus,
>
> - cognitively *I* can much easier glance through to "find" something.
> Because my eyes just have to scan up/down on the same character column
>
That's very subjective. Have you seen the use case regardless of patch
diffs on the RFC? Or the other examples given?
> - It's not alph
Le 05/02/2015 21:14, Andrea Faulds a écrit :
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.
I’d like to make sure that everyone voting understands the RFC fully. Please
read the RFC
> 2015-02-13 13:50 GMT-03:00 Nikita Popov :
>> use PhpParser\NodeVisitorAbstract;
>> use PhpParser\Error;
>> use PhpParser\Node;
>> use PhpParser\Node\Name;
>> use PhpParser\Node\Name\FullyQualified;
>> use PhpParser\Node\Stmt\Namespace_;
>> use PhpParser\Node\Stmt\Use_;
>> use PhpParser\Node\Stmt\
2015-02-13 13:50 GMT-03:00 Nikita Popov :
> On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov
> wrote:
>
>> On Wed, Feb 11, 2015 at 9:50 PM, Marcio Almada
>> wrote:
>>
>>> Hi internals!
>>>
>>> Since no new discussion topics appeared, the voting on the Group Use
>>> Declarations RFC for PHP7 is now
1. We aimed for maximum readability. The block syntax delimited with
bracket `{` ... `}` pairs is definitely easier to keep track in
comparison with a colon and semicolon `:`...`;`
2. A block delimited by a double colon and a semicolon `:` `;` is NOT
yet part of any structure from the PHP. Int
On Sat, Jan 31, 2015 at 8:27 PM, Andrea Faulds wrote:
>
>> On 1 Feb 2015, at 01:23, Dan Ackroyd wrote:
>>
>> On 31 January 2015 at 17:31, Philip Sturgeon wrote:
>>> On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati wrote:
2) There's a tiny bit of overlap with "scalar type hints",
>>>
>>
Hi, Lester
>> Can't we restore the simple way of working in PHP7
> >> where it does not need to wrap around other things quite so closely?
> >
> > Hi Lester,
> >
> > This way if doing things on php didn't go anywhere, people just stopped
> > using it because they saw better alternatives.
>
> I cou
All: I'll be continuing work on the RFC tomorrow, it is still in draft.
Yasuo: I'll read through your notes tomorrow, thanks for detailed input.
Cheers
Joe
On Sat, Feb 14, 2015 at 9:17 AM, Yasuo Ohgaki wrote:
> Hi Francois,
>
> Now I understand what you are discussing. Since we may have strict
On Feb 14, 2015 6:28 AM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > What would be the point of *allowing* returning a value? It's clearly
>
> It's an error only because you declared it an error.
>
> > an error. We could let you return anything and then discard it, but
> > now you won't spot the err
On Sat, Feb 14, 2015 at 3:28 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > What would be the point of *allowing* returning a value? It's clearly
>
> It's an error only because you declared it an error.
>
> > an error. We could let you return anything and then discard it, but
> > now you won't spot th
Hi!
> What would be the point of *allowing* returning a value? It's clearly
It's an error only because you declared it an error.
> an error. We could let you return anything and then discard it, but
> now you won't spot the error in your code.
Function return values which are going unused all t
On Sat, Feb 14, 2015 at 12:26:08PM +, Andrea Faulds wrote:
> We could do this, but for the longest time we've made all functions have some
> return value, even ones which don't explicitly return one (they return NULL).
> I think it'd be better not to change this. I expect IDEs and such could
Hi,
> On 14 Feb 2015, at 03:32, reeze wrote:
>
> Do we really have to throw an catchable fatal error?
>
> the other return types make sense, why so strict?
We throw E_RECOVERABLE_ERROR for all type errors, both for parameters and
return types. It's not anything new.
--
Andrea Faulds
http://a
Hi,
> On 14 Feb 2015, at 05:54, Stanislav Malyshev wrote:
>
> Hi!
>
> I'm not sure what it is useful for, exactly. I mean, the more fatal
> errors the merrier, but I fail to see what exactly use except having yet
> more cases when your code may break it provides. I mean, if you defined
> a void
Hi,
> On 14 Feb 2015, at 05:03, Xinchen Hui wrote:
>
> Hey:
> be honest, I think it's only part of the idea is implemented.
>
> which make it useless.
>
> in PHP, even if you don't return anything, NULL is returned implicitly.
>
> even if a function is declared return nothing(void).
>
> like
Hey François,
On 14 Feb 2015, at 04:57, François Laupretre wrote:
> That's a nice addition and a beginning to distinguish void from null, as I
> imagine the function still returns null.
>
> Now, what about making void a real zval type ? It would open a lot of
> possibilities. Unlike null, con
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net]
> Gesendet: Samstag, 14. Februar 2015 07:17
> An: 'Yasuo Ohgaki'
> Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav Malyshev'; 'PHP Internals'
> Betreff: RE: [PHP-DEV] Design by Contract
>
> I will try to explain
Hi Andrea,
Le Sat, 14 Feb 2015 04:18:28 +0100, Andrea Faulds a écrit:
Hi everyone,
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful
addition.
Yup, totally use
On 14/02/15 01:16, Andrea Faulds wrote:
>> - About the 'numeric' type you would introduce in a future RFC, would you
>> (in strict mode) allow everything accepted by is_numeric() or is it just a
>> shortcut for 'int|float’ ?
> The idea is just int or float (except in weak mode of course, where it
On 13/02/15 21:16, Nikita Nefedov wrote:
>> Can't we restore the simple way of working in PHP7
>> where it does not need to wrap around other things quite so closely?
>
> Hi Lester,
>
> This way if doing things on php didn't go anywhere, people just stopped
> using it because they saw better alte
Hi Francois,
Now I understand what you are discussing. Since we may have stricter
typing, we probably better
to consider type safety theory even if PHP is weakly typed.
What I'm going to write is not type theory, though.
On Sat, Feb 14, 2015 at 3:16 PM, François Laupretre
wrote:
>
> The theory
On Sat, Feb 14, 2015 at 01:03:44PM +0800, Xinchen Hui wrote:
>function a() : void {};
>
> following codes still works:
>
>$b = a();
>
> so, if you want a void return type, and if you want it to be a useful
> feature..
>
> above expr should be invalid with an error " a() return nothin
41 matches
Mail list logo
