PHP is just letting them be sloppy and remove
other people's type hints.
The other thing to consider is whether the same special case should be
added (in reverse) to return type hints - a sub-class could *introduce*
a return type hint, as long as the parent class did not already declare one.
Regards,
--
Rowan Collins
[IMSoP]
ny
value, or even a base for all objects, so I guess we have to take that risk,
but at least if contravariance were fully supported, we could have clear
examples of correct usage.
(Incidentally, I'm not sure how templates are relevant - this is purely about
inheritance and LSP of ordinary objects.)
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 4 February 2015 21:25:49 GMT, Nikita Popov wrote:
>On Wed, Feb 4, 2015 at 10:17 PM, Rowan Collins
>
>wrote:
>
>> On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki
>wrote:
>> >Hi Nikita,
>> >
>> >On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov
&g
sically the definition of a compromise?"
This particular compromise is very well thought through on the whole, and I
hope it at least leads the way out of the impasse of contrasting ideas by
exploring ways to combine them.
Thanks Andrea!
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime D
probably a big
problem for it. The Wikipedia article notes that few languages implement
parameter contravariance, mostly because they'd have to mix it with
type-based function overloading, making real-life examples hard to find.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runt
doesn't care what else it can do.
Regards,
--
Rowan Collins
[IMSoP]
Lester Caine wrote on 05/02/2015 12:33:
On 05/02/15 11:37, Andrea Faulds wrote:
The current description isn’t totally inaccurate, but I had considered renaming
the RFC since “big integer support” implies we don’t already have support for
big integers, though we do in the form of ext/gmp. A bet
Christoph Becker wrote on 05/02/2015 14:01:
Rowan Collins wrote:
There is nothing new about PHP's userland int type being 64-bit on
64-bit platforms. For instance, raising 2 to the power of 62 returns
exactly the same thing on every version of PHP back to 4.3.0:
http://3v4l.org/
readily ( "__sleep should
return an array only containing the names of instance-variables to
serialize").
Personally, I'd have made this a Warning rather than a Notice, since
it's clearly discarding data, but it should be consistent either way.
Regards,
--
Rowan Collins
[IMSoP
On Thu, Feb 5, 2015 at 9:57 AM, Rowan Collins <mailto:rowan.coll...@gmail.com>> wrote:
Playing around with existing behaviour, if you return something
other than an array, you get a Notice and a serialized null ('N;')
- e.g. http://3v4l.org/rm9rs
I think it
Lester Caine wrote on 05/02/2015 14:51:
On 05/02/15 14:24, Rowan Collins wrote:
There is nothing new about PHP's userland int type being 64-bit on
64-bit platforms. For instance, raising 2 to the power of 62 returns
exactly the same thing on every version of PHP back to 4.3.0:
http://3v4
Lester Caine wrote on 05/02/2015 16:49:
On 05/02/15 16:24, Rowan Collins wrote:
The simple answer here is that there is not a 'single' definition of
integer ...
True. But the definition of "integer" in PHP is, and has been for many
years, "as big as this build can han
}
class VoteEvent extends Event { ... }
interface LoginEventListener { public function handleEvent(LoginEvent $event); }
interface VoteEventListener { public function handleEvent(VoteEvent $event); }
class DebugEventListener implements LoginEventListener, VoteEventListener {
public function handleEvent(Event $event) {
// Code using only methods and properties of the base Event class
}
}
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 5 February 2015 23:22:26 GMT, Andi Gutmans wrote:
>having such a declare(…) syntax will be ridiculed by the broader app
>dev community until the end of time…
I think that's laying it on a bit thick. It's no worse than Python's "from
__future__ import", or JS's 'use strict;' (quotes included
PCRE-compatible regex) it ought to be fairly easy to add;
the existing implementation is here for comparison:
http://lxr.php.net/xref/PHP_TRUNK/ext/filter/logical_filters.c#575
[1]
http://grokbase.com/t/php/php-internals/149jfzxtq3/internationalized-domain-name-support-in-filter-validate-url
avoided (as
with the change to DateTime typehinting mentioned recently), but it's
not something that goes without saying.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
r than adapt it
into a cross-compatible state, would help people look out for the same
situation arising in future.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s (probably including
strict types) the declaration itself could be completely ignored, rather
than causing the file to be parsed as empty (which is probably no more
useful than it emitting a parse error). I wonder if it's feasible to
write extensions for *old* versions of PHP which add new decl
ction between (B) and (C), such as a compiled template
cache, and inject a string from user input, or a file in (A), which will
then be executed
[1]: http://php.net/manual/en/ini.core.php#ini.open-basedir
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
what problem you're trying to solve, but this to me
looks like a piece of magic that doesn't resemble anything else in PHP.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"encoding", but excludes "strict_types"?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is* multi-threaded, you have another set of headaches about how both
the engine and the userland can share and synchronize.
Not that I don't like the idea, but it's a huge project, with potential
for profoundly affecting the language.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Inter
On 08/02/2015 20:53, Lester Caine wrote:
On 08/02/15 19:00, Rowan Collins wrote:
We have a single code base happily running on 5.2, 5.3, 5.4, and I think
even 5.5, so it is definitely possible with some code bases. There were
a few pieces that had to be changed to work right under 5.3 and 5.4
ent error handler registered".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is rather verbose and
ugly. Also, having it behave differently from all other declare() statements
would bring into question why we even bother reusing the declare() syntax.
I'd rather verbose and clear than concise and vague.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine wrote on 09/02/2015 01:31:
On 09/02/15 00:05, Rowan Collins wrote:
>>Some of the new 'styles' of writing things are
>>going to make things considerably worse for those who are going to have
>>to maintain this code in the future.
>
>If you
On 9 February 2015 02:16:53 GMT, "S.A.N" wrote:
>2015-02-09 2:26 GMT+02:00 Rowan Collins :
>> On 09/02/2015 00:02, S.A.N wrote:
>>>
>>> You're right, but there is no threading issues.
>>> One worker synchronously execute requests, but may run pa
.
Keep your conspiracy theories for Youtube, and concern yourself with the
real proposals that are actually happening, all of which are evolutions
of the language.
Regards,
--
Rowan Collins
[IMSoP]
Andrea Faulds wrote on 09/02/2015 00:05:
If you're going to go that far, why not just disallow the block-level syntax of
declare() for this case, if that is the complaint? Or if the problem is the
non-block syntax, why not enforce that a non-block declare(strict_types) be at
the top of the fil
Pierre Joye wrote on 09/02/2015 00:05:
On Mon, Feb 9, 2015 at 6:30 AM, Rowan Collins wrote:
On 08/02/2015 20:33, Zeev Suraski wrote:
FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(),
whic
S.A.N wrote on 09/02/2015 17:40:
2015-02-09 12:41 GMT+02:00 Rowan Collins :
Yes, I can see it working well for specialised uses - you can simply not use
those aspects of the language that don't make sense. But for it to be a
mainstream part of the language, it needs to play nicely with
Rowan Collins wrote on 09/02/2015 18:24:
S.A.N wrote on 09/02/2015 17:40:
2015-02-09 12:41 GMT+02:00 Rowan Collins :
Yes, I can see it working well for specialised uses - you can simply
not use those aspects of the language that don't make sense. But for
it to be a mainstream part o
ences.
I don't think anyone has suggested maintaining the underlying library. Several
have suggested attempting to build at least a partial compatibility layer on
top of openssl or other maintained libraries. Others have suggested adding
aggressive warnings whenever the extension is used. I'm sure more suggestions
will follow.
What is clear is that *something* should be done, but that consensus was that
simple removal was not appropriate in this case.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eople have already pointed out that
ext/mcrypt needs some special thought, so just slapping a deprecation
notice somewhere isn't really that useful.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
c, which would
accomplish the goal but make them rather unwieldy. It might be worth
considering, though, given we know the situation's not just hypothetical.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11 February 2015 22:41:21 GMT, Lester Caine wrote:
>On 11/02/15 21:46, Andrea Faulds wrote:
>> Anthony Ferrara also had his own analysis which showed some of the
>problems with weak type hinting, and where strict types can be
>beneficial: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.h
o? It
strikes me as rather like the case of "var" for properties, which had
the deprecation notice removed.
I think it would make more sense to raise an E_STRICT, since the main
purpose seems to be to discourage users making such calls.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Inter
null (e.g. $count++, or $hash[$key] = $value, or even echo
$hash[$key]).
Perhaps what's needed is a survey of current messages, and an RFC to
reclassify them based on some consistent definitions?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
T
should be to give the user a helpful notice.
Whether that should be E_DEPRECATED or E_STRICT is a minor detail, and
depends on us predicting the future. My personal prediction is that this
will go the way of "var", and remain as a discouraged but supported
feature, but it's really not that big a deal.
Regards,
--
Rowan Collins
[IMSoP]
to fix
don't get drowned in the noise of things which you know you should get
around to fixing one day but are working as designed right now.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the use of $this.
Our choice is between keeping that ambiguity, and introducing a new rule that
any method not marked static must never be called statically (with provisos for
technically non-static parent:: etc).
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 15/02/2015 19:32, Marc Bennewitz wrote:
Am 15.02.2015 um 19:09 schrieb Rowan Collins:
The static modifier for methods is part of the method signature and
method body isn't.
(That's way interfaces doesn't describe method bodies but signatures)
The static modifier defi
er to read, and harder to extend, in exchange for typing a
few characters on each call (you could call it something shorter, like
"::inst()" if you valued brevity) so a -1 from me.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eaving the door open to start all over
again. I think it will hurt people's faith in the process to cancel now,
and can't think of a particularly strong reason not to let the vote run
its course before deciding what to do next.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Int
On 15/02/2015 20:20, Patrick Schaaf wrote:
Am 15.02.2015 21:05 schrieb "Rowan Collins" <mailto:rowan.coll...@gmail.com>>:
>
> This sounds to me like you should just be using the Singleton pattern,
Of course this is singleton under the hood.
> // Now wherever in t
ess".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
dn't also include those, while retaining the key
characteristic of the default behaviour being to carry on with some
fallback value (an empty loop, a null variable, etc) rather than to
die('Uncaught Warning Exception!').
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Ru
into
two separate classes.
[1] http://laravel.com/docs/4.2/facades
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
", i.e. the same meaning proposed for any method
that omits the keyword "static". By your reasoning, you could say that
adding "static" just means "foo() method doesn't use $this". The point
is that you're making an explicit choice one way or another
ts of queries against, so
global/singleton access is very convenient.
I do see the use case, but am not sure it's compelling enough to add a
language feature, given that a similar effect can be achieved using
existing features.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime D
function
which currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate
to be converted under the current RFC.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
y different from those she stated, just
because it fits their world view and gives them an excuse to talk about it.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
François Laupretre wrote on 16/02/2015 12:27:
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
Please can we take Andrea at her word:
> This isn’t a judgement of the PHP community nor the internals mailing
list, you’re all wonderful people and it’s really been a pleasure, and I
mean t
ust
putting off all the decisions for another year.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Feb 16, 2015 at 6:41 PM, Rowan Collins <mailto:rowan.coll...@gmail.com>> wrote:
Is there any value in deciding the initial syntax for 7.0, and
implementing only non-parameterised annotations, i.e. you can call
hasAnnotation(string): bool but nothing else?
Dmitry Sto
c.git;a=blob_plain;f=README.MAILINGLIST_RULES;hb=HEAD)
Cheers,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
5 at 15:31, François Laupretre wrote:
> > De : Rowan Collins [mailto:rowan.coll...@gmail.com]
> >
> > Saying "that's enough" isn't even a productive comment. Enough what?
> > What is it you are asking to happen next?
>
> Maybe an initiative to wri
Tony Marston wrote on 17/02/2015 09:59:
"Rowan Collins" wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example,
e() syntax that everyone seems to have an
irrational hatred of?
declare(pragma=Example\DbcParserExtension);
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alexander Lisachenko wrote on 17/02/2015 14:21:
2015-02-17 16:35 GMT+03:00 Rowan Collins <mailto:rowan.coll...@gmail.com>>:
The other alternative is to go to the other extreme, and have the
extensions scoped to a particular file, more like Perl pragmas.
Dare I say we coul
similar.
What you have identified there is a danger to be watched out for,
certainly, but it is not an inevitable outcome, if we come up with a
decent set of guidelines of how the feature should be used.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing L
"we can argue what's in this list separately". Sara's after reactions to
the principle of having meta-types/unions in general, not their
definitions, right now.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Michael Wallner wrote on 18/02/2015 11:39:
On 18/02/15 12:31, Rowan Collins wrote:
Michael Wallner wrote on 18/02/2015 11:19:
On 17/02/15 23:03, Sara Golemon wrote:
1) Introduce scalar types for primitives: bool, int, float, string,
resource, object (we already have array)
1a) Introduce meta
nted, it behaves like so; if it's not, it behaves the same way it
did in PHP 5.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Leigh wrote on 18/02/2015 13:31:
On 18 February 2015 at 13:18, Rowan Collins wrote:
This leaves us in a state where some functions will have defined types
with their aggressive coersion rules and some will not, and we can't
expect users to remember which set of functions have been updat
function accept_string_object(\String $string) { ... }
The nice thing about this is that if we ever allow users to define
"basic" types - copy-on-write structs, range types, enums, etc - they
could "extend" these built-in types.
Does that make sense to anyone, or am I ov
François Laupretre wrote on 18/02/2015 18:05:
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
What if we defined the types as names in the \PHP namespace, but defined
a slightly different algorithm for resolving typehints vs other uses:
function foo(\PHP\types\numeric $a) // unambiguous
Tony Marston wrote on 18/02/2015 10:52:
"Rowan Collins" wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
"Rowan Collins" wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC
suits my needs.
So how to start? Where can I find some documentation?
Thanks
Tom
Hi,
You might find some useful tips in these previous threads:
- http://marc.info/?t=14163198842&r=1&w=2
- http://marc.info/?t=14217322651&r=1&w=2
Regards,
--
Rowan Collins
[IMSoP]
-
job than what you have proposed, and since
I keep mentioning it, I should probably stop talking and start doing,
but I'm not convinced of the value of tinkering around the edges without
tackling the underlying problem.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime De
nce for other participants to follow the discussion, because they don't have
to devote hours to reading every word, but are instead alerted to salient
points they might want to think about and respond to further.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pierre Joye wrote on 24/02/2015 01:57:
On Feb 23, 2015 2:48 PM, "Rowan Collins" <mailto:rowan.coll...@gmail.com>> wrote:
>
> On 22 February 2015 23:56:18 GMT, Pierre Joye <mailto:pierre@gmail.com>> wrote:
> >Can you all of you stop this madness wit
}
If fopen() starts throwing exceptions here, that's as much a BC break as
it throwing them everywhere. If it doesn't, the rules for when it should
throw become even more complicated, and useful in even fewer cases.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Ru
particularly if the BaseException
superclass is added.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
7;phar://';
// You could explicitly allow a "function form" of the statements, so
you could parse this:
include(('phar://phar_file/' . $script_name), 'phar://');
// But then you've got a subtle BC break, because the interpretation of
this changes:
sort_callback)
$comparison_callback = function($l_key, $l_value, $r_key, $r_value) use
($ksort_callback) { return $ksort_callback($l_key, $r_key); };
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ilar to FastCGI, which could be sent multiple requests
representing POSIX command invocations, and serve them from a threaded
environment. So instead of "php composer.phar install", you'd run
"php-fastcli --port 5 composer.phar install", which would "attach&quo
ge my Unicode string is in; I don't even
understand what this means
I think an efficient OO wrapper around ICU is a great idea, but more
thought needs to go into what methods are exposed, and how people are
going to use them in real code.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Intern
On 28/02/2015 02:37, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins
mailto:rowan.coll...@gmail.com>> wrote:
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for removing "allow_url_include" INI option. [1]
orth it. Having a function called str_pos
which is an alias of strpos, but only on some versions, is more confusing, not
less.
Some people, such as the author of phpsadness.com, enjoy ranting about things,
and would probably find a way to be as critical of the new aliases as the
current names.
R
?
In this respect, some version of UString makes more sense, because (if
well-defined) it actually gives users some advantage over the current functions.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
isation of using a byte-level encoding the user is likely to
use as input and output, i.e. UTF-8.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
uld have thought any extension can hook into the operator
overloading API that GMP uses, just as they can hook into other object
behaviours.
Is there some difference between how "bundled" and PECL extensions are
loaded that would prevent this?
Regards,
--
Rowan Collins
[IMSoP]
.
Since there's no real BC break here, there's no reason it couldn't be
bundled into 7.1 if it was deemed ready by then, so it seems unwise to
rush into including it in 7.0 straight from what feels like a prototype
implementation.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP
a
trivial implementation.
Obviously, this means more implementation needed on the engine side, in
that it needs to expose callback functions for the various different
comparisons, but I think that's where the comparison logic belongs.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internal
Rowan Collins wrote on 02/03/2015 10:52:
Thomas Gielfeldt wrote on 02/03/2015 07:43:
2015-02-24 17:17 GMT+01:00 Thomas Gielfeldt :
Hi internals.
I've made PR proposing a feature request: A new interface Sortable.
https://github.com/php/php-src/pull/1116
If possible, I would like to c
personally have preferred generators to have used a distinct
keyword rather than just looking like functions, but since that ship has
sailed, making them look even more like functions worries me. Is there
perhaps some other syntax that could be used for this "generator result
value"
uding Rasmus himself; no ill will intended!), but
just adding some slightly different names for the same things will
muddle people more, not less.
I'm sorry, but this isn't going to be any more popular a suggestion than
the last ten times it was proposed.
Regards,
--
Rowan Collins
[
tive.
If we're going to have an alternative, let's come up with a creative
alternative that actually has an advantage to using it, not a choice
between equally cryptic names like "strripos" vs "str_ripos".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals
On 02/03/2015 22:59, Yasuo Ohgaki wrote:
Hi Rowan,
On Tue, Mar 3, 2015 at 7:50 AM, Rowan Collins <mailto:rowan.coll...@gmail.com>> wrote:
On 02/03/2015 22:36, Yasuo Ohgaki wrote:
I like scalar objects, but it does not resolve that PHP has
non standard
On 2 March 2015 at 21:24, Daniel Lowrey wrote:
> Rowan Collins wrote on 02/03/2015 14:44:
>
> > Could you explain a bit more about how the generator return
> > functionality is necessary for this? It seems to me like it's still just
> > a "nice to have
functions named the way they are?", in which case
Rasmus has provided the answer, in terms of "vertical consistency" with
cross-language libraries.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
$foo = getSession(42);
$json_data = $foo->current();
$foo->send($json_data);
$decoded = $foo->getReturn();
But never mind, I think we both get the idea.
I understand the desire for a "final result", but I don't like reusing
the word "return", because it's never "returned" as the result of
running the function, it's just made available through some specific
method/syntax.
Regards,
--
Rowan Collins
[IMSoP]
Bob Weinand wrote on 03/03/2015 12:08:
Am 03.03.2015 um 12:34 schrieb Rowan Collins :
Niklas Keller wrote on 03/03/2015 10:55:
Gr, top-posting...
Sorry, was on mobile. ;-)
However, since the existence of the word "yield" is the only thing
that
marks a coroutin
Niklas Keller wrote on 03/03/2015 12:52:
2015-03-03 13:27 GMT+01:00 Rowan Collins <mailto:rowan.coll...@gmail.com>>:
Bob Weinand wrote on 03/03/2015 12:08:
Why should the word "return" be unique to methods or functions?
It just doesn't feel like th
It's in the main repo along with all the other bundled extensions:
http://lxr.php.net/xref/PHP_TRUNK/ext/opcache/
It's been bundled since 5.5:
https://wiki.php.net/rfc/optimizerplus
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3 March 2015 18:54:56 GMT, Yasuo Ohgaki wrote:
>Hi Rowan,
>
>On Tue, Mar 3, 2015 at 7:13 PM, Rowan Collins
>wrote:
>
>> Yasuo Ohgaki wrote on 03/03/2015 04:01:
>>
>>> Hi Lester,
>>>
>>> On Tue, Mar 3, 2015 at 9:19 AM, Lester Caine
but nothing beats
functionality built right into the language distribution).
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 4 March 2015 00:46:49 GMT, Yasuo Ohgaki wrote:
>Hi Rowan,
>
>On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins
>wrote:
>
>> You are measuring the wrong cost. The cost of adding new names is to
>> people writing code:
>>
>> - additional confusion for new us
On 4 March 2015 07:12:41 GMT, Thomas Gielfeldt wrote:
>2015-03-02 16:26 GMT+01:00 Rowan Collins :
>
>> Rowan Collins wrote on 02/03/2015 10:52:
>>
>>> Thomas Gielfeldt wrote on 02/03/2015 07:43:
>>>
>>> 2015-02-24 17:17 GMT+01:00 Thomas Gielfeldt :
&
1 - 100 of 1644 matches
Mail list logo
