user-pic

Sid Burn

  • About: I blog about Perl, C# and programming in general.
  • Commented on Inheritance is Bad: Code Reuse Part II
    Your concerns about separate Position roles don’t make sense to me. One is mutable and the other is not. Since position and movement are different things, why not make them different roles in your example? It should be more a...
  • Commented on Using Role as Partial Classes
    Nah, some characters and formating has gone wrong. It's sad that MovableType has no way of edit a comment. But another thing what i wanted to say. You mentioned YAGNI. Actually what i say doesn't invalidated YAGNI at all. YAGNI...
  • Commented on Using Role as Partial Classes
    No. A movement is an action. It's an abstract thing which doesn't stand on its own, like a character or a space station. It has to be attached to something concrete to exist. The idea that something has to be...
  • Commented on Using Role as Partial Classes
    This is not true. I have no other need for movement at this time, so solving a problem I don't have is a very bad practice. That you can re-use it, is more a side-effect. Movement is a single responsibility,...
  • Commented on Using Role as Partial Classes
    Actually, for everything you have written i would recommend my own blog that i have written that exactly faces the problem you have. http://blogs.perl.org/users/sid_burn/2014/07/inheritance-is-bad-code-reuse-part-iii.html But it probably makes the sense to read all three parts. The overall problem that you...
  • Commented on Inheritance is Bad: Code Reuse Part I
    Yes, interfaces solve Part of it. The Problem is that interfaces itself don't have Code Reuse because their are just interfaces. In Part II i describe a solution with Roles. That somewhat gives you what interface have plus an implementation....
  • Commented on Sorry, my understanding of role is not enough
    Why, not created a new blog instead of modifing the old? 1) The "diamond problem" is not the reason against multiple inheritance. And you already can say that this one is solved with the C3 MRO (Method Resolution Order) algorithm....
  • Commented on Method Privacy in Perl
    Don't use inheritance. All problems solved....
  • Posted Inheritance is Bad: Code Reuse Part III to Sid Burn
  • Commented on Inheritance is Bad: Code Reuse Part II
    But you don't change a Role. In this case you need to delete Destroyable first and then apply DestroyableResistances. You also could now say you start with a class without Destroyable or DestroyableResistances and at startup you create just two...
  • Posted Inheritance is Bad: Code Reuse Part II to Sid Burn
  • Commented on mop problem 5 - Role and C3 searching is not always necessary
    Well, if you discipline yourself you can build a "Role-like" System with multiple inheritance. But it can easily go wrong. Role takes the good idea out of it and makes it nearly impossible to do it wrong. Single Inheritance itself...
  • Commented on Inheritance is Bad: Code Reuse Part I
    I will continue. I got some personal problems here. But next article will come soon....
  • Commented on Inheritance is Bad: Code Reuse Part I
    I did not say that IO::Seekable exists or was split because someone had the design in mind that i described here. I'm justing saying that the design that i described matches that of IO::Seekable and it is just an example...
  • Posted Inheritance is Bad: Code Reuse Part I to Sid Burn
  • Commented on The map/grep/sort dead end
    Three of the modules you mentioned aren't even usable, are still in the concept phase, or just provide a wrapper around Iterators but not really compareable to something like LINQ in C#. Data::CapabilityBased is just an idea how it could...
  • Commented on The map/grep/sort dead end
    Thanks. I never looked in the Mojo::* namespace because i primarly used Catalyst and didn't even expect that something like that would be in Mojo::*. At least it helps to make it better readable. A Lamba Syntax is just an...
  • Commented on map/grep is not a real iterator?
    map/grep are no iterators at all. They just read the whole list, apply the function to every element and return a new list. Perl itself doesn't have special iterator support. But you still can write something as an iterator, but...
  • Posted The map/grep/sort dead end to Sid Burn

    The first thing i wanted to talk about is the map, grep and sort Functions. I think these functions are somewhat special. If someone look at these functions then we can say that these are concepts of a functional programming language.

    All three functions take a code block. All three functi…

  • Posted Writing about Perl to Sid Burn

    Hello,

    so now i did it. I registered to write about Perl. But actually i wonder myself why i did it now, and not earlier. So i want to tell a little bit about myself.

    I'm 31 years old. I come from germany so you probably notice that my english is not the best. I apologize and try t…

Subscribe to feed Recent Actions from Sid Burn

  • Yuki Kimoto commented on Sorry, my understanding of role is not enough

    My idea is that role can only provide methods. This advantage is :

    1: We don't need to learn new syntax BUILD/DEMOLISH.
    2. We can use overriding of new method. sub new { shift->SUPER::new(@_) }
    3. We can use DESTROY mehtod.
    4. We don't need to think about internal data. We can only think about methods.

    Single inheritance is not bad. I think current perl inheritance syntax should be used on mop.

  • trp commented on Inheritance is Bad: Code Reuse Part I

    OOP solves the problems you describe with interfaces. Clean, simple, no muss, no fuss.

  • Ovid commented on Inheritance is Bad: Code Reuse Part II

    First, you should generally be consuming all of your roles in a single with statement:

    with qw(Destroyable PositionRW);

    By composing those separately as you have (two separate with statement),you’re lose the composition safety of roles and your code is reduced to little more than mixins.

    Your concerns about separate Position roles don’t make sense to me. One is mutable and the other is not. Since position and movement are different things, why not make them different roles in your example? And you can define a position inter…

  • Ovid commented on Using Role as Partial Classes

    Thanks for your comments, Sid. I saw some interesting things in the second part of your series of posts and I made some comments there about them.

    Next, you wrote "Movement" for example should be a behaviour that is re-usable.

    This is not true. I have no other need for movement at this time, so solving a problem I don't have is a very bad practice. I'm building an MMORPG and if I try to solve every problem I don't have, I'll never finish. If, and only if, I need to re-use movement behavior, will I solve that problem.

    You also wrote: A Character should hav…

  • Ovid commented on Using Role as Partial Classes

    Movement is a single responsibility, so it should be its own class.

    No. A movement is an action. It's an abstract thing which doesn't stand on its own, like a character or a space station. It has to be attached to something concrete to exist.

    The idea that a class only should represent abstract things like "Customer", "People", "Car" or other things is not really right. A class represents something specific. In a full object oriented language even something simple like an "int", "float", "string" is already represented as a class. A class should represent one sp…

Subscribe to feed Responses to Comments from Sid Burn

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is run by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.