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.
  • Flattened, composable behavior -- sounds like traits [unibe.ch].

    ;-)

    -- dagolden

    • I've read through that a number of times and I think they're right. There are, however, a couple of key differences. First, they don't have state with their traits (see bottom of page two in Traits: Composable Units of Behaviour [unibe.ch]). I think that's a mistake and so does Perl 6 and Moose. Smalltalk traits only share behavior, not data.

      Second, they're not advocating eliminating inheritance. They're advocating eliminating MI and mixins and using traits for allomorphic properties. I'm thinking that perhaps t

      • I agree the local class overriding role can seem confusing, but over the past few years of using roles pretty heavily I have come to appreciate this feature quite a lot. It actually makes the roles more re-usable since it is very easy to locally override something. Yes it does destroy some of the black-box-ness of Roles, but honestly I have not found roles to be very useful unless you can look inside and see what they provide/do. I have come to kind of see Roles as being more semi-transparent then opaque,

        • But for the few times that a local class needs to override a role, why not just have the class explicitly exclude that method from the role? Same effect, but it's explicit, not hidden. So you avoid mysterious breakage and you get closer to how roles were originally intended to be used (a good thing, in this case).

          I realize you probably can't change the API now, but what about use Moose::Role 'strict' or something like that?

          • [Why] not just have the class explicitly exclude that method from the role?

            That's for the same reason that classes don't explicitly mark overridden methods as "Hey! I'm overriding this method here! Pay attention! Don't look in my superclass! I'm over heeeeere! CALLMECALLMECALLMECALLME!"

            I can imagine a debugging or introspection mode where you can see exactly where methods and state come from, but one of the goals of roles was to provide transparent and typeful class componentization. If you don't know which methods a role provides, you shouldn't use it.

            • That's for the same reason that classes don't explicitly mark overridden methods as "Hey! I'm overriding this method here! Pay attention! Don't look in my superclass! I'm over heeeeere! CALLMECALLMECALLMECALLME!"

              We know they don't do this in Perl, but we also know that Perl's core OO is fairly limited. In several other languages, you must explicitly mark overridden methods. It's a great help to the programmer to see what's going on. After all, programs should be written primarily for humans to read and only incidentally for computers to understand.

              If you don't know which methods a role provides, you shouldn't use it.

              Agreed. There's still a difference between the real world and the desired world and in the real world, things aren't that simple. I want my code to fail at compile t

              • So far, aside from mocking my point of view, I've not heard anything which says that silently ignoring the role's method has a lower cost than the programmer explicitly ignoring it.

                Let me put it forth then: requiring explicit confirmation of overriding would be inconsistent with the existing stages of implicit overriding. I'll even raise the question of consistency in a context unrelated to OO: do you worry that the binding of lexical variable declared in an innermost scope shadows a lexical variable of

                • do you worry that the binding of lexical variable declared in an innermost scope shadows a lexical variable of the same name declared in an outer scope, and does so without an explicit marking?

                  Comparing a lexical variable and and a global method definition is comparing apples to oranges. When I'm calling $object->foo, I neither care, nor worry, what the lexicals are. I also don't worry about how &foo is defined, but I should care. And I do. With my heavy use of roles, I've found (an anecdote, I confess) that silently overriding a role method is a painful bug to track down. Knowing that, unlike with inheritance, we can actually find and prevent such errors at compile time but the keepe

                  • With my heavy use of roles, I've found (an anecdote, I confess) that silently overriding a role method is a painful bug to track down. Knowing that, unlike with inheritance, we can actually find and prevent such errors at compile time but the keepers of the keys refuse to do so doesn't make my code magically work.

                    One of the advantages of a slick IDE would be that you could trap many of these mistakes at edit time even, rather than compile time. Purple method-names are overriding something, blue aren't (or whatever).

                    One of the things you get for free with Smalltalk's image system I suppose.

                  • Comparing a lexical variable and and a global method definition is comparing apples to oranges.

                    I don't know what a "global method definition" is. Method definitions have their own scoping; they're scoped to invocants of the appropriate type. That's why I believe that the shadowing rule is appropriate: we're talking about which piece of code or behavior Perl can access when you use a specific name in a specific context.

                    Knowing that, unlike with inheritance, we can actually find and prevent such errors a