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 of
ctually need to kick, right now.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t it earlier 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
ly 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 Maili
mpanying 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
h limited resources.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
accurately without having a representation of that
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 horribl
if this was
how packages were implemented, people would decide 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
name "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]
--
ading functions and constants, but
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
ut I don't 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 unsu
oks entirely natural to a PHP programmer.
[1]:
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 as
ning up" is that it takes
energy away 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
using; or for
it to 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, i
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
[
y removing the old feature. Since there is no such feature, there
is no such justification in the RFC, which is why it's so controversial.
Regards,
--
Rowan Collins
[IMSoP]
ys have a starting advantage over change, which is why
we require a super-majority in primary RFC votes.
Regards,
--
Rowan Collins
[IMSoP]
arlier that it could default to a new "error" mode
(which could also be explicitly set):
https://externals.io/message/106384#106408
Regards,
--
Rowan Collins
[IMSoP]
ended ini setting 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
the vote
with one or more clearer questions.
Regards,
--
Rowan Collins
[IMSoP]
us and majority. If
no two participants in a discussion 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]
t; 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]
it.
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 diff
d" autoloader, presumably because the array definition
itself takes so long to compile.
Regards,
--
Rowan Collins
[IMSoP]
code 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]
n't necessarily be a show-stopper IF we agree the proposed
behaviour is a big enough gain.
Regards,
--
Rowan Collins
[IMSoP]
he first time 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]
er for inheritance and 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 cla
me benefit to readers, but
I think it's a lot less than "99.999%" of what making it mandatory would
bring.
Regards,
--
Rowan Collins
[IMSoP]
value, for
instance, so $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]
hated, but 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]
the language harder to 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]
ught of this as "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]
he out/inout approach is a refinement 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 b
question is
https://wiki.php.net/rfc/explicit_send_by_ref Incidentally, the "Proposed
for" on the RFC needs updating!)
Regards,
--
Rowan Collins
[IMSoP]
o have a Right Way to do everything, we should be saying
what that Right Way is.
I picked this 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]
y, given the current zeal for removing working
features, I fear that may happen.
Regards,
--
Rowan Collins
[IMSoP]
le.
Yes, 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 Maili
the 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
with official 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
the 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]
alues or remember how 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]
ly 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
T
ything 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;
an
because it is 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
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]
e combiners 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
x(array.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]
ver, 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]
ns are for short expressions" is a useful 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]
but it should be limited 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]
ns in core?
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 stricte
(start/end
of string 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]
*users* 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 Coll
e, last name, age, race,
> 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 ['nam
ializable actually suffers 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]
a) gives even a slight security advantage over scenario (b),
we should think very carefully before removing the feature.
Regards,
--
Rowan Collins
[IMSoP]
t looks 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
90430?
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
;
const SECONDS_IN_DAY = SECONDS_IN_HOUR * 24;
$lifetimeSecs = 7 * SECONDS_IN_DAY;
Similar 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]
hole bunch of complexity, 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
tands out 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"
rm is written in Java, and 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]
ty tooling: if we go 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
27;re running
out of punctuation!
Regards,
--
Rowan Collins
[IMSoP]
tive in PHP 9, because anybody 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]
l motto
of There More Than One Way 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
default parameters in existing
functions.
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 int
ue for that
parameter.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the moment
Hack is much further into that project than PHP, partly because it has less
concern about backwards compatibility.
Regards,
--
Rowan Collins
[IMSoP]
r "any callable that only throws 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]
but also *removing* PHP features
which don't work nicely with them.
Regards,
--
Rowan Collins
[IMSoP]
he tricky 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]
haviour as for parameters, and then revisit string keys later.
Regards,
--
Rowan Collins
[IMSoP]
eir code, it has 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
tax for something that'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
e it
I'm struggling to see 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.
and why, if your aim 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]
even implemented the function can be a 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]
27;d 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 fur
think 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 Developme
see the 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]
voting options 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
idn't happen last
time, and see if you can fix those 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
fered 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
ready
fixed for 8.0).
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
y actively 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 M
reach ( $previousStage as $x ) { yield $x; }" because
it's a familiar syntax, but really we're just defining the logic for a
nextStep($x) function.
Regards,
--
Rowan Collins
[IMSoP]
ving a dedicated array-returning syntax, either alongside or
instead of a generator-returning one.
Regards,
--
Rowan Collins
[IMSoP]
ing whether 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
eturn $a; })();
or with the shortest closure syntax I can think of, 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 inf
1 - 100 of 1644 matches
Mail list logo
