Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If Perl can do it, why can't you you stupid framework.

    The answer is because they, like the Java camp, have declared multiple inheritance bad. The reasoned that the work arounds weren't good enough to solve the diamond pattern in every case or they wanted to make things more "simple".

    I would not agree that lack of it makes the language broken.

    • I suspect that too much (ab)use of MI in C++ land might have lead to the descision as well. Although it is worth pointing out that it is much more difficult to handle MI sanely when you have a class system which handles your instance variables for you. Throw in virtual methods and object upcasting and you have a real nightmare trying to determine which object slot you should write too at any given moment (this is especially true if you want to agressively optimize anything). However, this does not mean tha

    • I would consider anytime you have to write an interface and an implementation class and glue that into multiple other classes just to work around the lack of MI as broken. As a tanget, the .NET 3.5 Orcas stuff adds "method extensions", which is basically the ability to inject methods into any type, which in most cases, can fix the lack of MI. 3.5 is also picking up initializer, which finnally does things like:

      new Person(){Prop1="Val";Prop2=3;Prop3=new OtherClass(){OProp1=34}}

      automatically assign the va

  • What's really broken is that people think you need to inherit everything. In your example, it looks like you have a cart that should have things, not inherit things. I know this lame example shows up in a lot of Java books, but it's the wrong use for inheritance. They usually pull this stuff out to explain decorators, too, which is a pattern that is almost never needed for the example given.

    There's no reason that any of those things should have an Is-A relationship. You need a cart that contains other disti
    • There's no reason that any of those things should have an Is-A relationship. You need a cart that contains other distinct objects,

      That's not exactly true in .NET. The Cart whould returns a strongly type collection of CartItems, not a mishmash of Object that then have to be inspect just to see what they are. And I don't understand that statement about no reason for IS-A. A CartItem IS a part...period. 100% percent of the time. You can't buy anything that's not a part...but I digress... Well sure, you coul

      • That's not exactly true in .NET. The Cart whould returns a strongly type collection of CartItems, not a mishmash of Object that then have to be inspect just to see what they are.

        It would make more sense to return a collection of objects that share similar interfaces, where these interfaces define the actions that you want to do with these objects.

        Your cart could return a collection of objects that can be IOrderable, IShippable, etc, where these are characteristics of these objects.

        • Right. I don't disagree with that statement as a solution.

          Again, by using interfaces, each different type of object has to reimplement the same code the implement the interface. That's a waste of effort when inherts takes care of that problem. To avoid duplicating code for all different types of objects implementing IPart, they'de all have to use another class..which even more effort for no good reason.

          We're not talking about unrelated objects in a collection ACTING like a part (via a common Interface), we'
      • Inheritance is only one way to look at that. An orderable item can be an object that contains a part along with an order description, coupon, etc. Those HAS-A relations, along with appropriate dispatching, don't need inheritance.

        Like I said, inheritance is beat into people's heads, so they think in terms of it when in reality the world doesn't operate that way.
    • Thanks for saying that. I wanted to pipe up but couldn’t muster the energy to be coherent.

      Inheritance is overrated. Polymorphism is the key; inheritance is not.