Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8.1.0

php.net

Post reply on HN
Print view View original

271–280 of 286 posts

Re: PHP 8.1.0

#271

Post by KerryJones »

sergiosgc wrote: post #252
KerryJones wrote: post #91

Earlier quoted context omitted.

Have you looked at any Laravel code? As someone who has worked from small startups to FAANG and inbetween, Javascript to PHP to Python to Go, I haven't found anything more elegant.

I have. Elegant it is not. Actually, it smells like Enterprise Java code, which made me flee from the Java ecosystem. To each his own, but this is not an elegant event listener (copied from the examples page): use App\Events\ArtistInformationFetched; use App\Services\MediaMetadataService; use Throwable; class DownloadArtistImage { private MediaMetadataService $mediaMetadataService; public function __construct(MediaMe…

It's interesting to me how to show your example you chose something from a 3rd party, non Laravel site (just because it has a laravel in the name doesn't), and chose something which inherently doesn't follow PHP or laravel coding standards (snake_case variables, for instance), when you could easily pull something from the main Laravel website?

https://laravel.com/docs/8.x/container#introduction

Or, if you wanted something perhaps at least use one of their featured partners for real code? https://github.com/tighten/jigsaw/blob/main/src/Jigsaw.php

I also would argue that the majority of code I see in other languages is equally or worse than the example you gave.

You can write terribly in any language, Laravel included.

Re: PHP 8.1.0

#272

Post by chubot »

lolinder wrote: post #111
chubot wrote: post #93

Earlier quoted context omitted.

Code that passes type checks can also fail to solve the user's problem, make 10,000 database calls, or render a page that is completely unreadable. The human in the loop is a good thing. All things being equal, the type system is also a good thing, but what usually happens is that you end up checking your page once a minute or once every 10 minutes, not 50 times in a minute. That difference can make or break a projec…

It depends a lot on what you're working on. If you are building a front end with PHP as your templating language, then yes, the ability to instantly see your changes is huge. In my experience, when working on back end, the difference isn't that significant because you really want to be using unit tests anyway, not constantly interacting with the front end to test your work. In those back end cases, having a strong ty…

Yeah I definitely agree that it's domain specific, and I was really talking about front ends (hence "checking your page").

User interfaces, data science, and security/reverse engineering work are three domains that really require tight feedback loops. The work I did on parsing shell [1] is basically a kind of blackbox reverse engineering, and was done with [1] https://www.oilshell.org/blog/tags.html?tag=parsing-shell#pa...

Re: PHP 8.1.0

#273

Post by jv22222 »

thinkindie wrote: post #211
bardan wrote: post #177

Earlier quoted context omitted.

I still dislike the constant $ and ->, today it just feels like extra typing. Otherwise I agree with you.

I'm with you. This is the only complaint I have about the language itself.

Trying to imagine php without $ and all I can think is... :o

Re: PHP 8.1.0

#274

Post by netzone »

Gigachad wrote: post #185
wbercx wrote: post #168

Earlier quoted context omitted.

I don't find these kinds of what-ifs very useful. I haven't used Rails, but does it somehow prevent you from accepting user input and programming it to go where you say you want it to go? Isn't there an element of "holding it wrong" with any language or framework?

Rails actually does do a good job of treating user input as dangerous and it can often detect when user input is being used in the wrong places like directly in to sql. And with industry standard tools like brakeman, you can have CI alert you of most cases where user input is not safely handled.

That's way too complicated for the person just starting out and wanting to add a counter to his small website. Nobody starting out with programming today will start with Rails. They might start with Javascript, but more than likely they'll start with PHP. It's accessible and SIMPLE.

Re: PHP 8.1.0

#275

Post by smsm42 »

the_gipsy wrote: post #240
smsm42 wrote: post #136

Earlier quoted context omitted.

I never seen any practical proof of that often repeated claim. Unless you define "proper" in an absurd way that has absence of bugs as the part of its definition, I've seen roughly as many bugs and as much time spent debugging in strongly typed languages as I have in weakly typed ones. Sure, some kinds of bugs go away, but they're replaced with different ones.

Just try it out. I am not saying that a type system will find all bugs. It will stop you from running incorrect code “50 times a minute”. Then you should have tests. Lastly you must also do some manual procedure (or run slower e2e tests). Doing all this yourself constantly is just frustrating.

I did. I've been doing it for over 3 decades, and worked with all kinds of languages. Of course, it's only my own anecdotal data set, but no, "once you try strongly typed language you'll see how magnificent it is" doesn't work anymore. I tried, and it's not that it's bad - it has its advantages - but it's not the bugless paradise that fanboys promise. And also I learned that running incorrect code 50 times a minute is not bad at all - actually, it's a pretty good rapid prototyping technique. Some people never launch their code until they are sure it's 100% perfect, I am not one of those people.

Re: PHP 8.1.0

#276

Post by [deleted] »

emodendroket wrote: post #269
Supermancho wrote: post #266

Earlier quoted context omitted.

> I'm not sure what about Java is stopping you from making static classes. I didn't imply that you couldn't make a static class in Java. There are lots of ways to make something like a top level static class (nested static, Spring singletons, et al), which works against the explicitly stated purpose of limiting state involvement.

Those limitations are a little annoying but I'm not sure how they're preventing you from doing what you want to do, and having top-level statics wouldn't limit someone from just sneaking global state in there either.

[deleted]

Re: PHP 8.1.0

#277

Post by Supermancho »

emodendroket wrote: post #269
Supermancho wrote: post #266

Earlier quoted context omitted.

> I'm not sure what about Java is stopping you from making static classes. I didn't imply that you couldn't make a static class in Java. There are lots of ways to make something like a top level static class (nested static, Spring singletons, et al), which works against the explicitly stated purpose of limiting state involvement.

Those limitations are a little annoying but I'm not sure how they're preventing you from doing what you want to do, and having top-level statics wouldn't limit someone from just sneaking global state in there either.

    @Test
    public void testSomeMethod_FromStatic() {
        StaticWrapper1 staticWrapper = new StaticWrapper1();
        int mockInput = 1;
        RegularClass rc = new RegularClass();
        int expected = 2;

        int ret = staticWrapper.someStaticClass.someMethod(rc, mockInput);

        verify(staticWrapper.someStaticClass, times(1)).someMethod(rc, mockInput);
        assertEquals(expected, ret);
    }


    public class StaticWrapper1 {
        static class StaticClass {
            public int someMethod(RegularClass foo, int val){
                return foo.someAddMethod(val);
                /* it's not practical to chain, eg
                   staticWrapper2.someAddMethod(foo, val);
                   because you end up with circular dependencies or passing large numbers of deps around, which you can't verify in tests anyway */
            }
        }
    }
You cant do this (verify the static call) by default nor anything more complicated than this (with Mockito Static mocking) because JUnit cant track deps through statics for testing. If you have multiple static objects that have static methods, you end up with brittle chains of instances that might need to refer to (either passed in or member instances of wrappers) just to call other static methods. This is inferior to PHPUnit.

Making syntactical boilerplate "just because", which also requires instantiation breaking DI (ostensibly, all you have to do is boot up Spring IoC container and it's there are runtime), is inferior to PHP.

Maybe one day Spring will be baked into Java, but that's a one-ton runtime workaround for a small mistake in the core philosophy, ie you can put a non-static function around a static function and treat it as the static, so it's a JVM problem. Pushing explicit instancing to the code is bad design from a makeshift solution to get Java working on older platforms, quickly. Now java does prechecking of memory anyway, so the way you have to do static implementation is an extraneous legacy limitation.

Re: PHP 8.1.0

#278

Post by emodendroket »

Supermancho wrote: post #277
emodendroket wrote: post #269

Earlier quoted context omitted.

Those limitations are a little annoying but I'm not sure how they're preventing you from doing what you want to do, and having top-level statics wouldn't limit someone from just sneaking global state in there either.

@Test public void testSomeMethod_FromStatic() { StaticWrapper1 staticWrapper = new StaticWrapper1(); int mockInput = 1; RegularClass rc = new RegularClass(); int expected = 2; int ret = staticWrapper.someStaticClass.someMethod(rc, mockInput); verify(staticWrapper.someStaticClass, times(1)).someMethod(rc, mockInput); assertEquals(expected, ret); } public class StaticWrapper1 { static class StaticClass { public int som…

Right, I mean, if you need to mock it a singleton would be a better choice; that's kind of the point of the pattern. Personally, though, I feel like if you frequently find yourself needing to mock these static classes, then they're not really as effective at avoiding statefulness as you claim -- if they're side effect-free, it should be safe to just use the implementation.

Re: PHP 8.1.0

#279

Post by jhgb »

the_gipsy wrote: post #74
firefoxd wrote: post #30

I've been using PHP since 5.x. Often had to work on older 4.x web apps. I find it interesting when I read people saying "PHP has come a long way. It's a proper language now, etc." If you work long enough with a language and figure out most its quirks, it's a breeze. It's nice that they are adding all these new features, but they are hardly what makes it or break it for me. Here is the one features that is taken for g…

With a proper type system you don’t need to run your code 50 times a minute.

Show me a practical type system that rejects all programs with logical bugs.

Re: PHP 8.1.0

#280

Post by exikyut »

fart32 wrote: post #200

I sometimes wish I'd never learnt C#. I love property accessors, as I consider properties to be a part of public API and in PHP, there's no nice way around it other than the boilerplate getters and setters. Also I hope we'll get generics at some point. I know there are some issues with their implementation, but even non-runtime enforced generics would be better then relying on a docBlock annotation. Enums are neat, t…

You technically can use getters and setters in PHP, albeit with a noteworthy bit of extra implementation associated with wiring up __get() and __set().
Post reply on HN