in reply to Re^6: OO automatic accessor generation
in thread OO automatic accessor generation

I won't bother commenting on your "all OO code is doing it wrong" rant as you and I have already been down that road many times and we will never agree and so it is not worth going down it again.

However, there is maybe some merit in my suggesting that Moose might also allow one or more compile-time switches to disable the creation/costs of the methods and data required to provide for deep introspection, for those classes that do not use it?

There is a lot of work going on to do exactly this. The idea is to basically "compile" the metaclasses and accessors once and cache them (the exact details of how that is accomplished is still up in the air). This would remove much of the Moose startup penalty and memory cost involved with metaclasses and would open the doors for other possible optimizations. I doubt though that we could replace method access with direct hash access since that involves compiling the call site and not the class itself and that can get really hairy really quickly.

As for your idea that type/range checking is only useful during development, I disagree (SHOCKING ISN'T IT!). In languages like O'Caml, the compiler does sophisticated static analysis/type inference to make sure that type usage is consistent throughout the program. Because of this O'Caml can ditch all type information at runtime, which helps to contribute to it's very fast runtime performance. Doing such a thing with a dynamic language like Perl where static code analysis is all but impossible would be a bad idea. It would be like not checking your parachute before jumping from an airplane because last time you jumped everything worked just fine.

-stvn

Replies are listed 'Best First'.
Re^8: OO automatic accessor generation
by BrowserUk (Patriarch) on Nov 12, 2009 at 22:09 UTC

    I never said ""all OO code is doing it wrong". Just a lot of it. And it's not because the code is OO, but because it pseud-OO. Ie. It misses the important points of proper OO. I like OO, when it is done properly.

    I also never said "ditch all type information". I am suggesting--actually stating--that once classes have been properly unit tested, you only need verify parameters at the public/private interface. It called Design by Contract. Read Meyer and argue with him if you still disagree.

    When public method parameters have been type and range checked on input and their algorithms have been verified, there is negligable benefit and considerable cost in indirecting attribute access in order to re-verifying attribute values derived from those inputs and algorithms.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      I am suggesting--actually stating--that once classes have been properly unit tested, you only need verify parameters at the public/private interface.

      The idea that you can unit test all possible inputs and all the possible permutations of their internal interactions, and that this is enough to ensure proper type usage, is just naive. It makes the assumption that the design will be frozen and especially in a language like Perl where a simple bit of anti-social code like *{BrowserUK::ClassFullOfAwesome::tested_method} = sub { ... } is possible, that is a bad assumption. This is not to say that in a disciplined shop where no one ever takes a shortcut due to an unrealistic deadline or idiotic business requirement this could not be true, but I have never heard of such a place. It has been my experience that when something that shouldn't happen happens, it is nice to have as much information as possible so that it can be reproduced and the whole plugged or bug squashed, retaining any and all type constraint checking in production means that I have all this information at my fingertips.

      /me adds one more thing to his running list of "Things BrowserUK and I will never agree upon" ...

      It called Design by Contract. Read Meyer and argue with him if you still disagree.

      I like Meyer and have read him extensively, but he pretty much just talks about Eiffel and OO theory as it pertains to his idealistic Eiffel colored world. As for Design By Contract, I am not a huge fan, there are some good ideas but I much more prefer the type system of ML/Haskell. Of course the tradeoff is that polymorphism is much harder in ML and Haskell (Haskell typeclasses go a long way, but it's still not OO level polymorphism), but every language has it's pros and cons.

      /me adds DoC and Meyer to the list now too ...

      -stvn
[reply]
[d/l]
        The idea that you can unit test all possible inputs and all the possible permutations of their internal interactions, and that this is enough to ensure proper type usage, is just naive.

        No! I'm not.

        I'm saying that if the input types to an algorithm are both type-checked & range-checked, then the ranges and types of the outputs will be consistant. There is no need to re-check those derived types and ranges. There is no need to check all possible permutations, only the boundary conditions--and thats a given.

        A challenge: Demonstrate otherwise?

        It makes the assumption that the design will be frozen and especially in a language like Perl where a simple bit of anti-social code like *{BrowserUK::ClassFullOfAwesome::tested_method} = sub { ... } is possible, that is a bad assumption.

        You are suggesting that you need to protect against the possibility that someone will make modifications to production code to override methods at runtime. Why? So that you can tell them what they did wrong.

        I guess our undestanding of what constitutes "production code" varies.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Meditations