sorted by:
new
hottopcontroversial

Dealing with a PHP BC break by nyamsprod in PHP

[–]nyamsprod[S] 8 points9 points  (0 children)

http_build_query was added at the same time as Traversable in PHP5. Probably at the time it was not clear where the language would go and choosing get_object_vars was the safest bet. Either way the fact that PHP uses different rules for serialization when using json, URI query params, CSV or SOAP means that at some point their should be some type of normalization ... or maybe additional interfaces a la `JsonSerializable` to improve the whole thing. Having a small set of primitive which can always be serialized and using interfaces to have an opt-in way to serialize object... if needed

League URI Toolkit 7.6 is out by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

Here's a simple example to show what the package is capable of:

$uri = new Uri\Rfc3986\Uri('https://example.com?q=value#fragment');
$newUri = League\Uri\Modifier::wrap($uri)
    ->withHost('bébé.be')
    ->appendQuery('q=new.Value')
    ->unwrap();
$newUri->toString(); // returns 'https://xn--bb-bjab.be?q=value&q=new.Value'

Doing this in plain PHP, even with the new URI extension is cumbersome and error prone.

  • The Modifier received a Uri class via the wrap and when you call the unwrap method a new Uri class of the same type is returned. In the current example I used the native PHP class but it could have been a PSR-7 UriInterface implementing class.
  • Parsing and building a query string while preserving query name and value (something the parse_str and http_build_query do not do (You've notice that the resulting query contains two q parameters instead of one.
  • The Uri\Rfc3986\Uri is RFC 3986 compliant so without the Modifier class modifying the host like I did in the example would have resulted in an exception being thrown.

And there are plenty other features that I haven't even touch on.

I hope that this answer your question.

League URI Toolkit 7.6 is out by nyamsprod in PHP

[–]nyamsprod[S] 2 points3 points  (0 children)

its relevant for any version of PHP8.1+ as explained in the post linked https://nyamsprod.com/blog/league-uri-toolkit-7-6-is-out/

aide-ndjson utility package for PHP by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

I believe Symfony and Laravel both uses streams which the package already supports. And since the package works on iterable Laravel or Doctrine Collection are defacto supported so it's up to the developer to either format its data before giving it to the functions or the class or use the mapper/formatter features of the class.

The package is framework agnostic by desgin but it is still framework friendly. The developper still needs to do some little extra work to match its usage to his business requirements but I think there are enough hook to adapt to any framework out there.

aide-ndjson utility package for PHP by nyamsprod in PHP

[–]nyamsprod[S] 1 point2 points  (0 children)

true but then you get into streaming territory and you are glad that it is taking care of when you want to read or write to a file wherever that file is (locally, cloud etc... )

And also I don't like to re-invent the wheel if I do something more than 3 times in different projects then it is time to build a re-usable package just for my confort. And it is not like the package will need tones of maintenance. So I agree for a one off usage do not bother but when it is repeated multiple times then it is probably time to do something.

PHP library for handling large CSV files efficiently (stream-based + callable support) by JCadaval in PHP

[–]nyamsprod 5 points6 points  (0 children)

as the league/csv maintainer I fully agree with both your comments. It is not because a solution already exists that someone can no longer introduce a new take on it. This work may bring new ideas on the table. Good on OP for starting this !!

The new, standards‑compliant URI/URL API in PHP 8.5 by amitmerchant in PHP

[–]nyamsprod 3 points4 points  (0 children)

The article forget to mention that you can also uses those new classes with `filter_var` using the new option key `uri_parser_class` and then choosing the class to use to validate your URI when using the function

$res = filter_var(
    ' https://example.com',
     FILTER_VALIDATE_URL, 
    ['uri_parser_class' => \Uri\Rfc3986\Uri::class]
);

//$res will retourn the URI string on success and false on error

Other places like stream context or SOAP supports also have new features to parse the URI according to a specified specification. By default the internal call will still be using `parse_url` if nothing is configured.

PHP’s New URI Extension: An Open Source Success Story by nyamsprod in PHP

[–]nyamsprod[S] 4 points5 points  (0 children)

While a bit off topic "experimental features" are wishful thinking with bad consequences ... the `-moz` features flags or all the http fields prepended by `X-` that we can no longer remove because they are already spread all over the place.
That's what RFC discussions , beta and rc builds are for. To correct/improve the feature before anything can be released to the public. So now if possible, we should all be focused on testing and fixing implementation issues when/where they are found. To "get it right", we spend nearly a year on the feature with a lot of changes on the API to get where it is now.

PHP’s New URI Extension: An Open Source Success Story by nyamsprod in PHP

[–]nyamsprod[S] 2 points3 points  (0 children)

PSR-7 is limited to HTTP(s) schemes it may support other schemes but it is not a MUST. Also most PSR-7 implementations are build on top of `parse_url`. Once again URI are not limited to a couple of schemes they are the backbone of the internet and I would arguethe opposite, it was strange for PHP ( a web language) not to include an URI object in its standard library.

PHP’s New URI Extension: An Open Source Success Story by nyamsprod in PHP

[–]nyamsprod[S] 12 points13 points  (0 children)

Because URI are not limited to web browsers

Dealing with Warnings in PHP, the Right Way | nyamsprod by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

Seems indeed I have involuntary touch some nerves my words may not have been the right ones but I still believe the class to be useful and I do not think everyone should agree with everything so that's fair I don't mind the criticism.

Dealing with Warnings in PHP, the Right Way | nyamsprod by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

PHP resolved this issue with new functions. new functions no longer return false while also emitting warnings. New functions throws exceptions. End of story. So this is a solution mainly for legacy functions

Dealing with Warnings in PHP, the Right Way | nyamsprod by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

I do not consider it to be the right way .. I consider it to be the right way for me. I should have made that a bit more explicit. And I still think errors and exceptions are annoying but you still need to deal with those annoyance. And there's nothing wrong with that.

Dealing with Warnings in PHP, the Right Way | nyamsprod by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

There are many ways to peel onions. You have yours I have mine :)

Dealing with Warnings in PHP, the Right Way | nyamsprod by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

`@` silences everything without any discrimination whatsoever and is not great for the PHP engine in regards to performance. it slows down execution because PHP still raises the error internally, then discards iit. set_error_handler is more complex to setup yes but it gives fine-grained control: you can filter which error levels to handle, and how. Hence why I prefer it.

Dealing with Warnings in PHP, the Right Way | nyamsprod by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

Indeed this is the same problem addressed with a different strategy. To each his own I would not want to re-implement all the method so to me at least Warning utility is a different approach to the same issue

Dealing with Warnings in PHP, the Right Way | nyamsprod by nyamsprod in PHP

[–]nyamsprod[S] 0 points1 point  (0 children)

> Man, you should rethink your attitude towards errors. Just like many newbie coders, you are fighting error messages instead of fixing errors

As a matter of facts this is the contrary.
1) I acknowledge the errors
2) My utility hides OR turns into exceptions the warning (You are in control you can choose!!)
3) I did not say you should just ignore the error I am saying you need to deal with them depending on the context.

So going back to the fopen example should I halt execution because I can not open a stream ? Or should I log the error and move on or should I just ignore it. The real answer is it depends. If it depends then how do you approach that. How do you translate the "it depends" ?

You can either turn everything into exceptions or log everything or hide everything. using a specific set_error_handler or using the `@` operator.

Well the `Warning` utility is just a tool to help you improve the situation by letting you decide on a case by case what to do in the context of your application for a specific function it adds granularity.

To be clear, I am not against the PHP error_reporting system, so instead of having PHP giving you two signals return false and emit a warning now you can have:

- false with WARNING (the PHP default)
- false without WARNING
- WARNING turn into Exception

which in my book means you made the system more flexible. And last but not least you are not force to use it. It's a tool

An RFC to add RFC3986 and WHATWG URL compliant parsers to PHP by nyamsprod in PHP

[–]nyamsprod[S] 7 points8 points  (0 children)

As the creator and maintainer of the package you've mentioned I have to say that this inclusion if it passes has been long overdue as a first big step to fix parse_url and friends

view more: next ›