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.

Why make classes you can't subclass? 7 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • How ironic that you try to enable subclassing but you forbid polymorphism with that ghastly method-as-function silliness.

    • Read closer. There is no irony.

      Polymorphism is already forbidden unless I want to rewrite a significant section of the existing code. I am therefore trying to find a way to get the behavior I want without doing that rewrite or else cutting and pasting.

      The first two solutions that I tried (neither of which worked) tried to extend the existing code in such a way that they would not affect anyone else who wanted to extend the existing code using the same technique. In other words I was trying to make my approach as polymorphic as possible given the existing code.

      Only after those approaches both failed did I consider injecting my code directly into that module. Given the structure of my application I am extremely confident that I only need one stash. And this behavior is what I want for my stash. So the non-polymorphism is not actually a problem.

      However I tried to make it polymorphic. Really.

      • Given the structure of my application I am extremely confident that I only need one stash. And this behavior is what I want for my stash. So the non-polymorphism is not actually a problem.

        I'm sure that's the same rationale why the original code is difficult to subclass; the author figured that one one would ever want to subclass it, so non-subclassibility is not actually a problem.

        • There is a significant difference. I'm working on a code-base with a specific purpose that I'm the only developer on. This gives me a fair amount of insight into how it is likely to be modified in the future.

          The module in question is used by a large number of people for many different things, and therefore the author should assume far less about how it is likely to be used in the future.

          I also note that, even though I don't think polymorphism is important within my code base, I looked first for a solution

          • I looked first for a solution that would preserve the possibility of polymorphism.

            That solution is easy and it's shorter than what you have.

            if (not eval { exists $self->{$variable} } ... )
            • You're complaining about the UNIVERSAL::isa?

              That idiom appears within other code within Template::Stash::Context. Again, if you want to fix that, fixing it in my code is less important than changing it in the main module. Doubly so because it already can't be readily subclassed, which makes any worries about the best way to be polymorphic completely irrelevant.

              That said, your fix has its own issues. Suppose that somewhere up the calling stack someone is using signals and a die handler. If that signal ha

              • Therefore if satisfying you interferes with virtually any other desirable code criteria, I will not bother trying to satisfy you. Not because I particularly want to irritate you, but because I care about different things.

                Glancing at the title of your journal entry here, one might reasonably assume that you care about things like Liskov substitution. Best of luck to you playing the odds in reliable software development.

                (After all, it's not as if signal handling in Perl is at all reliable, whereas noth

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.