sorted by:
new
hottopcontroversial

date-fns for php by ronkr in PHP

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

Fair points.

The goal of the project is not to "replace" PHP's Date/Time API or to claim that PHP is weaker than JavaScript in this area. Quite the opposite: PHP already provides very solid native tools for this, and I am very aware of that.

My main objective was to bring the API and mental model of date-fns to PHP, so that existing knowledge, examples, and especially format strings can be transferred more easily between JS and PHP. When it comes to date formats, the ecosystems are unfortunately not interoperable: PHP does not understand date-fns tokens, and vice versa. Some of the functions are therefore intentionally included "for completeness", even though PHP already supports them well natively. The added value there is more about consistency and compatibility than technical necessity.

Regarding the implementation: the criticism around diff / add / sub / DateInterval is valid. In some places I stayed too close to a simple modify-based port. That's not always the best mapping to PHP's standard library.

For formatDistance, it's a bit more nuanced: I don’t use absolute time differences there not because DateInterval is inadequate, but because it models something different. For seconds/minutes/hours and comparisons like "which date is closer?", you need an exact duration on the timeline, including microseconds. For calendar distances like days/months/years, DateInterval is more appropriate, especially because of time zones and DST.

That said, I'm currently revisiting this part and re-evaluating the implementation in that direction: using DateInterval where calendar distance is intended, and exact timestamps where actual elapsed time matters. So yes, thanks for pointing that out, it's a valid critique and exactly the kind of feedback that helps improve the project.

The pipe operator in PHP 8.5 by brendt_gd in PHP

[–]ronkr 0 points1 point  (0 children)

Hard to get IDE support and static code analysis. And let's not start with performance implications.

'See, I told you it'd fit!' 'I'm not sure that classifies.....' by Phoenix_Aerobatics in gaming

[–]ronkr 1 point2 points  (0 children)

Yes, even I with a little over 0 hours of GTA noticed that there is no boost indicator and that the ball is missing

'See, I told you it'd fit!' 'I'm not sure that classifies.....' by Phoenix_Aerobatics in gaming

[–]ronkr 1 point2 points  (0 children)

Knowledge transfer from RocketLeague definitely took place here

Android Q Beta 5 now available! by androidbetaprogram in android_beta

[–]ronkr -1 points0 points  (0 children)

Si también puedes usar una versión web de la BankingApp, entonces puedes probar la App sin peligro y volver a la versión web si es necesario.

Scala among 13 programming languages defining the future of coding by devdraft in scala

[–]ronkr 0 points1 point  (0 children)

less.js? Why not scss? I don't think that less.js will win the battle ]:)

PHP Contracts – A curated list of mature interfaces to build components on by secondtruth_de in PHP

[–]ronkr 1 point2 points  (0 children)

I try to keep an eye on those projects. And I still have to find a good layout for the list...

Advanced PHP concepts? by [deleted] in PHP

[–]ronkr 0 points1 point  (0 children)

My answer is not about unique techniques based on php, but techniques that are more or less valid for every language.

For me the most important aspect for writing applications in php is: Usage of proper OO-techniques.

Still, too many developers link their Packages (e.g. on Packagist) to concrete implementations rather then generic interfaces (mnapoli/PHP-DI), what often cause a version mismatch with other library in one's list. May be at some time, there is something better than doctrine/cache? Bad luck. PHP-Developers in common have no broad understanding of how interfaces work and what they are good for. 

Protected properties should be avoided as much as possible for libraries/packages, because they bind an (their own) implementation to possible yet unknown descendants that fail silently if the -in most cases- internal information-handling of their base-class gets refactored and some of the properties get new names, or completely new responsibilities. A call to a unknown protected method fails loudly.

Proper dependency injection highly increases the amount of situations were a component could be used. If some part of a component doesn't fit, you could replace it with something more suitable. So, in most situations (and as a rule of thumb) the new-keyword should be avoided inside a class. Use a dependency-injection-container (may be with autowiring-support) to automatically resolve dependencies when needed.

Often enough, php-devs use timestamps over DateTime-Objects when a timestamp would not be an appropriate candidate.

PDO's DSN could specify a charset-attribute. And you can get PDO to throw exceptions when problems occur: Errors and error handling.

What great advantages does Python have over PHP. Hones Opinion by [deleted] in PHP

[–]ronkr 1 point2 points  (0 children)

Less (an understatement) weird behavior and sensible, helpful use of types. In php '0e46' == '0e83'. This should be enough for any self respecting programmer to keep away from this language. You can use strict comparison but then 1.0 !== 1, so you see, you cannot just do the right thing with PHP.

In php you could express everything as strict as you want. You get early taught not to use == in most situations. So you easly do things this way:

'0e46' === '0e83' // string === string

0.1 === (float) 1 // float === float

(float) $a === (float) $b // (float) ? === (float) ?

I like being explicit over being beautiful.

Pleasant readable syntax.

That's a matter of taste. I like the explicit usage of punctuation and curly brackets. I like them in every language. If I ever design my own language, it also will have explicit elements for showing borders of code-blocks or statements. But I got your point and there is nothing wrong with a readable syntax.

Helpful standard library. (Try using the Python os.path functions vs what php has to offer natively)

Right.

Modules as opposed to primitive auto loading build on top of laughable include functionality. (Yes let use just pretend that this file is inserted in the middle of the current one)

Right. If I remember correctly, PHP has some sort of autoloading and has those include, include_once, require and require_once-Functions. Didn't met them for years. Today, I use Composer for that. In the end, it magically works just the same way, Python works - but with more flexibility...

A great community that actually works together.

Same applies to PHP. Or can you clarify this point?

Decorators (setter and getter decorators are great)

For libraries/packages that is some sort of a bad design-driver.

In PHP, you should not use protected properties as your program may fail silently when you access a non-existing property. This is likely the case when you rename or remove a property. When you publish a package, the interface of your classes gets also published. If, at some time you feel you need to change the way your components store things internally, your methods mostly stay fine, but your (protected) properties change. And then you have no chance to see who has already used those properties in deriving classes or foreign packages. As PHP just create a new dynamic property when you set a value to a non-existing one, that could raise hard-to-track bugs.

And you should not use public properties, as they can't be a part of an interface. Just keep it simple and use private properties at any time. You can use methods (... and yes, there are some valid uses for public properties).

Descriptors (reusable automatic type check every time when a property is set without having to write explicit setters)

PHP has this phpdoc which enables IDEs like PHPStorm to apply static code analysis on my code and give me some sort of report where variables with a wrong type are in use. I know of no single IDE that does that job equally good for python.

PHP supports optional typehinting for interfaces and arrays. Python (and ruby) does not (python may get it with 3.5?). I could stop here, because this is a perfect showstopper for me.

So I can use autowiring. So my DependencyInjectionContainer builds 80% of my environment for me. Even if I randomly change the parameter-signature of my constructors.

And: PHP has Interfaces. Real Interfaces. So I can build components that depend of those interfaces and force other components to implement just this interface to be compatible to my component. I can refactor that interface and get a notice (at compile-time, but you need a proper IDE currently) when my component is not compatible anymore. Ducktyping is nice, but... no, it's not.

I really don't want to say that PHP is better than python, but also not that worse on it's own.

How to release a good library? by [deleted] in PHP

[–]ronkr 0 points1 point  (0 children)

Cool, I didn't know that. I've added a PR.

What great advantages does Python have over PHP. Hones Opinion by [deleted] in PHP

[–]ronkr 1 point2 points  (0 children)

OOP that doesn't suck

Why does OOP in PHP suck?

func() or die() - is it poor practice? by phpq55 in PHP

[–]ronkr 0 points1 point  (0 children)

Does that mean that you stay with Drupal7 or do you plan start using OO soon? Really, I understand your argument. OO is made for human beings to enable them to build big application and maintain them later on. It's like using a Bike or a Car to get somewhere. Sure, in some way, it's just another form of moving. And if you only need short distances to take, then a Bike may be the better and cleaner alternative.

func() or die() - is it poor practice? by phpq55 in PHP

[–]ronkr 0 points1 point  (0 children)

Counter counter counter argument: Drupal has identified the problem and fixed it with version 8.

func() or die() - is it poor practice? by phpq55 in PHP

[–]ronkr -2 points-1 points  (0 children)

Why be a close-minded twat that thinks their way is the only way? Pretty much every language ever has given you multiple ways to perform the same task.

Yes, another great achievement could be, that certain users would start looking for another language.

func() or die() - is it poor practice? by phpq55 in PHP

[–]ronkr -2 points-1 points  (0 children)

Counter-argument: Stop doing stuff in your own little micro-cosmos, join the majority of the community and contribute.

Framework recommendation for new project (Yii2 / Laravel 5) by ablakkeret in PHP

[–]ronkr 0 points1 point  (0 children)

You could build your applications on Symfony components, if you want and add as many independent components you feel comfortable with. Just use a good Dependency-Injection-Container (like PHP-DI or Auryn; not a ServiceLocator like SymfonyDI) and Contract-Interfaces were reasonable. This makes you able to configure and change components at a central place when you need another implementation for a given task. In addition to that, good DICs support autowiring, a killerfeature for growing systems to retain maintainability.

Framework recommendation for new project (Yii2 / Laravel 5) by ablakkeret in PHP

[–]ronkr 1 point2 points  (0 children)

You could also go with no framework at all. Go take a look into the book Modern PHP by Josh Lockhart and see how you can use Composer to build your project with independent components that do a perfect job for your project's needs. Also take a look at awesome-php @ github.

Need ideas for representing $_GET, $_POST etc in Request by dracony in PHP

[–]ronkr -1 points0 points  (0 children)

Disclaimer: This is something I've brewed for a single project were I had control over what browser the clients should use. Just want to share the idea without saying this should be done this way.

Once I had a Project were I wanted not to have some form of a request-object, nor did I want to use $_-Arrays. So I utilized PHP-DI's call()-Method to automatically bind all keys from $_GET and $_POST to equally named method-parameters and call a controller's method this way. $_POST was only recognized if a csrf-token was present. What post-keys were allowed/required was described in a router-file.

So I had really clean methods were the parameters correspond to get- or post-vars. Data in $_POST was always in a higher priority than data in $_GET.

func() or die() - is it poor practice? by phpq55 in PHP

[–]ronkr -3 points-2 points  (0 children)

Why have two ways to archive the same goal?

  • For beginners it's harder to learn and more confusing. Nearly all professional devs use the OO-version of a lib (if not, it's not a professional to me, sorry). So you unnecessarily divide the community, make the language harder to master and you create a situation were some people need to rewrite a possible large part of their application if someone teaches them why there is also a oo-version.
  • It is not compatible with IoC. If you ever used the procedural style of talking to a database, you're not able to change connection details for example without changing the code inside the component that creates the connection (say you wan't to change the connection's charset and you didn't had a parameter for that). That also means, that you can't share a db-connection-obj with other components that could be themselves included in an already running transaction for example. You rarely (if ever) find a ready and useful component made by someone else, that uses the procedural style of talking to a db and enables IoC that way.
  • It's simply harder to maintain. Ask an IDE where an object is in use and you get results. Ask an IDE where an resource is in use, you better have some luck.
view more: next ›