Re: [PHP-DEV] FFI in PHAR files
Ah, that makes total sense. I was worried I was doing something very wrong. haha Thank you very much for the detailed clarification. This doesn't seem to be a "critical" feature, but I wonder if the documentation shouldn't mention something about only "regular files" being supported. Vinicius Dias, Zend Certified Engineer, iMasters PHP Certified Professional Vinicius Dias, Zend Certified Engineer, iMasters PHP Certified Professional Em sex., 8 de set. de 2023 às 16:55, Bishop Bettini escreveu: > > On Fri, Sep 8, 2023 at 2:33 PM Vinicius Dias wrote: >> >> I was playing around with some libraries using FFI and I wanted to >> share a .phar with the result, but to my surprise, it didn't work. >> >> Apparently we are not able to load shared libraries using FFI from >> within .phar files. >> Is that the expected behavior or is it a bug in the FFI extension? >> >> I have setup a dummy repo so the error could be easily reproduced: >> https://github.com/CViniciusSDias/ffi-phar-problem >> >> I am sorry if this is not the list to send this type of problem. I >> will gladly move the thread to the right one if someone points it out. >> https://www.php.net/unsub.php > > > Erstwhile PHAR extension maintainer here. What an interesting question! The > short answer is no, FFI does not support loading dynamic libraries contained > within a PHAR archive. > > The longer answer is that FFI was not written to be able to support VFS > locations, including the phar:// scheme. In this case, PHP starts and invokes > the code. The code invokes FFI[1] with a phar:// path, which then tries to > perform a dlopen()[2], which fails because dlopen has no idea how to resolve > PHAR paths: dlopen() expects a path that the OS can resolve[3]. > > I suppose it'd be possible to improve FFI to call the PHP VFS layer to > resolve a path, which would handle the phar:// scheme and other schemes. But, > I would be worried about potential other downstream impacts - esp. security > implications - as this is a novel (to me at least) scenario. > > bishop > > [1]:https://github.com/php/php-src/blob/50ca24251d97dbf78b0c1165dac7c1a19ff1c87a/ext/ffi/ffi.c#L2968C3-L2968C3 > [2]:https://github.com/php/php-src/blob/50ca24251d97dbf78b0c1165dac7c1a19ff1c87a/Zend/zend_portability.h#L156 > [3]:https://man7.org/linux/man-pages/man3/dlopen.3.html > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
On Fri, Sep 8, 2023 at 2:12 PM Lanre Waju wrote:
> Dear PHP Internals,
>
> I am writing to propose a new feature for PHP that introduces the
> concept of structs. This feature aims to provide a more concise and
> expressive way to define and work with immutable data structures. Below
> is a detailed description of the proposed syntax, usage, and behavior.
>
> Syntax
>
> struct Data
> {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }
> The Data struct is essentially represented as a readonly class with a
> constructor as follows:
>
>
> readonly class Data
> {
> public function __construct(
> public string $title,
> public Status $status,
> public ?DateTimeImmutable $publishedAt = null,
> ) {}
> }
>
These as the most basic examples of what you're proposing are barely
different expressions in length, let alone anything else. I wouldn't say
the first example is particularly more helpful, more readable, more concise
or conceptually more expressive than the second. The rest of your examples
are similarly either very minor savings of a few characters shaved off here
and there, or just as verbose as instantiating a class with a constructor
anyway.
I'm not convinced by the rationale that this would be a new feature
worthwhile for improved expression or concision. I can see a potential
benefit in these "structs" (not sure that's the term//keyword I'd choose,
given it has different meanings in other languages) though, as a kind of
template for properly structured arrays, with a built-in ability to cast
them to arrays or treat them as arrays/iterables. This would potentially
help give some of the power we're missing by not having generics. So it
wouldn't just be equivalent to a shorthand for a readonly class with a
constructor, but one which also satisfied a couple of interfaces with the
implementation automatically provided.
That's my initial reaction/two cents.
-Dave
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
On Fri, 8 Sept 2023 at 14:12, Lanre Waju wrote:
> Dear PHP Internals,
>
> I am writing to propose a new feature for PHP that introduces the
> concept of structs. This feature aims to provide a more concise and
> expressive way to define and work with immutable data structures. Below
> is a detailed description of the proposed syntax, usage, and behavior.
>
> Syntax
>
> struct Data
> {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }
> The Data struct is essentially represented as a readonly class with a
> constructor as follows:
>
>
> readonly class Data
> {
> public function __construct(
> public string $title,
> public Status $status,
> public ?DateTimeImmutable $publishedAt = null,
> ) {}
> }
> Assertions
> The Data struct will always be readonly.
> It has no methods besides the constructor.
> Constructors
> The Data struct can be constructed in three different ways, each of
> which allows for named or positional arguments, which can be mixed:
>
> 1.1 Class like
> $data = new Data('title', Status::PUBLISHED, new DateTimeImmutable());
>
> 1.2 Class like (Named Syntax)
> $data = new Data(title: 'title', status: Status::PUBLISHED, publishedAt:
> new DateTimeImmutable());
>
> 2.1 Proposed struct initialization syntax (Positional Arguments)
> $data = Data{'title', Status::PUBLISHED, new DateTimeImmutable()};
>
> 2.2 Proposed struct initialization syntax (Named Syntax)
> $data = Data{title: 'title', status: Status::PUBLISHED, publishedAt: new
> DateTimeImmutable()};
>
> 3.1 Anonymous Struct (Named Arguments)
>
> $data = struct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }('title', Status::PUBLISHED, new DateTimeImmutable());
> 3.2 Anonymous Struct (Named Arguments - Named Syntax)
>
> $data = struct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }(title: 'title', status: Status::PUBLISHED, publishedAt: new
> DateTimeImmutable());
> Nesting
> The proposed feature also supports nesting of structs. For example:
>
>
> final class HasNestedStruct
> {
> NestedStruct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> };
>
> public function __construct(
> public string $string,
> public Data $normalStruct,
> public NestedStruct $nestedStruct = NestedStruct{'title',
> Status::PUBLISHED, new DateTimeImmutable()},
> public struct InlineNamed { int $x} $inlineNamed = {x: 1},
> public { int $x, int $y} $inlineAnonymous = {x: 1, y: 2},
> ) {}
> }
> This proposal aims to enhance the readability and maintainability of
> code by providing a more concise and expressive way to work with
> immutable data structures in PHP.
> I believe this feature will be a valuable addition to the language as it
> not only opens the door for future enhancements (eg. typed json
> deserialization, etc.), but should also help reduce reliance on arrays
> by providing a more expressive alternative.
>
> Your feedback and suggestions are highly appreciated, and we look
> forward to discussing this proposal further within the PHP internals
> community.
>
> Sincerely
> Lanre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I'm all data only for structures, but I really dont think they should be
readonly.
This type of modifier should be down to the developer to decide.
If a developer only needs a data struct,
they can just `struct {}` but if they need a readonly struct,
they should specify the struct as `readonly struct {}`
Structs can have many uses, you will eliminate 99% of them by forcing
structs to
be readonly. No other languages force this on the developer, PHP shouldn't
either.
This type of limitation would make structs DOA for most developers.
[PHP-DEV] [RFC][Draft] Match block
Hello everyone I've been working on match blocks over the last few weeks. https://wiki.php.net/rfc/match_blocks I've already shared it in R11 and got conflicting feedback, which makes me unsure on how to proceed. We have a few options. 1. Add blocks only to match, possibly adding blocks to other constructs in separate RFCs (the approach of this RFC) 2. Support block expressions as a language-level concept, analogous to https://doc.rust-lang.org/reference/expressions/block-expr.html 3. Do nothing The two main complaints/questions I've gotten was whether this approach is the right one, and whether the syntax can be improved. The RFC tries to go into detail on explaining the rationale for the chosen approach. Additionally, it proposes a few alternate syntax options, although none of them are very satisfactory. At this point I'm unsure whether a proposal can satisfy all camps. Let me know if you have any thoughts/ideas. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
Hi internals! I think it can be useful for structured data obtained from decoding JSONs or from a relational database. However, maybe there is an even better idea, which combines the best of two worlds: the world of your structs RFC, and native PHP arrays - something like "array shapes". For instance, taking the syntax from your proposed RFC (but perhaps the keyword changed to `shape`, or perhaps `array class` to reuse keywords - let's not bikeshed here) to define a shape, and adding a function like `array_shape_coerce($array, $shapeType)` which internally marks an array to be of a defined shape if it matches its definition (throws an exception otherwise, or perhaps returns true/false value or an enum for success/failure) and allows it to be passed where a certain shape type is expected. I think this could be a better approach than pure structs because it leaves all array-based PHP machinery available to such "structs", like `array_map()`, `array_filter()` etc. There is an open question of whether array coerced to shapes can be modified, and if yes, how to react to modifications. Perhaps the easiest solution is to have another function along the lines `array_shape_seal($array, $shapeType)` which not only marks array to be of shape (if the given array matches given shape), but also permits only such modifications which keep the array to be of this shape. And if the regular `array_shape_coerce` is used, then any modifications are permitted, but the array "loses" its shape. Regards, Illia / someniatko
Re: [PHP-DEV] FFI in PHAR files
On Fri, Sep 8, 2023 at 2:33 PM Vinicius Dias wrote: > I was playing around with some libraries using FFI and I wanted to > share a .phar with the result, but to my surprise, it didn't work. > > Apparently we are not able to load shared libraries using FFI from > within .phar files. > Is that the expected behavior or is it a bug in the FFI extension? > > I have setup a dummy repo so the error could be easily reproduced: > https://github.com/CViniciusSDias/ffi-phar-problem > > I am sorry if this is not the list to send this type of problem. I > will gladly move the thread to the right one if someone points it out. > https://www.php.net/unsub.php Erstwhile PHAR extension maintainer here. What an interesting question! The short answer is no, FFI does not support loading dynamic libraries contained within a PHAR archive. The longer answer is that FFI was not written to be able to support VFS locations, including the phar:// scheme. In this case, PHP starts and invokes the code. The code invokes FFI[1] with a phar:// path, which then tries to perform a dlopen()[2], which fails because dlopen has no idea how to resolve PHAR paths: dlopen() expects a path that the OS can resolve[3]. I suppose it'd be possible to improve FFI to call the PHP VFS layer to resolve a path, which would handle the phar:// scheme and other schemes. But, I would be worried about potential other downstream impacts - esp. security implications - as this is a novel (to me at least) scenario. bishop [1]: https://github.com/php/php-src/blob/50ca24251d97dbf78b0c1165dac7c1a19ff1c87a/ext/ffi/ffi.c#L2968C3-L2968C3 [2]: https://github.com/php/php-src/blob/50ca24251d97dbf78b0c1165dac7c1a19ff1c87a/Zend/zend_portability.h#L156 [3]:https://man7.org/linux/man-pages/man3/dlopen.3.html
[PHP-DEV] FFI in PHAR files
I was playing around with some libraries using FFI and I wanted to share a .phar with the result, but to my surprise, it didn't work. Apparently we are not able to load shared libraries using FFI from within .phar files. Is that the expected behavior or is it a bug in the FFI extension? I have setup a dummy repo so the error could be easily reproduced: https://github.com/CViniciusSDias/ffi-phar-problem I am sorry if this is not the list to send this type of problem. I will gladly move the thread to the right one if someone points it out. Thanks, folks. Vinicius Dias, Zend Certified Engineer, iMasters PHP Certified Professional -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Increasing the default BCrypt cost
On Thu, Sep 7, 2023 at 8:26 PM Tim Düsterhus wrote: > Hi > > in response to the recent "PASSWORD_DEFAULT value" thread [1], I've > created an RFC to discuss an increase of the default BCrypt costs for > `password_hash()` from the current value of 10. > > https://wiki.php.net/rfc/bcrypt_cost_2023 > > I think 12 looks reasonable. I've performed some tests myself on private hosted servers with newer hardware with good results for 12 around 0.1 seconds. Can this be integrated into PHP 8.3, as it's not a new feature that can cause problems? Pushing it to 8.4 will delay the real usage with 2-3 more years already. I feel like the hardware performance improvements (specifically single thread performance) slightly increased in the past 3-4 years, and soon most of the hosting providers will be using it. Thank you for looking into this. Having good security configuration by default is important. Regards, Alex
Re: [PHP-DEV] [RFC] [Discussion] Add 4 new rounding modes to round() function
On Thu, Sep 7, 2023 at 11:10 PM Jordan LeDoux wrote: > > As someone who maintains a math library in PHP that has its own expanded > rounding implementation, I will politely disagree. Away from zero, towards > zero, towards positive infinity, and towards negative infinity are > completely and utterly unambiguous and provide the developer with precise > control over what behavior they want. I don't see a reason to use something > that we KNOW is ambiguous when we're designing it. > > I agree. My main point was consistency. On Tue, Sep 5, 2023 at 1:34 AM Jorg Sowa wrote: > Thank you all for the comments. The naming brought some constructive > discussion. > > My preferred solution would be inconsistent PHP_ROUND_AWAY_FROM_ZERO and > PHP_ROUND_TOWARD_ZERO as those are friendlier to the most of developers and > are not possible to mistake with other modes. I would go even one step > further and create aliases for NumberFormatter constants to have the naming > consistent. > > Yes, this is a great way to achieve consistency, adding aliases also in NumberFormatter. Thank you, Alex
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
I really like the idea of making structs opaque in that sense,
definitely going to put it to vote in the RFC. I agree with the decision
to exclude methods from structs, as they are intended to be pure data
types and If methods are required, classes can be used instead. I guess
based on the response from this list i might not need to put it up to a
vote.
On 2023-09-08 8:58 a.m., Matthew Weier O'Phinney wrote:
On Fri, Sep 8, 2023, 9:15 AM Lanre Waju wrote:
Allowing Methods in Structs:
Initially, I suggested that readonly structs have no methods besides the
constructor. However, upon further consideration, I believe it may be
beneficial to allow methods in structs. Even PHP enums allow methods, and
considering this, I am open to discussing and potentially having a vote on
allowing methods within structs as part of the RFC discussion.
At that point, a struct would be no different from a readonly class with
public properties, meaning we'd have two ways to accomplish the same thing.
Considering that a readonly class can already implement interfaces such as
JsonSerializable, Iterator, and ArrayAccess, they already solve the bulk of
the issues that have been raised in this thread.
The main thing of interest that I could see from your proposal was the
ability to nest a struct in another struct or a class definition, as that
could provide some interesting type safety without the need to declare new
classes. This could be even more interesting if it allowed _any_ struct
that fulfilled the same definitions:
class Post
{
public function __construct(
public readonly struct $author {
string $name;
UriInterface $uri;
UriInterface $avatarUri;
},
public readonly string $title,
public readonly string $content,
public readonly DateTimeInterface $publicationDate,
) {
}
// ...
}
struct User
{
string $name;
UriInterface $uri;
UriInterface $avatarUri;
string $email;
}
$post = new Post(new User(...), ...);
The idea here is that User fulfills the $author struct definition in the
Post class; it just has _additional_ properties. If the proposal would
allow that, this could be pretty powerful.
I would personally stay away from solving the conversion to and from arrays
and allowing methods. If users need those, they can either use
de/serialization libraries or readonly classes, respectively. Not including
them in the initial proposal keeps it more targeted, and demonstrates a
language feature that does not currently exist.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
On Fri, Sep 8, 2023, 9:15 AM Lanre Waju wrote:
> Allowing Methods in Structs:
> Initially, I suggested that readonly structs have no methods besides the
> constructor. However, upon further consideration, I believe it may be
> beneficial to allow methods in structs. Even PHP enums allow methods, and
> considering this, I am open to discussing and potentially having a vote on
> allowing methods within structs as part of the RFC discussion.
>
At that point, a struct would be no different from a readonly class with
public properties, meaning we'd have two ways to accomplish the same thing.
Considering that a readonly class can already implement interfaces such as
JsonSerializable, Iterator, and ArrayAccess, they already solve the bulk of
the issues that have been raised in this thread.
The main thing of interest that I could see from your proposal was the
ability to nest a struct in another struct or a class definition, as that
could provide some interesting type safety without the need to declare new
classes. This could be even more interesting if it allowed _any_ struct
that fulfilled the same definitions:
class Post
{
public function __construct(
public readonly struct $author {
string $name;
UriInterface $uri;
UriInterface $avatarUri;
},
public readonly string $title,
public readonly string $content,
public readonly DateTimeInterface $publicationDate,
) {
}
// ...
}
struct User
{
string $name;
UriInterface $uri;
UriInterface $avatarUri;
string $email;
}
$post = new Post(new User(...), ...);
The idea here is that User fulfills the $author struct definition in the
Post class; it just has _additional_ properties. If the proposal would
allow that, this could be pretty powerful.
I would personally stay away from solving the conversion to and from arrays
and allowing methods. If users need those, they can either use
de/serialization libraries or readonly classes, respectively. Not including
them in the initial proposal keeps it more targeted, and demonstrates a
language feature that does not currently exist.
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
2023-09-08 15:12 GMT+02:00, Lanre Waju :
> Dear PHP Internals,
>
> I am writing to propose a new feature for PHP that introduces the
> concept of structs. This feature aims to provide a more concise and
> expressive way to define and work with immutable data structures. Below
> is a detailed description of the proposed syntax, usage, and behavior.
>
> Syntax
>
> struct Data
> {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }
> The Data struct is essentially represented as a readonly class with a
> constructor as follows:
>
>
> readonly class Data
> {
> public function __construct(
> public string $title,
> public Status $status,
> public ?DateTimeImmutable $publishedAt = null,
> ) {}
> }
> Assertions
> The Data struct will always be readonly.
> It has no methods besides the constructor.
> Constructors
> The Data struct can be constructed in three different ways, each of
> which allows for named or positional arguments, which can be mixed:
>
> 1.1 Class like
> $data = new Data('title', Status::PUBLISHED, new DateTimeImmutable());
>
> 1.2 Class like (Named Syntax)
> $data = new Data(title: 'title', status: Status::PUBLISHED, publishedAt:
> new DateTimeImmutable());
>
> 2.1 Proposed struct initialization syntax (Positional Arguments)
> $data = Data{'title', Status::PUBLISHED, new DateTimeImmutable()};
>
> 2.2 Proposed struct initialization syntax (Named Syntax)
> $data = Data{title: 'title', status: Status::PUBLISHED, publishedAt: new
> DateTimeImmutable()};
>
> 3.1 Anonymous Struct (Named Arguments)
>
> $data = struct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }('title', Status::PUBLISHED, new DateTimeImmutable());
> 3.2 Anonymous Struct (Named Arguments - Named Syntax)
>
> $data = struct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }(title: 'title', status: Status::PUBLISHED, publishedAt: new
> DateTimeImmutable());
> Nesting
> The proposed feature also supports nesting of structs. For example:
>
>
> final class HasNestedStruct
> {
> NestedStruct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> };
>
> public function __construct(
> public string $string,
> public Data $normalStruct,
> public NestedStruct $nestedStruct = NestedStruct{'title',
> Status::PUBLISHED, new DateTimeImmutable()},
> public struct InlineNamed { int $x} $inlineNamed = {x: 1},
> public { int $x, int $y} $inlineAnonymous = {x: 1, y: 2},
> ) {}
> }
> This proposal aims to enhance the readability and maintainability of
> code by providing a more concise and expressive way to work with
> immutable data structures in PHP.
> I believe this feature will be a valuable addition to the language as it
> not only opens the door for future enhancements (eg. typed json
> deserialization, etc.), but should also help reduce reliance on arrays
> by providing a more expressive alternative.
>
> Your feedback and suggestions are highly appreciated, and we look
> forward to discussing this proposal further within the PHP internals
> community.
>
> Sincerely
> Lanre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
Aren't structs value objects in C#? Might be some semantic confusion
there, in choice of words.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/struct
"Structure types have value semantics".
Java uses the "record" keyword. Worth taking a look at, maybe?
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
If you want a new data object with slightly different values
struct Data2 extends Data
{
{string $t, array $meta} $title; // Overwrite parent type
Status $status;
{int $x, int $y} $inlineAnonymous = {x: 1, y: 2};
}
Regarding array functions and serialization, there are two approaches:
ArrayAccess: We can implement array functions similar to ArrayObject, making it
possible to use array functions on readonly structs.
Conversion to/from Indexed Array: Since these structs are restricted to a
default constructor with named/positional arguments, we can easily convert to
and from indexed arrays. JSON serialization can also be supported with the
property names as keys.
For example:
foreach (Data as ($propertyName =>)? $property) {} //not real syntax, but you
get the idea
However, it's important to note that readonly structs are not meant to replace
arrays or lists and, ultimately, are not arrays.
Allowing Methods in Structs:
Initially, I suggested that readonly structs have no methods besides the
constructor. However, upon further consideration, I believe it may be
beneficial to allow methods in structs. Even PHP enums allow methods, and
considering this, I am open to discussing and potentially having a vote on
allowing methods within structs as part of the RFC discussion.
Cheers,
Lanre
On 2023-09-08 7:35 a.m., Robert Landers wrote:
On Fri, Sep 8, 2023 at 3:12 PM Lanre Waju wrote:
Dear PHP Internals,
I am writing to propose a new feature for PHP that introduces the
concept of structs. This feature aims to provide a more concise and
expressive way to define and work with immutable data structures. Below
is a detailed description of the proposed syntax, usage, and behavior.
Syntax
struct Data
{
string $title;
Status $status;
?DateTimeImmutable $publishedAt = null;
}
The Data struct is essentially represented as a readonly class with a
constructor as follows:
readonly class Data
{
public function __construct(
public string $title,
public Status $status,
public ?DateTimeImmutable $publishedAt = null,
) {}
}
Assertions
The Data struct will always be readonly.
It has no methods besides the constructor.
Constructors
The Data struct can be constructed in three different ways, each of
which allows for named or positional arguments, which can be mixed:
1.1 Class like
$data = new Data('title', Status::PUBLISHED, new DateTimeImmutable());
1.2 Class like (Named Syntax)
$data = new Data(title: 'title', status: Status::PUBLISHED, publishedAt:
new DateTimeImmutable());
2.1 Proposed struct initialization syntax (Positional Arguments)
$data = Data{'title', Status::PUBLISHED, new DateTimeImmutable()};
2.2 Proposed struct initialization syntax (Named Syntax)
$data = Data{title: 'title', status: Status::PUBLISHED, publishedAt: new
DateTimeImmutable()};
3.1 Anonymous Struct (Named Arguments)
$data = struct {
string $title;
Status $status;
?DateTimeImmutable $publishedAt = null;
}('title', Status::PUBLISHED, new DateTimeImmutable());
3.2 Anonymous Struct (Named Arguments - Named Syntax)
$data = struct {
string $title;
Status $status;
?DateTimeImmutable $publishedAt = null;
}(title: 'title', status: Status::PUBLISHED, publishedAt: new
DateTimeImmutable());
Nesting
The proposed feature also supports nesting of structs. For example:
final class HasNestedStruct
{
NestedStruct {
string $title;
Status $status;
?DateTimeImmutable $publishedAt = null;
};
public function __construct(
public string $string,
public Data $normalStruct,
public NestedStruct $nestedStruct = NestedStruct{'title',
Status::PUBLISHED, new DateTimeImmutable()},
public struct InlineNamed { int $x} $inlineNamed = {x: 1},
public { int $x, int $y} $inlineAnonymous = {x: 1, y: 2},
) {}
}
This proposal aims to enhance the readability and maintainability of
code by providing a more concise and expressive way to work with
immutable data structures in PHP.
I believe this feature will be a valuable addition to the language as it
not only opens the door for future enhancements (eg. typed json
deserialization, etc.), but should also help reduce reliance on arrays
by providing a more expressive alternative.
Your feedback and suggestions are highly appreciated, and we look
forward to discussing this proposal further within the PHP internals
community.
Sincerely
Lanre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
FWIW (and it isn't worth much), I'm not a fan of the braces styles
(2.1, 2.2) as it is very non-php-ish.
It'd be great to still have methods, e.g., $data->isAfter($date) or
something. Otherwise, it isn't very useful except as typed arrays,
without any of the usefulness of the array functions.
Also, what if I want a new $data object but with slightly different
property
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
On Fri, Sep 8, 2023 at 3:12 PM Lanre Waju wrote:
>
> Dear PHP Internals,
>
> I am writing to propose a new feature for PHP that introduces the
> concept of structs. This feature aims to provide a more concise and
> expressive way to define and work with immutable data structures. Below
> is a detailed description of the proposed syntax, usage, and behavior.
>
> Syntax
>
> struct Data
> {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }
> The Data struct is essentially represented as a readonly class with a
> constructor as follows:
>
>
> readonly class Data
> {
> public function __construct(
> public string $title,
> public Status $status,
> public ?DateTimeImmutable $publishedAt = null,
> ) {}
> }
> Assertions
> The Data struct will always be readonly.
> It has no methods besides the constructor.
> Constructors
> The Data struct can be constructed in three different ways, each of
> which allows for named or positional arguments, which can be mixed:
>
> 1.1 Class like
> $data = new Data('title', Status::PUBLISHED, new DateTimeImmutable());
>
> 1.2 Class like (Named Syntax)
> $data = new Data(title: 'title', status: Status::PUBLISHED, publishedAt:
> new DateTimeImmutable());
>
> 2.1 Proposed struct initialization syntax (Positional Arguments)
> $data = Data{'title', Status::PUBLISHED, new DateTimeImmutable()};
>
> 2.2 Proposed struct initialization syntax (Named Syntax)
> $data = Data{title: 'title', status: Status::PUBLISHED, publishedAt: new
> DateTimeImmutable()};
>
> 3.1 Anonymous Struct (Named Arguments)
>
> $data = struct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }('title', Status::PUBLISHED, new DateTimeImmutable());
> 3.2 Anonymous Struct (Named Arguments - Named Syntax)
>
> $data = struct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> }(title: 'title', status: Status::PUBLISHED, publishedAt: new
> DateTimeImmutable());
> Nesting
> The proposed feature also supports nesting of structs. For example:
>
>
> final class HasNestedStruct
> {
> NestedStruct {
> string $title;
> Status $status;
> ?DateTimeImmutable $publishedAt = null;
> };
>
> public function __construct(
> public string $string,
> public Data $normalStruct,
> public NestedStruct $nestedStruct = NestedStruct{'title',
> Status::PUBLISHED, new DateTimeImmutable()},
> public struct InlineNamed { int $x} $inlineNamed = {x: 1},
> public { int $x, int $y} $inlineAnonymous = {x: 1, y: 2},
> ) {}
> }
> This proposal aims to enhance the readability and maintainability of
> code by providing a more concise and expressive way to work with
> immutable data structures in PHP.
> I believe this feature will be a valuable addition to the language as it
> not only opens the door for future enhancements (eg. typed json
> deserialization, etc.), but should also help reduce reliance on arrays
> by providing a more expressive alternative.
>
> Your feedback and suggestions are highly appreciated, and we look
> forward to discussing this proposal further within the PHP internals
> community.
>
> Sincerely
> Lanre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
FWIW (and it isn't worth much), I'm not a fan of the braces styles
(2.1, 2.2) as it is very non-php-ish.
It'd be great to still have methods, e.g., $data->isAfter($date) or
something. Otherwise, it isn't very useful except as typed arrays,
without any of the usefulness of the array functions.
Also, what if I want a new $data object but with slightly different
property values?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] RFC Proposal: Readonly Structs in PHP
Dear PHP Internals,
I am writing to propose a new feature for PHP that introduces the
concept of structs. This feature aims to provide a more concise and
expressive way to define and work with immutable data structures. Below
is a detailed description of the proposed syntax, usage, and behavior.
Syntax
struct Data
{
string $title;
Status $status;
?DateTimeImmutable $publishedAt = null;
}
The Data struct is essentially represented as a readonly class with a
constructor as follows:
readonly class Data
{
public function __construct(
public string $title,
public Status $status,
public ?DateTimeImmutable $publishedAt = null,
) {}
}
Assertions
The Data struct will always be readonly.
It has no methods besides the constructor.
Constructors
The Data struct can be constructed in three different ways, each of
which allows for named or positional arguments, which can be mixed:
1.1 Class like
$data = new Data('title', Status::PUBLISHED, new DateTimeImmutable());
1.2 Class like (Named Syntax)
$data = new Data(title: 'title', status: Status::PUBLISHED, publishedAt:
new DateTimeImmutable());
2.1 Proposed struct initialization syntax (Positional Arguments)
$data = Data{'title', Status::PUBLISHED, new DateTimeImmutable()};
2.2 Proposed struct initialization syntax (Named Syntax)
$data = Data{title: 'title', status: Status::PUBLISHED, publishedAt: new
DateTimeImmutable()};
3.1 Anonymous Struct (Named Arguments)
$data = struct {
string $title;
Status $status;
?DateTimeImmutable $publishedAt = null;
}('title', Status::PUBLISHED, new DateTimeImmutable());
3.2 Anonymous Struct (Named Arguments - Named Syntax)
$data = struct {
string $title;
Status $status;
?DateTimeImmutable $publishedAt = null;
}(title: 'title', status: Status::PUBLISHED, publishedAt: new
DateTimeImmutable());
Nesting
The proposed feature also supports nesting of structs. For example:
final class HasNestedStruct
{
NestedStruct {
string $title;
Status $status;
?DateTimeImmutable $publishedAt = null;
};
public function __construct(
public string $string,
public Data $normalStruct,
public NestedStruct $nestedStruct = NestedStruct{'title',
Status::PUBLISHED, new DateTimeImmutable()},
public struct InlineNamed { int $x} $inlineNamed = {x: 1},
public { int $x, int $y} $inlineAnonymous = {x: 1, y: 2},
) {}
}
This proposal aims to enhance the readability and maintainability of
code by providing a more concise and expressive way to work with
immutable data structures in PHP.
I believe this feature will be a valuable addition to the language as it
not only opens the door for future enhancements (eg. typed json
deserialization, etc.), but should also help reduce reliance on arrays
by providing a more expressive alternative.
Your feedback and suggestions are highly appreciated, and we look
forward to discussing this proposal further within the PHP internals
community.
Sincerely
Lanre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Increasing the default BCrypt cost
@Craig warning, it's very random what kind of CPU performance you get
on your t2 instances, the CPUs vary greatly from modern to many years
old.
I know of Fortune 500 companies that have automated systems to spin up
t2 instances until they randomly get "a good one", then discard the
others, because the cpu performance vary so widely
On Thu, 7 Sept 2023 at 23:38, Craig Francis wrote:
>
> On 7 Sep 2023, at 18:26, Tim Düsterhus wrote:
> > in response to the recent "PASSWORD_DEFAULT value" thread [1], I've created
> > an RFC to discuss an increase of the default BCrypt costs for
> > `password_hash()` from the current value of 10.
> >
> > https://wiki.php.net/rfc/bcrypt_cost_2023
>
>
> Thanks Tim,
>
> Just quickly running this on two AWS EC2 servers, to give rough figures for a
> VM (note usual issues like noisy neighbours, turbo-boost, thermal throttling,
> etc).
>
> t2.nano
>
> Cost 8: 2.083060 total (0.020831 per hash)
> Cost 9: 4.115596 total (0.041156 per hash)
> Cost 10: 8.238419 total (0.082384 per hash)
> Cost 11: 16.334089 total (0.163341 per hash)
> Cost 12: 32.693785 total (0.326938 per hash)
> Cost 13: 65.587982 total (0.655880 per hash)
> Cost 14: 131.358058 total (1.313581 per hash)
>
> t2.small
>
> Cost 8: 2.062625 total (0.020626 per hash)
> Cost 9: 4.142067 total (0.041421 per hash)
> Cost 10: 8.231646 total (0.082316 per hash)
> Cost 11: 16.851889 total (0.168519 per hash)
> Cost 12: 32.814440 total (0.328144 per hash)
> Cost 13: 69.409889 total (0.694099 per hash)
> Cost 14: 133.682196 total (1.336822 per hash)
>
> Both nano and small only have 1 vCPU, have 0.5 vs 1 GiB RAM, and a different
> number of CPU Credits/hr.
>
> We recently discussed hashing and costs at one of our OWASP meetings, we came
> to conclusion that the default of 10 for bcrypt probably should be increased,
> but only to 11 for typical websites. The main concern was about making
> denial-of-service attacks easier (think of a normal website developer, who
> won't limit the number of login attempts).
>
> It's also worth keeping in mind the difference between online vs offline
> attacks, what it's being used for, human behaviour when it comes to choosing
> bad passwords ("123456" and "Password1!" will still be guessed very quickly),
> etc.
>
> Craig
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
