IMHO short tag removal has one major thing going for it, consistency,
and by extension, predictability.
That's it.
Is that enough? I'm on the fence.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
isn't it about time that an spl_autoload_list was
added that accepted the standard composer classmap [class_id => path]
and forewent most autoload callbacks entirely?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
cal directories. Sounds like a
job for composer tbh so userland workload would be limited for projects
using modern workflows.
This would of course be dependent on if the compiler stage has the
ability to branch off and call an autoloader the first time it
encounters the import_declares.
Ju
X.
Certainly not a catch-all situation, but might present an opportunity
for doing some of the leg work automatically.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 23/07/2019 10:00, Derick Rethans wrote:
DOs:
- Test test test test
- Tell your friends and collegues to test with their apps and projects
- Oh yeah: test!
Derick, congratulations on your RM role, however, for your personal
well-being, I feel obliged to ask if you have recently experienced a
leaky code.
If short tags are to be removed, V2 is a significantly more reasonable
way of going about it.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
stretching the bounds of reasonableness too far
to suggest the creation of a dedicated page on php.net that contains a
description, a link to csfixer etc, and then that link be included in
the depreciation message itself.
--
Mark Randall
On 23/07/2019 18:54, G. P. B. wrote:
Hello intern
On 20/06/2019 22:19, Rowan Collins wrote:
On 20/06/2019 16:36, Mark Randall wrote:
"Hello".substr(1) // would work as expected regardless of encoding
As I always point out when "multi-byte support" or "Unicode support" is
discussed, it's often ambiguous j
r the web?
function x(utf8_string $x): utf8_string { ... }
These are all just questions I have no answer to or firm opinion on, but
I would be interested to know people's general ideas as to solutions.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ke descriptions or unions with different requirements for each type.
Well-docblock'd stubs, C definitions, documentation pages etc would then
be the drawn from the JSON rather than the other way.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
}
return -1;
};
$x and $y would be captured, $z would not be. I believe this is how
short closures are implemented, but is at present only supporting a
single line.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
IMHO would provide best-of-both-worlds.
The benefits of public key vs a symmetric key are that the logs remain
secure even with read access to php.ini.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
0;
$y = 1;
$closure = function() use (...) {
};
Where "use (...)" would auto-capture all of the used variables in a
similar manner to short closures, that would certainly save a bit of time.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
eing able to tell the difference would have at least some
useful applications.
Clearly there's ways around that using the current, more verbose method,
but it would be nice if a way could be found so that this potential
ambiguity wasn't there in the first place if this new mechani
gt; null;
I know this is a huge tangent, I just wanted to throw it out there as a
possible option for handling chaining, that would potentially kill many
more birds down the road in the process.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tion errors.
4. Leave the existing functions as-is, finally claim the \php namespace,
alias all of the internal functions into it, and make their default,
unchangeable behaviour be to throw a RuntimeException on error.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To uns
#x27;, MyObject::class ];
}
}
Eh, my suggestion is probably a terrible ideal.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
rd
his proposals as an RFC with all due haste, as it's quite clear the
current plan cannot go forward as-is.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eir entire
codebase against each one. But we all know that's not how the real world
works.
For all those reasons, I am in favour of your proposal to fail-safe with
a compiler error.
(Also: Did I miss a vote option which would have made short_open_tags
always on?)
--
Mark Randall
--
PHP
s *significant*.
Until someone can convince me otherwise, I will continue to strongly
believe that foreseeable future (years).
I'm half tempted to RFC it so it can go to a vote.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ary of would be if you were
computer-generating code, as it would not pick up literals.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t holds no weight with me.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 23/04/2019 14:39, Mark Randall wrote:
It keeps coming back to the feature we've all been praying to the PHP
Gods for... generics.
Replying to myself (sorry).
I just wanted to point out that the same syntax would also solve your
other issue from the nullable casts thread:
function
$obj;
}
throw new InvalidArgumentException('Cast expected ' . T);
}
$x = cast($obj);
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ll replace it as the recommended
inbuilt method that handles strings with whitespace and trailing junk?
Will there be one?
I'm aware that the most common IDEs suggest using (int) instead of intval.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
of whether it
passes or fails, you should both be holding your heads high that you've
made the effort.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on
and returns null. Otherwise moves on to next option and casts it to an
integer.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tems');
}
$value = (?string)$_GET['name'] ?? '';
if ($value === '') {
// also, ?name[]= can sod off
throw new Exception('You must provide a name');
}
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ll
I don't think it would go down very well to have non-nullable casts
throwing TypeErrors for common cases, without an elegant
could-not-convert fallback that doesn't require a 5 line try-catch block.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
hen prints `int(1)`
In the absense of a nullable modifier, that makes so little sense that
it definitely needs to throw a TypeError IMO.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e ?? $default.
Equally I see a lot of use in the following to nullify unexpected inputs
such as if $_GET['something'] was an array:
$input = (?string)$_GET['input'] ?? '';
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
out, it would allow:
$output = (?int)$input ?? $default;
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
set of independent scripts.
If this doesn't pass, long term I think the main alternative would be to
have a single statement that was like a quasi-include of declarations in
another file, almost like a ".h"
declare_import('/my/namespace/nsprefs.php');
--
Mark Randal
al = &$t1[1];
$val = 1;
-> [ 'hello', 1]
I did take a look in zend_types.h half expecting to see a pointer to an
optional structure defining an indirect function call + argument to be
called whenever the zval_value was about to be changed, but if it's in
there, I mis
n generics,
casting operators, and overloaded function constructors...
... and yes, that did include almost every major language wishlist item
in a single go. Chalk it up to me romancing my long lost love of C++.
Thanks.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
3');
chain(
'Random String',
func_1($1, 'Hello', 'World'),
func_2($1, 'Peace', 'Out'),
func_3('ThisOneNeeds', 'Arg3ReplacingInstead', $1),
func_3($1, $1, 'HowAboutOneWhichUsesTheSameArgumentTwice')
);
7;Hello', 'World'),
func_2($1, 'Peace', 'Out'),
func_3('ThisOneNeeds', 'Arg3ReplacingInstead', $1),
func_3($1, $1, 'HowAboutOneWhichUsesTheSameArgumentTwice')
);
function chain($start, ... $fns) {
foreach ($fns as $fncall) {
$start = $fncall($start);
}
return $start;
}
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
201 - 237 of 237 matches
Mail list logo
