On 28 August 2019 18:45:18 BST, Matthew Brown wrote:
>Kicking a house is a poor analogy IMO - most people don’t upgrade a
>major
>language version without first verifying that their code still works in
>the
>new version.
Probably. Most analogies fall down pretty quickly. I just feel like some
ht now.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
er can do so?
Does that sound reasonable?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nically impressive, and very much usable by other
>orgs
>too.
I literally have no idea what to take from that response. Some organisations
are slow, some have cool workflows, so let's break all the things?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing Li
ing QA impact etc) is a significant investment for
many organisations. That's why it has the potential to delay adoption of a new
version, and why a long lead-in via deprecation or opt-in is necessary.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailin
h limited resources.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on period, or
an opt-in mode, are about that change, not a disagreement about the principle.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t
state.
One rather ugly possiblity in this case would be to have the values returned be
"uninitialized", so that accessing the array keys was valid, but accessing the
values gave an Unitialized Value Error. That would be pretty horrible for
backwards compatibility, though, particular
ide how they wanted to
use it, and PSR-4 would probably be superseded by something which
accounted for packages existing.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"Foo" - either a class, an
interface, a trait, or a package. If it wasn't what the engine was
expecting, it would be an error, just as it is right now if you write
"implements ClassName", or "new TraitName();"
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Inter
the relevant point is that you can define function foo() {} and class
foo {} in the same namespace; as long as you couldn't also have a
separate package foo{}, it could share the same autoloader as classes,
interfaces, and traits.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
think it works. The things that make
weeds a problem are that they take up space, they take up nutrients, and
they spread. I don't think short open tags does any of those things.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
https://blog.jetbrains.com/phpstorm/2019/02/new-phpstorm-meta-php-features/
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 13/08/2019 23:28, Mark Randall wrote:
On 13/08/2019 21:26, Rowan Collins wrote:
Ah, that makes sense. Does that necessarily mean we need a dummy
class, though? The autoloading logic in the engine knows that it
called the autoload callback expecting a package definition, so can
count
way from actual new features, even if it's just the mental energy of
monitoring and responding to long threads like this one.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
be in OpCache twice with different options, which would be complex
to implement.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 13/08/2019 18:45, Mark Randall wrote:
I thought about this as my first consideration, however it effectively
requires that the PHP code within the package class is fully parsed
and executed in order for it to retrieve the data.
Consider pre-loading where the code is compiled, but not run,
On 13/08/2019 12:01, Mark Randall wrote:
On 13/08/2019 10:02, Rowan Collins wrote:
I really like this approach. It allows a package definition file to
exist, without either the language or the header of each file having
to define its location.
#
# File: /lib/company/project1/a/b/MyClass.php
and eval.
On a bikeshedding note, I've never liked the way declare syntax looks,
so would prefer a new keyword, but the symmetry of replacing declare(strict_types=1); with declare(package=Something\Defining\StrictOptions); is admittedly quite
appealing.
Regards,
--
Rowan Collins
[IMSoP
such feature, there
is no such justification in the RFC, which is why it's so controversial.
Regards,
--
Rowan Collins
[IMSoP]
dvantage over change, which is why
we require a super-majority in primary RFC votes.
Regards,
--
Rowan Collins
[IMSoP]
ult to a new "error" mode
(which could also be explicitly set):
https://externals.io/message/106384#106408
Regards,
--
Rowan Collins
[IMSoP]
tting in the official
distribution as "off" (more compatible) or set it to "error" (to make
mistakes safer and easier to spot).
Regards.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
vote
with one or more clearer questions.
Regards,
--
Rowan Collins
[IMSoP]
ssion can agree on even a summary of what the
issues are, then we have a far bigger problem than how many wiki pages to
create. Most voting reasons would amount to "I agree with point 4, but
disagree with points 3 and 8", rather than needing to restate the whole
case.
Regards,
--
Rowan Collins
[IMSoP]
field in the header,
and Dan already proposed a convention of contributors "signing" dissenting
opinions they agree with. The example you link to says "Author: Zeev
Suraski", so I'm not sure what change you're proposing.
Regards,
--
Rowan Collins
[IMSoP]
I also think the term "negative feedback" might be a bit ... negative.
Elsewhere in your message, you used "dissenting", which I think captures the
essence better. The difference from the main page is not inherently about
positive vs negative, but about allowing different voic
toloader, presumably because the array definition
itself takes so long to compile.
Regards,
--
Rowan Collins
[IMSoP]
would mostly work as presently, but with some notion
of being "owned" by a particular package. This doesn't mean all the
functions of Composer would be integrated, but could provide richer
primitives, such as registering an autoload callback or preload list to a
particular package, rather than having to perform string matches.
Regards,
--
Rowan Collins
[IMSoP]
per IF we agree the proposed
behaviour is a big enough gain.
Regards,
--
Rowan Collins
[IMSoP]
ime many people heard that they needed to stop marking their
call sites was PHP 5.3, released in 2009 and EOL in August 2014.
[1] https://www.php.net/manual/en/migration53.deprecated.php
[2] https://wiki.php.net/rfc/calltimebyref
Regards,
--
Rowan Collins
[IMSoP]
nd class visibility.
>
I think there's some confusion here, because establishing the concept of a
package as separate from a namespace is exactly what I proposed.
Here's a previous message (technically in the same thread, but from 18
months ago) where I also mentioned class visibility:
https://externa
it's a lot less than "99.999%" of what making it mandatory would
bring.
Regards,
--
Rowan Collins
[IMSoP]
$fn($a) might not technically modify $a, but still modify
elements inside it. So it seems like we come back to "this is kind of
useful information but may not actually offer a hard guarantee".
Regards,
--
Rowan Collins
[IMSoP]
neither
really loved either, and the subtleties of how each mode works are likely to be
sources of confusion for years to come. I am far from convinced that it is a
model we should enthusiastically seek to repeat.
Regards,
--
Rowan Collins
[IMSoP]
understand. Part of the motivation for removing short
open tags seems to be to make the language more consistent. The ability for a
package to configure the compiler as its author intended is certainly better
than having to test every combination, but we need to think very carefully
about what options we add.
Regards,
--
Rowan Collins
[IMSoP]
t;PHP 4 behaviour",
because I used it right up until 5.3, exactly how this RFC is now
suggesting is the future. (I guess I should have paid more attention to
deprecation notices at the time!)
Regards,
--
Rowan Collins
[IMSoP]
inement over that, but I'm not convinced
> that it a worthwhile refinement relative to the language and engine
> complexity it will introduce.
>
Would it really be that complex? The only real difference between "out" and
"&" would be automatically setting the variabl
estion is
https://wiki.php.net/rfc/explicit_send_by_ref Incidentally, the "Proposed
for" on the RFC needs updating!)
Regards,
--
Rowan Collins
[IMSoP]
his example in particular, because I'd actually love there to be
better guidance on how to convert encodings, and I'd like to remove
utf8_encode and utf8_decode, which I think cause far more damage by being
so badly named. I haven't proposed it, because for the people who are using
those functions correctly, there would need to be a clear replacement, and
right now there isn't.
Regards,
--
Rowan Collins
[IMSoP]
ing working
features, I fear that may happen.
Regards,
--
Rowan Collins
[IMSoP]
, as I said elsewhere, I think 9.0 is a much better time for the full
removal, and I hope the RFC will be amended appropriately.
However, to reiterate, either is still later than the previous RFC.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
he process in some way.
Presumably if it doesn't achieve consensus, the previous plan would
remain in effect.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
cial versioning policy.
As with deprecation itself, any violation of the "no breaking changes" rule,
however slight, should have an explicit justification. If I had a vote, any RFC
omitting such a justification would receive an automatic "no" from me.
Regards,
--
Row
strict mode simply throw
an error for *any* use of the non-strict == and != versions?
declare(strict_operators=1);
var_dump( "11" == "11.0" ); # TypeError: "Cannot use non-strict equality
operator in strict operator mode."
var_dump( "11" === "11.0"); # bool(false)
I'm not sure whether I like the idea or not, but I thought I'd throw it out
there as a possibility.
Regards,
--
Rowan Collins
[IMSoP]
w different combinations will be interpreted.
> I'm starting to believe that a joint effort to fork PHP if the only way out
>
If what you want is a fork of PHP with stronger typing, then take a look at
Hack https://hacklang.org/
Regards,
--
Rowan Collins
[IMSoP]
gets it right as of
PHP 7.3: https://3v4l.org/0431j
A much simpler example, though, is using just the second word of that
string: the accented "s" confuses plain stripos but not mb_stripos.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To uns
g other than
ASCII letters untouched.
So, any non-Latin script, like Greek or Cyrillic; any accented characters,
unless you're lucky and they're represented by ASCII-letter plus combining
modifier; the Turkish "i", which if I remember rightly has three forms not two;
and so on.
Regar
encoded as the sequence U+1F1EC U+1F1E7.
[1]
http://web.archive.org/web/20010605075550/http://www.php.net/manual/en/ref.mbstring.php
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ngle correct function for encoding conversions,
with mbstring, intl, and iconv all offering slightly different
implementations, and all distributed as optional extensions.
Is there some way we can bless a single conversion function, in core, and
recommend that in deprecation notices?
Regards,
--
Rowan Collins
[IMSoP]
ners or
non-printing marks? Often, number of bytes (in some encoding, such as
UTF-8) is actually the relevant measure; other times, "width on screen"
is what is actually required, and very hard to compute.
My point is that any attempt to make the language "do the right thing by
default&
ay.keys);
} else {
# Find highest unused number, starting from the one just deleted
do {
new_highest_key = key_being_unset - 1;
} while ( not key_exists(array, new_highest_key) );
array.next_key = new_highest_key + 1;
}
}
I've no idea if this is plausible or not.
Regards,
--
Rowan Collins
[IMSoP]
has the opposite been
considered: process an existing set of stubs to remove unsupported or
irrelevant annotations, and import into php-src with this tool? That way,
the manual effort for existing functions would be virtually zero.
Regards,
--
Rowan Collins
[IMSoP]
l distinction
and constraint.
If we really need automatic capture, I'd prefer for it to be opted into in
the normal syntax, e.g. "function() use(*) { ... }". We could even have
"use(&*)" for "automatic capture by reference", if we wanted to go that far.
Regards,
--
Rowan Collins
[IMSoP]
to
something like:
> A system error has occurred.
> Please contact the site administrator.
> If you are the site administrator, please check your error logs for
details of the error.
Regards,
--
Rowan Collins
[IMSoP]
?
Something like:
a) not affected, because handling is consistent with userland anyway
b) should explicitly accept nulls
c) should explicitly reject nulls
We do however have to make a tricky judgement on functions in category c,
of how much code is going to break if we make them stricter.
Regard
tring or surrounded by whitespace)? For instance, would "A ??= B" be
"unescaped" to "A ?= B" or passed through as is? Note that this changes the
scope of the BC break, as well as the usability of the chosen syntax, as
both "?=" and "??=" could be defined as operators.
Regards,
--
Rowan Collins
[IMSoP]
* in having more variants and complexity in syntax to understand
and be tripped up by, even if it actually mad the internals simpler for
some reason. I don't personally think that applies here, but it's a
reason someone voting might decide to consider.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP
ace,
> gender, email, etc...,
>
This is exactly the kind of place I would *not* want a simple toArray()
function. Should (array)$person (or $person->toArray()) return
['firstName'=>'Rowan', 'lastName'=>'Collins'], or ['name' => 'Rowan
Collins'], or ['name' => ['Rowan', 'Collins
uffers from similar problems, and is IMO useful
only because it's automatically recursive. I presume the proposed mechanism
would not be, i.e. return [$foo] would not be interpreted as return
[(array)$foo].
Regards,
--
Rowan Collins
[IMSoP]
ven a slight security advantage over scenario (b),
we should think very carefully before removing the feature.
Regards,
--
Rowan Collins
[IMSoP]
ks like
we just require the user to have run "createdb test" before running the
test suite.
Regards,
--
Rowan Collins
[IMSoP]
On 27 April 2019 13:51:11 BST, Lester Caine wrote:
>On 27/04/2019 13:37, Rowan Collins wrote:
>> The only way I've seen dates stored as integers is as a number of
>> seconds / milliseconds / whatever since some epoch, most commonly
>> seconds since 1970-01-01 00:00:00 UTC
&
?
I'm sure there are use cases for this syntax, but the examples in that
e-mail were poorly chosen.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ar approaches work for other contexts, for instance:
const GIBIBYTE = 1024 ** 3;
const GIBIBYTE = 2 ** 30;
both read more clearly than anything you could do with underscores:
const GIBIBYTE = 1_073_741_824;
const GIBIBYTE = 0x40_000_000;
const GIBIBYTE = 0b1_0_0_0_0_0_0;
Regards,
--
Rowan Collins
[IMSoP]
omplexity, the edge
case was just made into a documented limitation.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
less from everything else.
My personal bias against it is that I'm too used to reading \ as "escape", so
every time I see examples my first reaction is "what does an escaped
parenthesis mean?" I'm sure I'd get used to it, but I prefer "fn" because it
more immedia
d VSCode is written in JS; I doubt they
share any parser components with each other, or with anything written in C
or PHP itself.
We're not just talking about existing tools, either, but every tool created
until the language dies.
Regards,
--
Rowan Collins
[IMSoP]
with
something which requires complex lexer/parser rules, then every editor,
IDE, and static analysis tool will need to also work with that syntax.
For those saying they "slightly prefer" ==> please ask yourself, do you
prefer it enough to add complexity to every tool that wants to p
on!
Regards,
--
Rowan Collins
[IMSoP]
that needs to support 7, 8 and
9 can be explicit, and hopefully not many people will be jumping directly
between 7 and 9.
Regards,
--
Rowan Collins
[IMSoP]
To Do It.
The big downside of all this is that even if the compiler understands
what all the combinations of flags will do, the human reading the code
won't necessarily, so having declare(increment_warnings=1) probably
doesn't add much over just documenting the change somewhere.
Regards,
tions.
None of this is a problem with a simple "default" keyword, which would
work reliably with all existing function signatures where a default is
defined, and require no change in code or practice on the part of
library authors, so can be introduced right now, and used straight awa
t
parameter.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ly because it has less
concern about backwards compatibility.
Regards,
--
Rowan Collins
[IMSoP]
hrows descendants
of FooException or BarException".
Then you end up with this kind of fun:
function curryish(callable<(int, float): int throws
FooException|BarException> $callback): callable<(float): int throws
FooException|BarException> {
return fn($x) => $callback(42, $x);
}
Regards,
--
Rowan Collins
[IMSoP]
features
which don't work nicely with them.
Regards,
--
Rowan Collins
[IMSoP]
icky part is that PHP is a highly dynamic language, so there's a lot
of cases where the analysis can only return "maybe". My understanding is
that this is what a lot of the work on Hack is doing: creating a language
which looks a lot like PHP, but doesn't have as many ambiguous cases which
can't be analysed statically.
Regards,
--
Rowan Collins
[IMSoP]
sit string keys later.
Regards,
--
Rowan Collins
[IMSoP]
no
chance to and is killed outright instead.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
at's already easy.
Regards,
--
Rowan Collins
[IMSoP]
and a comment,
unless it changes the behaviour of the language in some way.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the difference between enforcing "add an ! before
the name if it throws" and "add a comment next to the name if it
throws", or even "add X to the name if it throws", unless the language
itself is going to perform some extra check.
Regards,
--
Rowan Collins
[IM
is to be explicit
and clear. If you just want to type less, use an IDE or editor with good
auto-complete support.
Regards,
--
Rowan Collins
[IMSoP]
great way of
clarifying your design), and use an IDE or CI tool that will tell you when
they're missing or incorrect.
Regards,
--
Rowan Collins
[IMSoP]
avoid the word "smallest". PHP_FLOAT_MIN could be described as having
the "smallest magnitude", and -PHP_FLOAT as being "the largest magnitude,
but negative".
Perhaps:
> Closest representable positive floating point number to zero. If you need
the
> negative number furthest
making it non-associative, so that you have to use parentheses
in "$a ? $b : $c ? $d : $e" would break very little code, in an obvious
way, and help with a major pain point people have with the language.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Ma
e original RFC thread for the
pros and cons, and why I suggested a "PHP 8 Preview" would be a better
target for people to test against.
Regards,
--
Rowan Collins
[IMSoP]
ions in one RFC.
Regards,
--
Rowan Collins
[IMSoP]
drink before reading through the examples
in this RFC then: https://wiki.php.net/rfc/string_to_number_comparison
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
but incrementing them results in 1."
>
The NULL part of that has always baffled me. Why should ++ not be
symmetrical with -- here?
In general, documenting what we currently do is great, but is separate from
agreeing that it's what we *should* do.
Regards,
--
Rowan Collins
[IMSoP]
On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote:
> On Mon, 25 Mar 2019 at 13:30, Rowan Collins
> wrote:
> >
> > One suggestion for an additional section: update the RFC with feedback,
> > particularly if it is withdrawn or rejected.
>
> I think that knowledge could
se issues", rather than just "it didn't get
very far before, but we can't remember why". This is something I intend to
do with my own "locked classes" RFC: I'm probably going to withdraw it
because I don't have time to rework it, but will try to summarise where a
new RFC c
s offered for PHP 7.4. That way, the deprecation
notices are immediately actionable, and the new home of the extension gets more
publicity.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
fixed for 8.0).
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ively developed third-party system, this
is probably actually the best model, with PHP Internals experts providing
advice where necessary, and third-party experts tracking innovations in the
particular system.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailin
quot; because
it's a familiar syntax, but really we're just defining the logic for a
nextStep($x) function.
Regards,
--
Rowan Collins
[IMSoP]
ay-returning syntax, either alongside or
instead of a generator-returning one.
Regards,
--
Rowan Collins
[IMSoP]
hether generators should be added to the
language.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
this:
$a = (() => { $a=[]; foreach ( $x as $y ) if ( $y < 2 ) $a[] = $y;
return $a; })();
By all means let's try to weigh the cost and benefit, but let's not jump
to the conclusion that the cost is nearly infinite and the benefit is
nearly zero.
Regards,
--
Rowan Collins
[IMSoP]
--
1 - 100 of 1629 matches
Mail list logo
