tion syntax creates a Closure object.
There may be other parts I've not mentioned, but hopefully this illustrates the
idea that "a native decimal type" doesn't have to be one all-or-nothing project.
Regards,
Rowan Tommins
[IMSoP]
to cast
a Yes vote myself.
Regards,
--
Rowan Tommins
[IMSoP]
re of what it might be.
Regards,
Rowan Tommins
[IMSoP]
On 25 April 2024 22:01:35 BST, Mike Schinkel wrote:
>> On Apr 25, 2024, at 11:28 AM, Rowan Tommins [IMSoP]
>> wrote:
>> If the project has no clear deprecation policy, the information is useless
>> anyway.
>
>Not true.
>
>Having standardized notation
guess I'm in the minority.
Naming it "version" would just make it less clear, and not resolve
anything from my point of view.
Regards,
--
Rowan Tommins
[IMSoP]
pics require
> discussion and are thus better suited for textual
> documentation.
The JetBrains attribute *does* include a "replacement" argument, but it's
heavily tied into a specific use case: it contains a template used for code
transformation in the IDE. Both it and "since" are explicitly marked
"applicable only for PhpStorm stubs".
Regards,
Rowan Tommins
[IMSoP]
properties" as just an optimisation: the engine doesn't allocate a property it
knows will never be accessed, and accesses to it, e.g. via reflection, just
return "uninitialized".
I am however conscious that RFCs have failed in the past for being "not
complete enough" as well as for being "too complex".
Regards,
Rowan Tommins
[IMSoP]
e reasons
to keep the division and rounding separate.)
Regards,
--
Rowan Tommins
[IMSoP]
to
add, but not one that should be on by default, given we're not writing the
extension from scratch.
Regards,
Rowan Tommins
[IMSoP]
ndToPrecision() and
roundToScale(), but as Jordan explained, an implementation which
actually calculated precision could be difficult and slow.
Regards,
--
Rowan Tommins
[IMSoP]
If Ilija's "data classes" proposal progresses, you'll be
able to have copy-on-write for free as well.
Regards,
Rowan Tommins
[IMSoP]
where, and
userland libraries spend a lot of effort polyfilling things which would
ideally be available by default.
This is, essentially, the thesis of the research and work that I have
done in the space since joining the internals mailing list.
Thanks, there's some really useful perspective there.
Regards,
--
Rowan Tommins
[IMSoP]
ttps://github.com/php/php-src/blob/master/Zend/zend_strtod.c
Regards,
--
Rowan Tommins
[IMSoP]
oes every number value have?" I don't
think "rounding mode" would be on that list, so I don't think it belongs on a
class called Number.
Regards,
Rowan Tommins
[IMSoP]
.
So, again, I urge you to forget about it being easy to stick an extra property
on an object, and think in the abstract: does it make sense to say "this number
has a preferred rounding mode", rather than "this operation has a preferred
rounding mode".
Regards,
Rowan Tommins
[IMSoP]
ould handle both use cases?
Regards,
--
Rowan Tommins
[IMSoP]
l2.
So I see it just as an API design decision: do we specify the rounding
mode of numeric division a) on every operation; b) on every value; c) in
a runtime setting (ini_set); d) in a lexically scoped setting (declare)?
My vote is for (a), maybe with (d) as a fallback.
Regards,
--
Rowan Tommins
[IMSoP]
ing extra properties to it is
easy, but I don't think it actually makes it easy to use.
Regards,
--
Rowan Tommins
[IMSoP]
want to benefit from *both*
of your efforts. It really doesn't matter to me how many mailing list threads
that requires, as long as there aren't two teams making conflicting designs for
the same feature.
Regards,
Rowan Tommins
[IMSoP]
requested for custom array-like types).
In other words, looking at how the efforts overlap doesn't have to mean
abandoning one of them, it can mean finding how one can benefit the other.
Regards,
Rowan Tommins
[IMSoP]
h users and the people volunteering their effort, to whom I
am extremely grateful.
Regards,
Rowan Tommins
[IMSoP]
is clearly wrong.
The fundamental problem is that it ignores the OOP concept of
encapsulation: how an object stores its internal state should not define
its behaviour. Instead, the object should be able to directly define
behaviour for the operations it supports.
Regards,
--
Rowan Tommins
[IMSoP]
ause the Money
class can expose only the methods that actually have useful and safe behaviour.
The fact that the composed class can't add its own operator overloads is
unfortunate; but allowing inheritance wouldn't solve that, because the
inherited overloads are all wrong anyway.
Regards,
Rowan Tommins
[IMSoP]
, int|decimal $divisor, RoundingMode
$roundingMode). How you implement "decimal" doesn't change that at all.
Regards,
--
Rowan Tommins
[IMSoP]
; behaviour,
which might or might not be a good idea.
This is mostly just a thought experiment, but I am a bit concerned that
code like this is going to be confusingly ambiguous:
$item->shape->position->zero!();
What is going to be CoW cloned, and what is going to be modified in
place? I can't actually know without knowing the definition behind both
$item and $item->shape. It might even vary depending on input.
Regards,
--
Rowan Tommins
[IMSoP]
ssibly, it would just be an error to perform division on a fixed
scale decimal, but allowed on a variable-fixed scale decimal.
Regards,
--
Rowan Tommins
[IMSoP]
d simply be made
for us: they would just be objects, with all the same behaviour around
inheritance, serialization, and so on.
Regards,
--
Rowan Tommins
[IMSoP]
measure is; it's
always about reducing the attack surface or limiting the damage.
Regards,
--
Rowan Tommins
[IMSoP]
ot the integrity of the entire repository.
Regards,
--
Rowan Tommins
[IMSoP]
ussed: https://externals.io/message/113838#113840 and a
user guide was created on the PHP wiki: https://wiki.php.net/vcs/commit-signing
Feedback for the idea was generally positive, but maybe nobody got around to
actually doing it.
--
Rowan Tommins
[IMSoP]
ther out: https://3v4l.org/5HlPE https://3v4l.org/LBALm
If both are defined, which should it call? And if you wanted the other,
how would you specify that? We would need some new syntax to remove the
ambiguity.
Regards,
--
Rowan Tommins
[IMSoP]
eason you're getting negative feedback: to
you, the feature seems like an obvious extension, even a bug fix; but to
others, it seems like a complete change to how static calls are interpreted.
Regards,
--
Rowan Tommins
[IMSoP]
s, it can be flagged automatically.
Regards,
--
Rowan Tommins
[IMSoP]
//www.php.net/manual/en/ref.mbstring.php
So... if you want to help make people more aware of the grapheme_*
functions, one place to start would be editing the documentation for the
various string, mbstring, and grapheme functions to use consistent
terminology, and sign-post each other more clearly.
http://doc.php.net/tutorial/
Regards,
--
Rowan Tommins
[IMSoP]
uno', ' - dos']);
Which of course extends to more complex cases:
$foo = array_map(fn($english, $spanish) => "'$english' en Español es
'$spanish'", ['one', 'two'], ['uno', 'dos']);
$foo = array_map(fn($english, $spanish, $german) => "$english - $spanish
- $german", ['one', 'two'], ['uno', 'dos'], ['ein', 'zwei']);
https://3v4l.org/d55kT
So, I'm not opposed to the change, but its value seems marginal.
Regards,
--
Rowan Tommins
[IMSoP]
On Fri, 22 Mar 2024, at 17:38, Claude Pache wrote:
>
>> Le 22 mars 2024 à 16:18, Rowan Tommins [IMSoP] a
>> écrit :
>>
>> $optionalExpiryDateTime = $expiry as ?DateTimeInterface else
>> some_other_function($expiry);
>> assert($optionalExpiryDateTime
sented to me in a code review, I'd probably just write "WTF?!"
I have no idea looking at that what type I can assume for
$optionalExpiryDateTime after that line, which was surely the whole point of
using "as" in the first place?
Regards,
--
Rowan Tommins
[IMSoP]
expected
$x = $a as DateTime|string else 'No date given'; // OK
$x = $a as DateTime else null; // TypeError: null given, DateTime expected
$x = $a as ?DateTime else null; // OK
If the statement runs without error, $x is guaranteed to be of the type (or
pattern) given to the "as" operator.
Regards,
--
Rowan Tommins
[IMSoP]
ring( $name );
etc
And once you have that, you don't need anything special for the null case, it's
just:
$nameString = $name as ?string else null;
Regards,
--
Rowan Tommins
[IMSoP]
n some type checking contexts would be fine
(although mostly they're pointless, rather than harmful). Disallowing or
repurposing null would mean you have an incomplete type system, because there
is no other type to match a null value against.
Regards,
Rowan Tommins
[IMSoP]
sible values "true" and "false"; and null, which
has a single possible value "null".
So there are 2**64 + 2 + 1 possible values that meet the constraint, and
nothing to specify that one of those is my preferred default if given
something unexpected.
Regards,
--
Rowan Tommins
[IMSoP]
$x) { var_dump($x); }
foo($a);
Which is null if $a is null, and a TypeError if $a is anything else:
https://3v4l.org/5UR5A
Regards,
--
Rowan Tommins
[IMSoP]
fallback is not evaluated
Probably, it should then be an error if the fallback value doesn't meet the
constraint:
$bar = new Bar;
$bar as Foo else null; // error: fallback value null is not of type Foo
$bar as ?Foo else 42; // error: fallback value 42 is not of type ?Foo
Regards,
--
Rowan Tommins
[IMSoP]
t; that should be separate from
the syntax for a nullable type.
Regards,
Rowan Tommins
[IMSoP]
ns we
*could* support, so choosing a minimal set is hard.
Regards,
--
Rowan Tommins
[IMSoP]
of avoiding declare() directives is not to
replace them with something else, but to choose a design where nobody
feels the need for them.
Regards,
--
Rowan Tommins
[IMSoP]
plugins sometimes have a base implementation used for multiple
programming languages, and PHP might be the only one that needed this
extra tracking.
Regards,
--
Rowan Tommins
[IMSoP]
ps://docs.python.org/3/library/collections.html#collections.defaultdict
Over all, I think this is a really great proposal, and hope it proceeds
smoothly.
Regards,
--
Rowan Tommins
[IMSoP]
uch
properties? will we be prevented from adding some optimisation to
OpCache because these properties break some otherwise safe assumption?
Maybe I'm being over-cautious, but those are the kinds of questions I
would expect to come up if this feature had its own RFC.
Regards,
--
Rowan Tommins
[IMSoP]
ked.
Regards,
--
Rowan Tommins
[IMSoP]
sed
me. It feels to me like something that will seem surprising to people when they
first encounter it, but useful once they understand the implications.
Regards,
Rowan Tommins
[IMSoP]
On 15 March 2024 17:11:29 GMT, Larry Garfield wrote:
>On Wed, Mar 13, 2024, at 10:26 PM, Rowan Tommins [IMSoP] wrote:
>> I think it would be more helpful to justify this design on its own
>> merits, particularly because it's a significant difference from other
>> la
v4l.org/3Gnti/rfc#vrfc.property-hooks
Awesome! The RFC should probably highlight this, as it gives a
significant extra option for array properties.
(Also, good to know 3v4l has a copy of the branch; I hadn't thought to
check.)
Regards,
--
Rowan Tommins
[IMSoP]
ture. But if we add it now and regret it, or some detail of its
implementation, we will be stuck with it forever.
Regards,
--
Rowan Tommins
[IMSoP]
etation, it became much more intuitive to call that
magic variable by a magic name like $field; than to re-use the syntax that
would normally refer to the property, and make it sometimes reference this new
thing instead.
To re-iterate an earlier point, though, I think the language should choose.
There should be exactly one way to refer to the backing field, whether that's
$this->foo, $field, or get_backing_field(). Don't leave users reading each
other's code and not being sure if it's doing the same thing.
Regards,
--
Rowan Tommins
[IMSoP]
/wiki.php.net/rfc/property-hooks/imsop-suggestion
Regards,
--
Rowan Tommins
[IMSoP]
This is a test e-mail from a subscribed GMail address, to see if the
"451: Temporary lookup failure" errors are now resolved.
Thanks to those working on it!
--
Rowan Tommins
[IMSoP]
coroutine.
> The yield is much more intuitive than magic fields
I think we'll just have to differ in opinion on that one. Maybe you're just
more used to working with coroutines than I am.
Note that yield also doesn't solve how to read the current backing value in a
get hook (or a set hook that wants to compare before and after), so we still
need some way to refer to it.
Regards,
Rowan Tommins
[IMSoP]
plus:
$this->name = $this->_name_set($value);
With "yield", I can't picture that simple translation; the "magic" is
whatever translates the "yield" keyword into "$this->name ="
I would file it with the type widening in the RFC: seems kind of cool,
but probably isn't worth the added complexity.
Regards,
--
Rowan Tommins
[IMSoP]
t the short form
meaning "the value returned is saved to the backing field" is both more
expected and more useful.
The "yield" idea is ... interesting. I think personally I find it a bit
too magic, and too cryptic to be more readable than an explicit
assignment. Opinions may vary, though.
Regards,
--
Rowan Tommins
[IMSoP]
cribed, I believe: via the web form, or using
+unsubscribe in the to address.
Regards,
--
Rowan Tommins
[IMSoP]
value); }
set => $this->phone = $this->santizePhone($value);
It also feels weird to say both "the right-hand side must be a valid
expression" and "the value of the expression is ignored".
So I think making the short-hand be "expression to assign to the implicit
backing field" makes a lot more sense.
Regards,
--
Rowan Tommins
[IMSoP]
:
public string $name { set => throw new Exception('Read-only property ' .
__PROPERTY__ } // implied default getter and backing field
public virtual string $name { get => $this->firstName . ' ' .
$this->lastName; } // setter disabled because property is declared
virtual
I think there's some really great functionality in the RFC, and would
love for it to succeed in some form, but I think it would benefit from
removing some of the "magic".
Regards,
--
Rowan Tommins
[IMSoP]
efine what goes in each, and harder to do
half-way. My gut feeling is that it would descend into a lot of bikeshedding,
and stop us making progress; whereas adding a few methods for common use cases
could present a real quick win.
Regards,
--
Rowan Tommins
[IMSoP]
etting for such a basic feature in the first place.
Regards,
--
Rowan Tommins
[IMSoP]
On 16 February 2024 16:09:32 GMT, Rowan Tommins wrote:
>public function executeAndReturn(): string
>public function executeAndOutput(): void
I guess I missed:
public function executeToFile(Stream $fileHandle): void
public function executeWithCallback(callable $wrIteFunction): void
which
ur.
Regards,
--
Rowan Tommins
[IMSoP]
they were declared as nullable types; and the fix
for the proposed deprecation would be to do so:
?int $foo = null
int|string|null $foo = null
The fact that the feature is tricky to explain is a good reason to deprecate
it, and I think I support the proposal unless I see a good argument against.
values" syntax, as in:
$arr = [1,2,3,4,5];
[$first, $second, ...$rest] = $arr;
It couldn't work as the exact inverse of construction, though; this is allowed:
$arr1 = [1, 2, 3];
$arr2 = [...$arr1, ...$arr1];
But this wouldn't make any sense:
$arr2 = [1, 2, 3, 1, 2, 3];
[...$arr1, ...$ar
];
https://3v4l.org/Uu5e4
The name for this if you want to find more information is "array destructuring".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e an eye on the future, not just the past.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e us a much more flexible system,
not weeks of complex engineering.
If the proposal is "copy some code from FrankenPHP into php-src, which nobody
else will want to use", it's pointless; if it's "standardise an API with some
enabling code", then *of course* we want to
or ourselves when we do get there.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
's essential for
any kind of concurrent run-time (async, thread-aware, etc).
Regards,
--
Rowan Tommins
[IMSoP]
AMPHP)
feels like a big missed opportunity.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
p somewhat resembling functional programming:
everything you want to have side effects on needs to be passed around as
parameters and return values, because the only thing isolated between requests
is local variable scope.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Developme
rds compatibility" is overly generous: the OP
gave Swoole as an example of an existing worker environment, but I can't see
any way that Swoole could implement an API that communicated request and
response information via global state.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP I
.dev/docs/worker/#custom-apps So really all I'm arguing is
that a few more lines of that PHP example be moved into the C implementation,
so that the user only needs to provide that inner callable, not the outer while
loop.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Dev
On 29/12/2023 21:14, Kévin Dunglas wrote:
On Fri, Dec 29, 2023 at 8:14 PM Rowan Tommins
wrote:
- FrankenPHP expects the user to manage the main event loop ...
This isn't exact. FrankenPHP does manage the event loop (the Go
runtime manages it - through a channel - under the hood
ptical how many SAPIs would actually implement it,
rather than providing more powerful APIs.
Regards,
--
Rowan Tommins
[IMSoP]
ect objects as part of the backtrace
information. Such a class could iterate its contained objects, checking if they
are unserializable classes, or classes which should recursively be asked if the
instance is serializable.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Devel
from purely legal or financial links.
[1] https://wiki.php.net/rfc/php_technical_committee
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
to do something
similar natively, creating an equivalent of
WrappedCallable('i_dont_exist') using the first-class callable syntax:
function test(callable $f = i_dont_exist(...)) {
echo $f('hello');
}
Regards,
--
Rowan Tommins
[IMSoP]
public constructor.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ument for function autoloading; the argument for static classes needs to
be either:
- "admit it, we're never going to get function autoloading";
- or "I'd want this even if we had function autoloading" (in which case the
discussion of require vs autoloading becomes irrelevant).
Regards,
--
Rowan Tommins
[IMSoP]
ather
than a distraction of "Composer vs something else".
Regards,
--
Rowan Tommins
[IMSoP]
e. Maybe we need a new function or operator to
atomically break the reference and assign a new value, e.g.
unreference($this->foo, 42); or $this->foo := 42; to replace
unset($this->foo); $this->foo=42;
Regards,
--
Rowan Tommins
[IMSoP]
kage / module config - *for example* Composer has a "files" array
in each package's "autoload" config.
So the actual assumption is "surely you must be using OpCache", which
unlike Composer is bundled with PHP.
Regards,
--
Rowan Tommins
[IMSoP]
m, which is that they didn't expect to *ever* have a
call to __get for that property.
But I guess I'm 4 years too late to make that case.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ce of changing it to just:
> Typed properties start off as uninitialized.
>
> Once you've assigned a value, you can't go back to the original uninitialized
> state using unset()
>
> Accessing an uninitialized property will first check for __get, and throw an
> error if that is
On 21/11/2023 12:14, Derick Rethans wrote:
I have fixed this now.
It turned out to be a bug in *bugs.php.net*, which I had fixed
yesterday...
Wow, that was an unexpected chain of dependencies! Thanks for tracking
it down. :)
Regards,
--
Rowan Tommins
[IMSoP]
On 16/11/2023 20:41, Rowan Tommins wrote:
Hi all,
I have finally written up an RFC I have been considering for some
time: Harmonise "untyped" and "typed" properties
RFC URL: https://wiki.php.net/rfc/mixed_vs_untyped_properties
I've revised the RFC; it now proposes
knows which
service might need prodding to bring it back to life?
Regards,
--
Rowan Tommins
[IMSoP]
why* the situation has
changed, or *why* the arguments were not sufficiently considered in the first
place.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
p with a
justification that addresses the points raised previously, and follow the
process here: https://wiki.php.net/rfc/howto
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
loading
support for such functions, and that's a whole different problem...
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
FC, at least to consider.
The RFC to add "mixed" gives an example of removing the type as invariance, but
doesn't seem to justify why "untyped" and "mixed" should be considered
different, from a type system point of view.
https://wiki.php.net/rfc/mixed_type_v2
R
e we didn't even manage to remove "var" in favour of
"public", but I wanted to say it for completeness.
Maybe someone can come up with some other variation or compromise?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ent an initial draft to start the discussion, because the current
behaviour is quite hard to explain in a short e-mail.
Please let me know your thoughts.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e what's really needed is to draft a new copy of the policy document,
updating or removing those parts that are no longer relevant, and adding a
timeline for the pre-release phases?
Or possibly there's a different document I should be looking at, and the RFC
could contain proposed edits to that?
1 - 100 of 1035 matches
Mail list logo
