Re: [PHP-DEV] Moving a tmpfile()?
> Why move the temporary file when it is already a temporary file, right? If you don't want to have to write the file again with a copy? On Sat, May 6, 2023 at 1:56 PM Hans Krentel wrote: > > > > On Saturday 29 April 2023 09:32:42 (+02:00), Dan Liebner wrote: > > > Are there any inherent problems with moving a file created with > tmpfile()? > > > > In practice, it seems that it can be done and the file will not be > deleted > > after being moved and the file handle closed. > > yes, not that it would be inherently wrong to do it that way, it is that > tmpfile() already offers the file handle, so you can rewind() and put the > contents in your destination file: > > > $destinationPath = tempnam(__DIR__, '.destination.'); > $tempHandle = tmpfile(); > > # ... operate on $tempHandle ... > fwrite($tempHandle, "hello world\n"); > > rewind($tempHandle); > $result = file_put_contents($destinationPath, $tempHandle); > fclose($tempHandle); > > > Why move the temporary file when it is already a temporary file, right? > > -- hakre >
Re: [PHP-DEV] Moving a tmpfile()?
On Saturday 29 April 2023 09:32:42 (+02:00), Dan Liebner wrote: > Are there any inherent problems with moving a file created with tmpfile()? > > In practice, it seems that it can be done and the file will not be deleted > after being moved and the file handle closed. yes, not that it would be inherently wrong to do it that way, it is that tmpfile() already offers the file handle, so you can rewind() and put the contents in your destination file: $destinationPath = tempnam(__DIR__, '.destination.'); $tempHandle = tmpfile(); # ... operate on $tempHandle ... fwrite($tempHandle, "hello world\n"); rewind($tempHandle); $result = file_put_contents($destinationPath, $tempHandle); fclose($tempHandle); Why move the temporary file when it is already a temporary file, right? -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Limit write access to object function parameters
Hey there,
Looking at how to achieve “readonly input object” now a few things come in
my mind:
* Write a readonly class in first place, assuming it’s not a class from a
package you cannot or don’t want to update
* Clone the object
* Use a new immutable DTO for data transfer
* Use stateless “services” (DI-ed)
* Use static code analysers
* Have conversations in your team
Having this in mind, such feature looks more or less as syntax sugar with
not much value. Nevertheless, I like it :)
Hope to see other comments.
Regards,
Dimitar
On Sat, 6 May 2023 at 13:55, Olle Härstedt wrote:
> Heyo internalitos,
>
> I was thinking of having the possibility to use `readonly` (or any
> other keyword) to make a function argument behave as if it was a
> readonly object.
>
> class Point
> {
> public int $x;
> public int $y;
> }
> function doThing(readonly Point $p)
> {
> $p->x = 10; // Not allowed
> }
>
> In C# it's called in/out/ref types:
> https://www.pluralsight.com/guides/csharp-in-out-ref-parameters
>
> The main use-case is to not give away more access than you have to,
> and being able to state your intent in the function signature.
>
> Another alternative would be to allow properties in interfaces, and
> then define a readonly-like interface:
>
> interface ReadonlyPoint
> {
> public readonly int $x;
> public readonly int $y;
> }
> function doThing(ReadonlyPoint $p)
> {
> $p->x = 10; // Not allowed
> }
>
> No idea about practical feasability.
>
> Since arrays are value types, they're not really relevant for this
> suggestion. Same goes for string, int, etc.
>
> Regards
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Final anonymous classes
On Sat, May 6, 2023, at 2:16 AM, Rokas Šleinius wrote: > On Fri, 5 May 2023 at 23:58, Levi Morrison via internals > wrote: >> >> I am not sure about making them final by default. I think it's a more >> consistent language design to allow `new final class()` as you >> originally proposed. Although I don't know why anyone would want to >> extend anonymous classes, we can see that people do, in fact, do it. I >> don't see why we couldn't allow `new class() extends $someClass` in >> the future to specifically allow them to do this. I mean, I'm not >> going to lobby for it, I'm just pointing out that is more aligned and >> consistent with other parts of the language, than to simply make it >> final by default. >> >> Cheers. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> > > My work currently is integrating with various shipping provider APIs > such as DHL. I have to deal with the enormous API request (and > response) definitions. I am just creating a DTO class for each level > of JSON key, which results in a HUGE amount of classes. > > I have a hunch this problem can be solved better with anonymous > classes, but their support is not great yet - PHPStorm has a breaking > bug with their autocompletion and I am too dumb to figure out a better > solution in any case. I think you're on the right track with named classes, honestly. With current PHP versions that's syntactically a lot nicer than it used to be. > However, I totally agree with Levi in that the way forward is better > towards `new class() extends $someClass` and not "all anonymous > classes final by default". It may open patterns and opportunities we > have yet to think about. My understanding of the engine implementation is that extending from a class dynamically would be really really hard. (Anon classes are not defined at runtime, they get defined at compile time, just with an auto-generated name.) That said, I have to agree here as well that I'm not a fan of forcing anon classes to be final, but if someone could figure out dynamic-extension anon classes, I would be a happy camper. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Limit write access to object function parameters
Heyo internalitos,
I was thinking of having the possibility to use `readonly` (or any
other keyword) to make a function argument behave as if it was a
readonly object.
class Point
{
public int $x;
public int $y;
}
function doThing(readonly Point $p)
{
$p->x = 10; // Not allowed
}
In C# it's called in/out/ref types:
https://www.pluralsight.com/guides/csharp-in-out-ref-parameters
The main use-case is to not give away more access than you have to,
and being able to state your intent in the function signature.
Another alternative would be to allow properties in interfaces, and
then define a readonly-like interface:
interface ReadonlyPoint
{
public readonly int $x;
public readonly int $y;
}
function doThing(ReadonlyPoint $p)
{
$p->x = 10; // Not allowed
}
No idea about practical feasability.
Since arrays are value types, they're not really relevant for this
suggestion. Same goes for string, int, etc.
Regards
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Final anonymous classes
On Fri, 5 May 2023 at 23:58, Levi Morrison via internals wrote: > > I am not sure about making them final by default. I think it's a more > consistent language design to allow `new final class()` as you > originally proposed. Although I don't know why anyone would want to > extend anonymous classes, we can see that people do, in fact, do it. I > don't see why we couldn't allow `new class() extends $someClass` in > the future to specifically allow them to do this. I mean, I'm not > going to lobby for it, I'm just pointing out that is more aligned and > consistent with other parts of the language, than to simply make it > final by default. > > Cheers. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > My work currently is integrating with various shipping provider APIs such as DHL. I have to deal with the enormous API request (and response) definitions. I am just creating a DTO class for each level of JSON key, which results in a HUGE amount of classes. I have a hunch this problem can be solved better with anonymous classes, but their support is not great yet - PHPStorm has a breaking bug with their autocompletion and I am too dumb to figure out a better solution in any case. However, I totally agree with Levi in that the way forward is better towards `new class() extends $someClass` and not "all anonymous classes final by default". It may open patterns and opportunities we have yet to think about. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
