to be more commonly used than it is today.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ed; my suspicion is that what they
really want is a clearer message to users that they shouldn't use the
feature.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ase, the only
edits are to add a list of names, which is basically what the voting
widget does anyway, so I really can't see any reason to be upset about it.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ubmit a patch to that library, wait for the maintainer to accept
it, and make sure I can use the latest version; if the library raises extra
Errors, I have to delay my upgrade, or run a patched version of the
library, until it's fixed.
Regards,
--
Rowan Tommins
[IMSoP]
On Wed, 28 Aug 2019 at 10:33, Nikita Popov wrote:
> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
> notice is really
e are four repos I found" to "GitHub
is the way to go"; we should be making specific arguments for why it will
meet our needs, and evaluating it among all the alternatives.
Regards,
--
Rowan Tommins
[IMSoP]
but a lot of the longer threads would be
better off with just a subject line.
Regards,
--
Rowan Tommins
[IMSoP]
antage over Discourse, or PHPBB, or
Trac, or Phabricator, or Bugzilla, or probably hundreds of suggestions we
could evaluate.
Regards,
--
Rowan Tommins
[IMSoP]
discussion forum?".
As a code collaboration platform, GitHub is pretty good, but it's not built
as a discussion forum, and there are plenty of limitations to using it as
one.
Regards,
--
Rowan Tommins
[IMSoP]
something is classified as Notice or Warning.
Regards,
--
Rowan Tommins
[IMSoP]
$foo[$key1] doesn't yet
exist.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
quot;; it's saying "I want to do this
specific thing, I just want to do it in fewer lines of code".
The more helpers like this we have, the more I'd be amenable to
*eventually* raising things to Error - although I still think that should
be done over a longer period of time than a single r
quot;this variable is going to be used as an
accumulator with these dimensions".
The "if isset" lines, in my opinion, don't express any intent, and they
don't protect against any real errors; they're just noise to work around a
short-coming in the language.
Regards,
--
Rowan Tommins
[IMSoP]
hilarious parodies of each other's positions.
Regards,
--
Rowan Tommins
[IMSoP]
lines back into one
- or, a way to express the intent of the code more clearly, such as
declaring the shape of an array
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s,
and so on; they don't just say "sorry, you can't do that".
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
mous classes I would love to see it gradually phased
out. I would much rather see syntax for capturing variables in an anonymous
class declaration than new ways to create stdClass objects.
Regards,
--
Rowan Tommins
[IMSoP]
een building
absolutely everything from scratch, and trusting some third parties, with
contingency plans if that trust proves ill-founded.
Regards,
--
Rowan Tommins
[IMSoP]
inst the risks of running our own
infrastructure.
Regards,
--
Rowan Tommins
[IMSoP]
ew Employee( age => 42, name => 'John Smith' );
That would require multiple new features, though, so initializers might be
more achievable in the short term, and perhaps there is room for both,
particularly if support for getters and setters improves.
Regards,
--
Rowan Tommins
[IMSoP]
hich is off-topic.
> Improving protected and private properties initialization through
> constructor is not the main target of current RFC.
>
I don't think it's off-topic to consider whether a related feature would
make this one redundant. However, you've picked a weird sentence to reply
to, because I'm agreeing with you, that the two features could exist side
by side without being redundant.
Regards,
--
Rowan Tommins
[IMSoP]
ance; or c) create and
pass a single instance of some class. The examples look really neat on
their own, but imagine coming on that syntax in someone else's code and
trying to work out what it was doing.
There's definitely some interesting ideas here, but they're not all part
of one feature, and they all rely on particular ways of structuring your
code.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
definitions don't look similar, but support both simple and
complex cases in one syntax
Either way, the whole set of features isn't going to be implemented in one
go, so we don't need to work out all the details, just a direction of
travel.
Regards,
--
Rowan Tommins
[IMSoP]
ould find easier than Thunderbird's tree view. There are
certainly downsides to e-mail, and upsides to GitHub, but let's stay calm
and evaluate our options rather than jumping at the first thing we see.
Regards,
--
Rowan Tommins
[IMSoP]
On 16 September 2019 04:13:24 BST, Mike Schinkel wrote:
>
>> On Sep 14, 2019, at 4:47 PM, Rowan Tommins
>wrote:
>> I think that's only true because you've actually proposed a number of
>related but different features.
>
>
>See my other email to the list asking ab
e.
>
>
> Is that problematic? Most language features require code to be structured
> a particular way.
>
> I am assuming that PHP is not an opinionated language that defines one way
> to structure code and shuns all other ways, except for those ways that have
> been explicitly deprecated by RFC such as magic quotes. Am I incorrect
> about this?
>
>
I didn't say it was "problematic"; again, I'm just trying to evaluate these
ideas, and part of that is working out their limitations, and whether there
are alternatives that can be used in more scenarios.
Regards,
--
Rowan Tommins
[IMSoP]
lude saying "I've added a handful of suggestions
relating to X" and discussing the wider issue that links them.
I agree it would be interesting to experiment further, and I think this hybrid
approach would be a good one to try next.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Int
main
discussion stays on the list. Suggestions to improve the RFC itself could
be made inline on the PR by anyone who wanted to, but non-inline PR
comments would be heavily discouraged so that wider comments on the
proposal would stay here.
Either way, I think it's interesting to experiment with dif
from
context treat it as an array; but that array won't have a key $k2, so
you also need to say that reading *that* was deliberate, and from
context treat it as an integer.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
logic is unambiguous, and any additions are just to
suppress unnecessary errors.
To reiterate, my motivation here is to discuss features that help write
these scenarios with less boilerplate, and separate them from other
scenarios where there's a real bug risk which should raise an error.
Regard
the volume itself that's the problem, but
repetition, lack of clarity, or lack of focus. Better support for threads or
topics wouldn't solve those, but it would solve the common case of "this part
of the conversation isn't relevant to me but I want to read the rest".
Regards,
Hi Dan,
On 21 September 2019 12:18:20 BST, Dan Ackroyd wrote:
>On Fri, 20 Sep 2019 at 19:52, Rowan Tommins
>wrote:
>>
>> I think we should be making that volume easy to work with, not trying
>to reduce it as an end itself.
>
>As I've said elsewhere, I think having a centra
caling to a year (or indefinite) after three
or more. That gives warnings more "teeth", and punishments more flexibility.
I would be interested to hear your thoughts on these suggestions.
Regards,
Hi Dan,
--
Rowan Tommins
[IMSoP]
mescale).
Finally, and perhaps most importantly, RFC votes are intended to be
measures of consensus. Taken alongside the discussion, the result strongly
suggests that there is a consensus (but not a unanimous one) to change the
error level, but there is some concern about raising it as high as Error.
Regards,
--
Rowan Tommins
[IMSoP]
before we start digging into detailed answers.
Regards,
--
Rowan Tommins
[IMSoP]
The result is just as logical,
and just as meaningless, as "a number between 0 and 0" - in both cases,
there is exactly one valid value, so every random choice returns that value.
The BC break is a separate discussion - the RFC listed some changes to
openssl_random_pseudo_bytes but not t
On Sun, 29 Sep 2019 at 20:22, Dan Ackroyd wrote:
> On Sat, 28 Sep 2019 at 20:10, Rowan Tommins
> wrote:
> >
> >
> > I would be interested to hear your thoughts on these suggestions.
> >
>
> I encourage you to work on them. Or anyone else who cares to
on the detailed
implementation; but that could make the process feel quite long and
bureaucratic.
Regards,
--
Rowan Tommins
[IMSoP]
to see how tools adopt that feature, and
whether eventually we'll see autoloader functions as just a fallback
mechanism, with most packages being enumerated in advance as large
preloaded blocks.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing
e thing again this time?
Regards,
--
Rowan Tommins
[IMSoP]
e, to make clear they're
expecting to be used this way; but require no additional methods other
than those required by Iterator (or Traversable), Countable, and
ArrayAccess.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the
pieces small, I think. You are totally right, there may be some
unexpected behavior when doing that.
The reason I mentioned it is that without it the new type hint or
interface seems rather limited: I can't imagine many "array" type
constraints being replaced with "arraya
ic
function getData(): array; }"
Which is basically my objection to __toArray() - I can't think of many
situations where writing (array)$foo saves or gains you anything over
writing $foo->asArray() or $foo->somethingMoreSpecific()
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"strongly opposed". If the feature was added, I would simply ignore it, and
probably argue against its use in code review and style guides.
However, other people have pointed out that unlike (string)$object,
(array)$object does have a default behaviour, and adding an overload for it
has the potential to break code relying on that. So it's not an entirely
zero-cost feature.
Regards,
--
Rowan Tommins
[IMSoP]
e guarantee that if
> function_exists($object,'__toArray') is true that casting to (array)
> would be valid.
>
>
Which brings us back to square one: knowing that a method returns an array
isn't enough; I need to know what kind of array that is, and the thing that
normally tells me that is the method's name.
Regards,
--
Rowan Tommins
[IMSoP]
re some languages which write it that way around), but that should be a
separate feature, where you could also write this:
doSomething(
$foo,
'weekend',
[ 'blah => 42, 'bob' => 'smith' ],
moreStuff()
) => $say;
Regards,
--
Rowan Tommins
[IMSoP]
d'] ) {
$user = getUser($_GET['id']):
}
else {
echo "Invalid ID provided";
}
Which would be equivalent (given a type hint on getUser() and no
strict_types declaration) to this, but without needing to use exceptions
as flow control:
try {
getUser($_GET['id']);
}
catch ( TypeError $e )
g null-coalesce operator?
$user = $application->getUser() ?? $this->getUser();
// or if the precedence is the other way around:
$user = $this->getUser() ?? $application->getUser();
Regards,
--
Rowan Tommins
[IMSoP]
peat the expression each time, as you would
with an "anti-coalesce", "null-safe chain" feels a clearer reading of the
intent here than "if not unset".
Regards,
--
Rowan Tommins
[IMSoP]
e that
the deprecated features were "the wrong way". If the engine had to
support the feature anyway, I'm not sure what the advantage would be of
tying it to "compiled vs non-compiled", rather than opting in via a
declare() statement or package config.
Regards,
--
Rowan Tomm
old:
>
> 1. Backward compatibility
>
> 2. Allowing PHP to continue to meet the needs of new/less-skilled
> programmers and/or people who want a more productive language for smaller
> projects that do not need or want all the enterprisey type-safe features.
>
>
Both of these are reasons to have some sort of "strict mode", but not for
tying it to some other feature.
Regards,
--
Rowan Tommins
[IMSoP]
and
switch ($x) {
case 1: break;
}
In general, I really like this idea; I've always wished switch worked this
way.
Regards,
--
Rowan Tommins
[IMSoP]
match ( $user->getScore() < $$ ) {
0, default => foo(),
10 => bar(),
100 => baz()
}
Regards,
--
Rowan Tommins
[IMSoP]
;
>
> $user = getUser($id):
>
> }
>
>
I'm not sure what the point of this example is. You've just cast to int, so
the assertion can never fail, and if getUser has a type hint, it's about to
make that assertion anyway.
Regards,
--
Rowan Tommins
[IMSoP]
suggesting here, but I'm pretty
sure it conflicts with existing uses of commas, so shouldn't constrain us
from using them elsewhere.
foo(1,2,3);
foo($var = 1,2,3);
$a = [0, $var = 1,2,3];
// etc
Regards,
--
Rowan Tommins
[IMSoP]
run-time will be better than flagging a Warning and returning a defined
value?"
Regards,
--
Rowan Tommins
[IMSoP]
e, not as a general rule that all
Warnings should be promoted.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
report the
result without ever triggering an exception". That's the point of
designing a new API, to work out what the use cases are, and cater for
them in a clean way.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
could be achieved is using a "tuple" declaration, like in Hack:
https://docs.hhvm.com/hack/built-in-types/tuples
In general, grouping things with commas and no parentheses is always
going to *look* ambiguous IMO, even if you can limit where it's used to
not be *technically* ambiguou
y
force you to specify class/interface names: you should catch only the
exceptions you actually know how to handle in that particular piece of code.
Regards,
--
Rowan Tommins
[IMSoP]
passed, either on each zval or perhaps just at the class level, so that
checking the same type again would be much faster, even if it was a complex
union with multiple interfaces.
Regards,
--
Rowan Tommins
[IMSoP]
rt-hand form becomes a kind of double negative - "if this is
not set, don't do this", or "if this is not not set, do this":
$_SERVER['fname'] !?? $user->setName($_SERVER['fname']);
That makes me think that the choice of syntax isn't quite right, but I'm
not sure what
to maximise the
compatibility between the two, and share as much implementation as
possible. Both/all modes should get the same performance improvements,
except where the actual features are necessarily slower or faster.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
store multiple related classes in the same file.
Yes, I think moving from auto-loading to eager loading would make sense
for a lot of projects.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
n
exception would be perfectly fine. It's the commonly used sets of functions
with a variety of different error conditions and use cases, like file
handling, where more careful redesign is prudent.
Regards,
--
Rowan Tommins
[IMSoP]
by OpCache?)
* On versions where the keyword is present but optional, the define is
skipped, and the keyword is a no-op
* On versions (or external tooling) where omitting the keyword is a
warning, or even an error, the keyword indicates intent
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PH
ave a "concrete advantage" over
each one.
Regards,
--
Rowan Tommins
[IMSoP]
owed_html_builder->build());
That doesn't mean the version you wrote is *wrong*, but should make us
consider why one version deserves special treatment by the language and the
other one doesn't.
Regards,
--
Rowan Tommins
[IMSoP]
t; I think I am sensing a pattern in your objections: For you, providing
> benefits in one area is to be avoided unless all areas can receive similar
> benefits?
Almost. It's more that I'm against adding a large number of small features
that each make one use case slightly easier, but don't
andards would
place it at the top of that list, so we're talking about the difference between:
declare(strict_types=1);
namespace Foo;
use global functions;
...
and
declare(strict_types=1);
declare(global_functions=1);
namespace Foo;
...
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ot;use global
functions", is more obviously a one-off.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
rate to, but it would be a
shame if every PHP file in 10 years time included a line like this:
use function *; // don't know what this does, but apparently it's good for
performance ¯\_(ツ)_/¯
Regards,
--
Rowan Tommins
[IMSoP]
ture, so perhaps it should be
something more like:
declare(lookup_functions_in_current_namespace=false);
That would also mean that it can be covered by any future way of setting
language directives, such as settings per "module", bundling into
"editions", etc.
Regards,
--
Rowan Tommins
[IMSoP]
/37c11714
That's great! But ... it is a breaking change, and I can't see any note
in UPGRADING. Is there a running list of the Warnings that have been
promoted to Errors anywhere, and if not, should we create one before we
forget?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals
ed
and which partially-promoted.
Regards,
--
Rowan Tommins
[IMSoP]
l for your efforts!
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ore fundamental reason, though.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 13 Feb 2020 at 12:04, Manuel Canga wrote:
>
>
> On Thu, 13 Feb 2020 at 08:58, Rowan Tommins
> wrote:
>
>> On 12 February 2020 23:12:34 GMT+00:00, Manuel Canga <
>> manuelca...@gmail.com> wrote:
>> >El mié., 12 feb. 2020 23:01, Rowan Tommins
ke the syntax for closures simpler by
skipping the "get name" step and making foo::fn return a closure straight
away.
So the question is, are there use cases that fall into category (b)?
Regards,
--
Rowan Tommins
[IMSoP]
x wouldn't allow us to remove __get and __set, but would
mean fewer cases where people needed to deal with them.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t it's at least worth exploring
some possible futures, and how decisions now might help or hinder them.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hat self-contained state, and "everything from global
state" or "nothing from global state" seem like more natural options
than "one thing from global state, everything else not".
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
r);
}
In general, it feels like it would be useful for generators that knew
it was going to happen, but a foot-gun for generators that weren't
expecting it, so I like Judah's suggestion of an opt-in mechanism of
some sort.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
with any of the other properties (e.g. populating $post
and $uploads based on form data), could "better syntax for getting raw
request for global state" be a separate feature. Then again, maybe the
ability to over-ride it in the constructor is enough to make it useful.
Regards,
--
Rowan Tommins
[IMSoP]
y default, which seems consistent with the aim of matching
existing behaviour.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on what is and isn't proposed.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
somewhere as
a kind of appendix to show where the current design came from?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
laces in their code to check, but they'd
still need to manually track which they'd already looked at, so I'm
not sure how useful it would be.
What I will look into is how well static analysis tools such as
PHPStan and Psalm could build a similar list, as I think that's
generally a more useful approach.
.
I am less precious about the changes to boolean, which is why I propose
three separate votes. I would be open to an alternative RFC removing all
implicit casts on boolean, object, and resource; but unless and until
undefined variable behaviour changes, null is necessarily a special case.
Regards,
--
Rowan Tommins
[IMSoP]
at the BC break is too great, even in the null decrement
case, feel free to vote No, and keep the current WTF in the language.
Regards,
--
Rowan Tommins
[IMSoP]
and >> in C++ has been mentioned several
times). If that's the case, then an interface that prevents you
implementing DateTime - DateTime seems perfectly legitimate.
Regards,
--
Rowan Tommins
[IMSoP]
he user
to at least consider
Regards,
--
Rowan Tommins
[IMSoP]
tent);
return [ 'input' => $request->input, 'uploads' => $request->uploads ];
}
The only downside I can see to adding it is complexity of implementation.
But that's at best a reason to say "we'll hope to add this later" rather
than "it would be better not to add it".
Regards,
--
Rowan Tommins
[IMSoP]
ted in a slightly different place, or two different
places, or whatever.
Regards,
--
Rowan Tommins
[IMSoP]
On Thu, 27 Feb 2020 at 17:06, Paul M. Jones wrote:
> Hi Rowan,
>
> > On Feb 27, 2020, at 10:57, Rowan Tommins
> wrote:
> >
> > you seem to be happy to just put it out there and see
>
> Perhaps it was not your intent, but even so: please don't put words in my
s mb_convert_encoding() doesn't have the same penalty. It seems
quite plausible that a library dedicated to converting charsets would be
more optimised for that job than a single function in a larger library
mainly focussed on working with one charset at a time.
Regards,
--
Rowan Tommins
[IMSoP]
l
of it copy-and-pasted boilerplate that's hard to spot mistakes in.
It's also impossible to use with inheritance, or to compose with traits (as
Diactoros does, for instance), because every with* method needs to know the
full details of how to create a partial clone.
Regards,
--
Rowan Tommins
[IM
written in the constructor, or
within this block
$inst->foo = $other->getFoo();
};
// object is "finalised" when the block ends
return $inst;
}
Regards,
--
Rowan Tommins
[IMSoP]
y
Percentage / Money => Error
Optionally, on class Percentage:
Percentage + Percentage => Percentage
Percentage - Percentage => Percentage
Percentage* int => Percentage
Percentage / int => Percentage
Regards,
--
Rowan Tommins
[IMSoP]
1 - 100 of 1043 matches
Mail list logo
