PHP Traits - How They Work & Drawbacks - Full PHP 8 Tutorial

Поделиться
HTML-код
  • Опубликовано: 28 окт 2024

Комментарии • 196

  • @iraklyoda4213
    @iraklyoda4213 Год назад +27

    Hello Gio. Just wanted you to know that with help of your PHP course I just landed my first full-time job as a web-developer. Thank you for your work! All the theoretical knowledge really helped me to perform at interview

    • @ProgramWithGio
      @ProgramWithGio  Год назад +7

      That is amazing, congratulations & thank you for sharing this info, you just made my day 🙌

  • @JohnnyBigodes
    @JohnnyBigodes 3 года назад +33

    This is real hard stuff to digest, but you have perfectly explained how it works and how it should be used. Thanks

  • @federicobau8651
    @federicobau8651 2 года назад +12

    Best php traits and oop tutorial and best php course, better than paid bootcamps

    • @TheBelrick
      @TheBelrick 6 дней назад

      I have to say, traits are ugly. Geez php dev team, what were you thinking?

  • @mwaas
    @mwaas Год назад +9

    this course should be main reference to learn php.
    all things is perfect and it is really the right( and the perfect )way to learn php

  • @free2idol1
    @free2idol1 Год назад +2

    Thank Gio! The more I watch your series, the deeper I understand php advanced concepts.
    I hope you would enjoy my little support here.

    • @ProgramWithGio
      @ProgramWithGio  Год назад +1

      That's awesome, happy to hear it. Thank you for your support 🙏💙

  • @lotuslando1994
    @lotuslando1994 8 месяцев назад +1

    I'm finding your use of real world examples, like coffeemakers, really, really helpful in understanding the concept of traits.
    I don't have to spend a lot of time trying conceptualize how this works. I know how coffeemakers work. I know what different types of coffee are.
    This made this lesson very easy to absorb and understand.
    Thanks again for coming up with such creative, and RELATABLE, ways to impart this information. 🙂

  • @rangingaway92
    @rangingaway92 9 месяцев назад +1

    Best course for free. Enjoy the coffee and keep going.☕

  • @free2idol1
    @free2idol1 Год назад

    12:38: `LatteTrait::makeLatte insteadof CappuchinoTrait` => this is new to me.
    Thanks Gio very much for your unique advanced tutorial.

  • @devangbaroliya2899
    @devangbaroliya2899 3 года назад +5

    Love the way u explain.
    Plz, make series on the projects after this.

  • @benfaerber4956
    @benfaerber4956 3 года назад +5

    Great tutorial! I'm a beginner Laravel dev and I'm trying to understand how to best use the framework and PHP in general.

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +1

      Thank you. That's awesome, Laravel is great and I use it everyday.

  • @Armando-px8hi
    @Armando-px8hi Год назад

    I guess it was the last common lesson related to OOP's common features. Another great work with the memes as well. Highly respected GIO!

  • @Vitalii-m6r
    @Vitalii-m6r Год назад

    Traits is a quite powerful feature. Thanks for this video!

  • @aristuzabaru
    @aristuzabaru Год назад

    🤯🤯🤯 I guess I'll have to watch it a few more times. Great content and great instructor as always!

  • @WhiteSiroi
    @WhiteSiroi 2 года назад +2

    Thank you so much, I love that you give your thoughts on best practices and share your experience, like use traits for code reusability so we can avoid duplications and wrong use of inheritance.

  • @oghenevwefepeace2501
    @oghenevwefepeace2501 2 года назад

    Finally, understand the meaning of traits. Thank you

  • @Vlodko_S
    @Vlodko_S 2 года назад +1

    Thank you! That's the best explanation of traits I've ever seen. Now all is pretty clear

  • @udalathudar
    @udalathudar 10 месяцев назад

    Thank you for this amazing PHP series, finally learned about Trait.

  • @DanielAbernathy
    @DanielAbernathy 3 года назад +1

    Very comprehensive look at traits! I learned a couple things I didn't know.

  • @mezdelex
    @mezdelex 3 года назад +1

    Great in-depth explanation. So we could say that traits share functionality logic with mixins as a way to avoid repeating code instead of using it in a more complex and not recommended way.

  • @Zubbee
    @Zubbee 2 года назад +3

    I like Traits. This lesson is like one of the longests so far and I thought it would be hard to understand since it's long but it wasn't. I followed. I totally see what you are saying about it being better to use traits for code reuse and not for declaring properties or as contracts. I'm learning alot. Thanks Gio.
    PS - Can traits be leveraged in procedural php structures?

    • @ProgramWithGio
      @ProgramWithGio  2 года назад

      That's awesome, thank you 🙌. Traits are for OOP, you need classes to use traits

  • @ryancurrington4398
    @ryancurrington4398 Год назад

    Great job explaining, thanks for sharing your knowledge.

  • @ItsDigiUtime
    @ItsDigiUtime Год назад

    Really appreciate you mentioning PSR-12 standards even with the small things like separating use statements on their own line.
    In my 2 and a half years of programming I have only met one developer who knew about this or said it out loud (I found out about it from him). Can't blame others because even in Laravel for example with auto generated code (when initialising a new project), it is not taken into account (for example the generated User class at the start).
    Just need to raise awareness more I guess to reach people who care but some people really do not care about PSR-12 and ignore it even when told about it.

    • @ProgramWithGio
      @ProgramWithGio  Год назад +1

      I agree, but in my opinion as long as you follow some sort of standard & convention and stay consistent its still better even if its not PSR-12. Laravel has its own conventions and they are somewhat consistent, so when I use Laravel I try to be consistent & follow the same conventions as well

  • @pat1938
    @pat1938 2 года назад

    Hey, thanks for the video, it really made me understand why I should use traits (very often just by reading documentation I get the idea of what something is but I never end up actually using the feature).

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      Hello 👋. Really glad to hear that 🙌

  • @syedanwar1872
    @syedanwar1872 Год назад +1

    your content worth trillion :)

  • @emekatimothyiloba699
    @emekatimothyiloba699 Год назад

    I used this last use case of traits you explained in a project i just completed

  • @siddheshb.kukade4685
    @siddheshb.kukade4685 3 года назад +2

    hey, till 9:00 you were using traits for latteMaker and cappuccino classes but as we have discu Cssed earlier the problem was in the coffeemaker class and I think you should create a trait of cofffeMaker class which was actually causing ambiguity instead of the lattemaker and cappuccino classes. let me know if I'm wrong ... btw Great Video Sir 🔥
    Edit :
    After rewatching I think that my solution is just another way yours is also correct after all, All the trait is doing is copying and pasting the code.
    actually, I was confused with the same C++ concept of *abstract methods* 👍‍‍

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +1

      Yup, traits are mainly to reduce code duplication & reuse the code instead

  • @noneavailable6742
    @noneavailable6742 2 года назад +2

    Hello. Before i ask my question i just wanna thank you for this series, it's definitely one of, if not the most comprehnsive and straight forward course i've watched.
    My question is regarding the setMilkType method in 22:30. Why do we "return $this"? aren't setters supposed to change the state of the object and not return anything? I've tried doing it without returning anything and it works but i'm not sure if i'm missing something here.

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +3

      Hello. Thank you 🙌. Returning the current object allows method chaining

    • @noneavailable6742
      @noneavailable6742 2 года назад

      @@ProgramWithGio Ahh, got it now. Thank you :)

  • @SaiyanJin85
    @SaiyanJin85 Год назад

    Great video as always, I think if we ended up having the same method signature in multiple traits used in a class then it’s code smell on our design in general, it’s nice though that php provides a way to chose which one to execute

    • @SaiyanJin85
      @SaiyanJin85 Год назад

      Also changing the visibility of a method in a trait should not been done especially by junior devs, it’s going to be a really bad habit down the road

    • @ProgramWithGio
      @ProgramWithGio  Год назад

      Yup for sure

  • @hardikjogadiya3356
    @hardikjogadiya3356 Год назад

    Wow, traits can be so awesome.

  • @massimoramaj3233
    @massimoramaj3233 Год назад

    Great explanation as always!

  • @karam0101
    @karam0101 2 года назад

    Another great tutorial. Thank you for sharing all these concepts

  • @godmansarah
    @godmansarah 2 года назад +1

    Thanks for this video! I think I do grasp the concepts better when there are examples like CoffeeMaker and Mail, rather than just Class A and Class B, foo and bar, and var_dumps :)
    So it seems that if you use a trait inside another trait and have a class that call both the "parent" trait and "child" trait, that is fine with the "duplication" of code, as PHP knows that is not a conflict? As in 16:40, CappuccinoTrait uses LatteTrait, and AllInOneCoffeeMaker uses both CappuchinoTrait and LatteTrait, and it seems to be fine.

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +2

      Yes, when using traits within traits it won't conflict unless you define a method with the same name.

  • @udayan285
    @udayan285 11 месяцев назад

    Thank you Gio.

  • @fabiosimedo
    @fabiosimedo 2 года назад

    I found it extrmely informative Thank you!

  • @fury_uri
    @fury_uri 2 года назад

    Great explanation and visuals/code examples. Almost didn't watch it due to the instructor's monotonous vocal quality, but I'm glad I did. Maybe try speaking more naturally instead of reading (?). At any rate, thanks for this helpful video!

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      Thank you. I'm usually not reading while coding, it's just the way I sound. I can't fake the emotions 😁, I know I may sound boring, I'll try to improve that

    • @fury_uri
      @fury_uri 2 года назад

      @@ProgramWithGio 😅 - ah. Well, nice job in not reading a script. I plan to check out the rest of your videos and courses. Keep up the great work!

    • @ProgramWithGio
      @ProgramWithGio  2 года назад

      @@fury_uri thank you 💙

  • @hansschuijff
    @hansschuijff 2 года назад +1

    Great course, Gio. I appreciate your effort here and the many examples you offer to make each subject clear.
    In the last example of this lesson you propose making an Email class and then extending the Invoice and Customer class to it. I agree that that would not be logical and a trait would be better in that case. But is extending the best probable way to use such a class?
    It seems that perhaps making an Email class would not be so bad if you just instantiate it and then use a send method on it. It would add a dependency, so probably that would be a subject here, but is there something wrong with just coding it something like this?
    $email = new Email( $from, $to, $subject, $content );
    $email->send();
    Anyway, thank you very much for such an extended and clear php course.

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      Thank you & great question. That is totally fine & actually the better way, it was just an example in this lesson to see how traits could be used but in general in such cases I go for dependency injection & creating objects on its own instead of having hard dependencies. Whichever class needs email object can just accept it in the constructor or within the method.

  • @emekatimothyiloba699
    @emekatimothyiloba699 Год назад

    God bless you Gio

  • @abdallakaram5376
    @abdallakaram5376 3 года назад +2

    Very excellent explanation, but I hope it will be a little slow. Thank you very much for this valuable information

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +1

      Thank you. Sorry if I went a bit too fast, I try to slow down as much as I can. RUclips also has the option to adjust the speed if needed.

    • @abdallakaram5376
      @abdallakaram5376 3 года назад +1

      @@ProgramWithGio I am very grateful to you that I will use this property

  • @rashmimore5844
    @rashmimore5844 5 месяцев назад

    Thank you for the great video !

  • @frednights7626
    @frednights7626 Год назад +1

    Thanks!

  • @benderbg
    @benderbg 2 месяца назад

    After watching this lesson my coffee making skills are next level.

    • @ProgramWithGio
      @ProgramWithGio  2 месяца назад

      That's great. Latte skills are good skills to have :)

  • @eivis75
    @eivis75 Год назад

    Thank you, as a fresh beginner I like this course so far. However, I keep having one thought in my head, how and where will I use all of this, I think I would have problems implementing simple concepts. It is a bit hard to connect all learnt stuff right now... But I guess everything will get clearer with practice, at least I will learn these concepts and it will be much easier, when I will revisit in the future.

    • @ProgramWithGio
      @ProgramWithGio  Год назад +1

      You'll just have to build projects & apply them there. Practice is what will make it stick. We are building a project at the end of this series as well.

  • @dhiaben20
    @dhiaben20 3 года назад

    actually final keyword works in traits, i tried this example and it worked.
    trait Foo
    {
    final public function foo()
    {
    echo 'Foo';
    }
    }
    class ParentClass
    {
    use Foo;
    }
    class ChildClass extends ParentClass
    {
    public function foo() {
    echo 'Error Can\'t Override Final Method';
    }
    }
    but if i do the same like you did in 27:51, using Foo trait in ParentClass and immediately override the method in the same
    class, the error will not be thrown:
    class ParentClass
    {
    use Foo;
    public function foo() { // i think doing so will just ignore foo method in trait
    echo 'this will not throw an error';
    }
    }

    • @ProgramWithGio
      @ProgramWithGio  3 года назад

      Yea that is what I said I think. When you use final keyword in a regular class you cant override that method in a child class but if you use final keyword on a method inside a trait, you can still redefine that method in a class that uses that trait. You can watch 26:44 - 28:00, I show in there that redefining a final method works & does not throw error.

    • @julienSibille
      @julienSibille 3 года назад

      @@ProgramWithGio In that case, using the trait with final keyword in the base class makes it really final for child classes isn't it ?

    • @godmansarah
      @godmansarah 2 года назад

      @@julienSibille Ah I see. This makes sense as using the trait "copies" the code into the class. From then on it is "final" for any classes that extend it.

  • @siddheshb.kukade4685
    @siddheshb.kukade4685 3 года назад +1

    waiting for next videos

  • @ilya_123__
    @ilya_123__ 11 месяцев назад

    Thank you for you great job!

  • @webdeveloper1933
    @webdeveloper1933 3 года назад +1

    Thanks for this awesome series, are you going to have series about Design Patterns? that would be great,, thanks in advance !!!

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +2

      You're welcome & thank you. Yes I'm thinking of making separate lessons about design patterns, though some design patterns will be part of this course as well in third section.

  • @thrldr3106
    @thrldr3106 2 года назад +1

    Awesome videos, man! Keep up the good work.
    So traits are something like composition but with less code, meaning that you don't have to write additional methods to call them from your class, right? But doesn't it go against the dependency injection principle since you can't pass them via the constructor or methods? Using traits you basically enforce unnecessary dependencies as far as I can tell. Doesn't it make traits intrinsically inferior to composition while in a nutshell they are designed to solve the same problem?

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      Thank you. Traits are not same as composition because code from traits is simply pasted into the class that uses it, so trait code becomes part of the class. This introduces possibilities of conflicts & so on. Composition on the other hand is when you inject dependencies through constructor (There is a lesson about composition coming soon, so it might help understand the difference).

    • @thrldr3106
      @thrldr3106 2 года назад

      ​@@ProgramWithGio thank you. Well I mean that traits just look like a generally bad option as far as the OOP is concerned. It couples your classes by binding them with a trait, so if one class needs to change a method of the trait, it either needs to override it, or the other class will have to be changed to stay in touch

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +3

      Yes and no, depends how you use traits. Note that traits are not objects like classes, they just become part of a class. The same can be said about inheritance & it is true in many cases but we still use inheritance, its part of the OOP. It depends on how you use it, overusing/misusing traits is just as bad as inheritance & anything else

    • @free2idol1
      @free2idol1 Год назад

      ​@@thrldr3106 Hi,
      I think if you need to rewrite a method then you will end up rewriting it anyway, regardless of using Trait.
      Like this above coffee maker example.
      If you don't want the makeLatte() provided by MakeLatterTrait, then you have to write your own method irrespective of using MakeLatterTrait or not.

  • @SoleilMagica
    @SoleilMagica 2 года назад

    This is good, thanks!

  • @memack101
    @memack101 2 года назад

    Thank you.

  • @dawid_dahl
    @dawid_dahl 3 года назад

    Excellent video, thanks!
    Do you have any videos on how to unit test things like traits?

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +1

      Thank you. Beginning of section 3 is about testing & PHPUnit. Though I don't have anything on testing traits specifically. Might make a separate video on that.

  • @YaidierPerez
    @YaidierPerez 3 месяца назад

    Hey there :) First of all thank you for such great content. As your last example (using the Trait Mail)... would it not be better to use a class Mail with an static method sendEmail instead? Thank you :)

    • @ProgramWithGio
      @ProgramWithGio  3 месяца назад

      I avoid use of statics as much as possible. A better way would've been to use dependency injection but this was a lesson about Traits so I showed it as an example

    • @YaidierPerez
      @YaidierPerez 3 месяца назад

      @@ProgramWithGio Thank you very much for your response :)

  • @julienSibille
    @julienSibille 3 года назад +1

    Thanks !
    Could you tell me when to use trait and when to create a service ?
    Image you have to register users in multiple places of the application, you create a trait or a service ?

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +1

      You would create a trait when you want to reuse code in multiple parts of the application. In your example it depends, why would you need to have a code to register users in multiple places. You could just create a service & use that service everywhere where you need to register the user, I don't think trait would be a good option here.

    • @julienSibille
      @julienSibille 3 года назад

      @@ProgramWithGio Thanks for reply !
      To be more explicit: There are parts of the code where i register on the fly a user as a Manager when an EventAnimatorAccount is created.
      I guess i can still use the service you've mentionned to do it ?

    • @ProgramWithGio
      @ProgramWithGio  3 года назад

      @@julienSibille service sounds about right or even Model/Repository depending on your project structure

    • @julienSibille
      @julienSibille 3 года назад +1

      @@ProgramWithGio Thank you so much for you hard work, and then taking time for reply !

  • @celesteomalowete7010
    @celesteomalowete7010 9 месяцев назад

    Thanks

  • @invgreat5608
    @invgreat5608 Год назад

    Thank you!!!!

  • @rajabhishek5551
    @rajabhishek5551 3 года назад

    Please make a video on appointment system

    • @ProgramWithGio
      @ProgramWithGio  3 года назад

      The project we'll be working on in this course is not appointment system but it will be fun :)

  • @bhaidar
    @bhaidar 3 года назад +1

    Hey Gio, I have two questions here:
    First, why the use of static::class inside non-static functions? I can use $this and it still works. Any special reason?
    Second, why would I prefer traits over composition?
    Thanks

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +2

      Hello Bilal,
      1. Check the previous lesson about late static binding. It explains why you would use static in certain cases.
      2. Composition is almost always better. Traits can help with code reuse, for example, you may have a set of methods that can be part of multiple other classes, you could use traits.

    • @bhaidar
      @bhaidar 3 года назад

      @@ProgramWithGio I already watched the late binding lesson. In this case, there is no inheritance, so using self:: gives almost the same value. Unless I am missing something here :)

    • @ProgramWithGio
      @ProgramWithGio  3 года назад

      @@bhaidar are you referring to static::class that's inside trait? It has the same usecase pretty much, if you use inheritance in the class that uses that trait then you would want to use late static binding. In some cases sure it has the same outcome.

    • @bhaidar
      @bhaidar 3 года назад +2

      @@ProgramWithGio Yes that's what I thought of later. Late Static Binding is useful when there is inheritance. Something else I realized based on my question above, with Traits, functions or properties become part of the class itself. While with composition, you are still forwarding the calls to another class.

  • @kekw5738
    @kekw5738 9 месяцев назад

    Can we use composition in the last part of video? Customer and Invoice can have relationship "has a" with Mail and it allows us to use sendEmail() method without traits, what problem could be with this?

    • @ProgramWithGio
      @ProgramWithGio  8 месяцев назад

      Yes definitely, composition would be better for sure. This was just an example of Traits

  • @PrabhashChoudhary-o3f
    @PrabhashChoudhary-o3f 3 месяца назад

    Hello Gio. For the last example instead of trait, we can have a mail class which can be used without inheritance (extending the class). is that not a good solution?

    • @ProgramWithGio
      @ProgramWithGio  3 месяца назад +1

      @@PrabhashChoudhary-o3f yes it is. Here I was just demonstrating an use case of traits

    • @PrabhashChoudhary-o3f
      @PrabhashChoudhary-o3f 3 месяца назад

      @@ProgramWithGio ok got it..thank you

  • @jgabrielmaster
    @jgabrielmaster 2 года назад

    Hey there! A quick question that came to mind at the very end of the video: you used a trait Mail to avoid code duplication when that functionality was needed by the Customer and Invoice classes. The question is - would there be a problem in simply importing a Mail class to use it? Thanks in advance.

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      Nope no problem at all, in fact composition is better in many scenarios in my opinion

    • @psriniv1
      @psriniv1 2 года назад

      @@ProgramWithGio I was going to mention this too, but it was cool to see that you COULD do this with traits. Just makes more sense to me to have $this->emailHandler->send($message) or whatever

  • @Omeostatica
    @Omeostatica Год назад

    A question: is it better to use the template method pattern in place of traits?

    • @ProgramWithGio
      @ProgramWithGio  Год назад

      Not really, is not the same. Template pattern if I remember it correctly uses inheritance while traits are used for code reuse. Inheritance shouldn't be used for that in my opinion

  • @imqqmi
    @imqqmi 12 дней назад

    Not sure what the advantage is of traits over just another class, like an email class that you import with a use statement. Traits just removes the referencing/instancing to such a class but is that all there is to it?

    • @ProgramWithGio
      @ProgramWithGio  7 дней назад

      In most cases its almost always better to use dependency injection & just pass down those classes via constructor. Traits do provide some benefits where you can extract some common methods into a Trait & re-use it without putting them in a class. You can for example extract some common functionality like common __get & __set definitions that are the same across multiple classes, drop them in a trait & reuse.

  • @andrepedrosa1525
    @andrepedrosa1525 2 года назад

    Hi, in the final example of this video, why not create a class Email, than inside Invoice and Customer create an instance of Email and use method sendEmail? Thank you.

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      Hello. Yes composition is almost always better, this was just an example of Traits. We cover composition later in the course.

  • @aleksandrkanygin2672
    @aleksandrkanygin2672 2 года назад

    Hi, thank you for the turorial, btw in the last example (where you show how to use traits for sharing functionality between non-related classes) can we also create a class called something like EmailHandler with sendMail method, and than create an instance of EmailHandler in both classes as property (in Customer and Invoice classes) and when we need to send email functionality call $this->emailHandler->sendEmail(). Would that be a correct solution? Thank you for your time.

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      Hello. Absolutely, that would be another approach & also the ideal way in my opinion in many cases. Dependency Injection is the right way 👍

    • @aleksandrkanygin2672
      @aleksandrkanygin2672 2 года назад

      @@ProgramWithGio thank you, so that's how it called, I've seen someone do this in similar case and it looked like a correct way. And I see you have a tutorial on that topic, great!

    • @ProgramWithGio
      @ProgramWithGio  2 года назад

      @@aleksandrkanygin2672 yup, more fun topics on the way 🙂

  • @free2idol1
    @free2idol1 Год назад

    Hi Gio,
    Before asking my question, I'd like to thank you for creating awesome content.
    It is hard to find a better tutorial explaining this concept than your video.
    18:42: Instead of creating a setter, can I make something like this?
    `echo static::class . ' is making Latte with ' . $this->milkType ?: "whole-milk";`
    Is there any bad implication it may cause?
    Thank you.

    • @ProgramWithGio
      @ProgramWithGio  Год назад +1

      Hey, thank you. There is no setter at that timestamp so not sure what you mean, do you mean the getter getMilkType? In general yes you can do that but it is trying to access a magical property that may or may not exist. In some cases that is ok but it is better to have it be returned from a method or at least have a property_exists check

    • @free2idol1
      @free2idol1 Год назад

      @@ProgramWithGio Thank you for your reply.
      But I could not get what the real benefit of `$this->getMilkType()` over the shorthand method of directly accessing the property ($this->milkType ?: "whole-milk";) is.
      I understand in the above mini example, the shorthand approach works fine but how about in more complex scenario, why is it not a good idea to directly accessing the property?

    • @ProgramWithGio
      @ProgramWithGio  Год назад +1

      With shorthand approach you are accessing a magical property, it will work yes but its just a preference/code smell type of thing. A method is a bit better because you can define the method within the trait. Can make it abstract and have classes that use trait define the method, that way you ensure that method is implemented & value is set

  • @blunygeorge
    @blunygeorge 3 года назад

    21:16 if we define (edit: define, I meant here as "give definition", implement) the method, of course the class does not have to be abstract. I'm not sure why is that pointed out. I did not try it out, but I assume if we don't define the method, then the class needs to be abstract (if not, and there are no errors, then this could be mentioned, but I don't think that is the case). Sorry for nitpicking.

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +1

      You are right but 20:56 is the reason I pointed it out. In the inheritance lesson, when you have at least one abstract method, the class has to be defined as abstract. But in this case, even though we technically have an 'abstract' method we don't need to define the class as abstract because it's coming from a trait & is not defined within the class itself, we just need to implement it. So basically if you have an abstract method in your class that class has to be the abstract class, you can't have a regular class with an abstract method. So that's why I mentioned that when it comes to traits you don't need to mark the class as abstract unless of course, you want to. Just thought it was worth mentioning it in case someone was wondering why we didn't have to declare a class as an abstract since trait code technically gets inserted into the class making that abstract method be part of the class itself.

    • @blunygeorge
      @blunygeorge 3 года назад

      @@ProgramWithGio I wasn't clear originally, by "define the method" I meant "implement the method". If we implement an abstract method, just like in case of real inheritance with extends keyword from a class, the subclass that implements it does not need to be abstract. No difference here between classic inheritance from classes and using traits. That is why it was a bit out of place for me the way you presented it.

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +1

      Yea and you are correct but some may have had a question on why don't we need to mark the class as abstract since if the class has an abstract method entire class has to be marked as abstract & the way traits kind of work is that trait code is "put" or rather "copied" inside the class that uses that trait, so question could arise that how come class that uses trait whose abstract method is "copied" in the class is not defined as abstract class. Maybe I went too deep with it but just wanted to point it out.
      But I agree that having an abstract method in trait means that you just have to implement that method or mark the class as abstract just like with regular inheritance. The point I was trying to make is with the way we think of traits that trait code is 'copied' within the class and if you zoom out of it & think of it that way then you could come up with that question.
      I probably overthought that part & didn't need to point it out but I try to be as detailed as possible to make sure I answer questions that might come up.

  • @imdadullah9093
    @imdadullah9093 2 года назад

    do this series have any videos on rest api and how to write good rest apis

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      No, we cover the API topic briefly but it's not a full rest API course

  • @VCR47527
    @VCR47527 Год назад

    You present traits as a way to share functionality between classes without using inheritance. What about composing functionality using class properties. In your final example why not use a class MailService which both Invoice and Customer have a reference to?

    • @ProgramWithGio
      @ProgramWithGio  Год назад

      For sure, composition is better, we cover composition also in the series. This was just an example of traits

  • @naumanbashir6385
    @naumanbashir6385 2 года назад

    Fuck! This is insanely informative.

  • @OleksiiSolonenko
    @OleksiiSolonenko 2 года назад

    Why we can’t use composition for email functionality in the last part of video? Just creating class Email without any inheritance and using it where its needed would be enough.

    • @ProgramWithGio
      @ProgramWithGio  2 года назад +1

      Yes of course you can. This was just an example of Traits.

  • @MrKristian252
    @MrKristian252 2 года назад

    You know a tutorial is good, when you casually just watch them

  • @blueyon
    @blueyon 7 месяцев назад

    PHP does allow multiple inheritance.

    • @ProgramWithGio
      @ProgramWithGio  7 месяцев назад

      Not directly, you are referring to ability to implement multiple interfaces & maybe the traits feature.

  • @Веб-разработка-л3р
    @Веб-разработка-л3р 2 года назад

    Why didn't we just create an email class with a constructor that accepts the subject, message, sender's address, recipient's address and didn't create an object of this class and didn't call the sendEmail() method from object?

    • @ProgramWithGio
      @ProgramWithGio  2 года назад

      Sure that's another way to do it. This was just an example of how traits can be used.

  • @ntdash2153
    @ntdash2153 2 года назад

    current
    trait
    parent

    • @ProgramWithGio
      @ProgramWithGio  2 года назад

      🤔

    • @ntdash2153
      @ntdash2153 2 года назад +1

      @@ProgramWithGio listing precedences : current class > trait > parent class

  • @substance90
    @substance90 Год назад

    31:20 this violates the Single Responsibility Principle. IMHO one would be better off using dependency injection of a MailService in both classes.

    • @ProgramWithGio
      @ProgramWithGio  Год назад

      Ideally yes, this is just an example of Traits, we cover composition later

  • @PickleADC
    @PickleADC 2 года назад +1

    i just prefer using interfaces and design patterns.

  • @maickelwand9100
    @maickelwand9100 7 месяцев назад

    I stop every video at the first FooBar nowadays. Made it to 23 minutes this time.

    • @ProgramWithGio
      @ProgramWithGio  7 месяцев назад +1

      Glad you watched the first 23 minutes 💙

  • @JoseManuelCornelio
    @JoseManuelCornelio 9 месяцев назад

    I'm totally lost in this one

  • @BobDoe_69
    @BobDoe_69 2 года назад

    is this difficult or am I just st*pid af hmm second guessing myself honestly

    • @ProgramWithGio
      @ProgramWithGio  2 года назад

      I can tell you that it's not easy, so no you are not st*pid. Don't worry about it if you don't get it on the first run. Take a break & come back to it and rewatch. It can take some time & everyone learns at different pace 💙

  • @TomiBorchert
    @TomiBorchert 3 года назад

    sounds like we are in a hurry.

    • @ProgramWithGio
      @ProgramWithGio  3 года назад

      Not sure what you mean. Do you mean that I talk too fast? If that's the case I apologize, I try to talk slow. Though youtube allows you to adjust the playback speed 👍.

  • @SarkarRipon
    @SarkarRipon Год назад

    Rather you stop teaching online because you are not good at teaching, you’re making a simple thing complicated.

    • @ProgramWithGio
      @ProgramWithGio  Год назад

      Many would disagree with that given the positivity in comments but feel free to watch something else mate. Cheers

  • @kickass1179
    @kickass1179 3 года назад +1

    Nice explanation, but I hope some viewers don't get you wrong, as I do not see any downsides for Traits.
    From PHP.net: "PHP implements a way to reuse code called Traits.", it doesn't mention at all that Traits can be used as contracts.
    Traits SHOULD be used whenever it is necessary to reuse code, it is PHP's way to compensate for being single inheritance language.

    • @ProgramWithGio
      @ProgramWithGio  3 года назад +1

      For sure, traits are very useful but I've seen them misused which is why I covered it in case you see it misused that way and decided to use it the same way. I don't think anyone would misunderstand since I point out the benefits of it and emphasize that it's good for code reuse.
      But also I don't think traits should be used for code reuse in certain cases. Sometimes developers drop in code and use it in many different places where it doesn't really make sense domain wise.

  • @chenting71
    @chenting71 2 года назад +1

    Really enjoying. Great Great Great. By the way, the more I get into PHP OOP, the more I feel its principle and logic become clumsy, chaotic and self conflicting. Like a not been well-thought law kept patching itself. 🥱😅. You opinion is well respected. PHP is still a powerful script language, just hope they can sort things out more logically...

    • @ProgramWithGio
      @ProgramWithGio  2 года назад

      Thank you. I think OOP makes code cleaner & more organized. It of course depends but overall I think it makes it better

  • @karolzamojcin1886
    @karolzamojcin1886 Год назад