Re: Re: Re: Often Overlooked OO Programming Guidelines

[ysth]

I disagree with the categorization of Perl's OO as a hack. I think it provides the minimal tools as part of the core language, and gives lots of room for addition, restriction, expansion, and factorization. This is evidenced by the wide variety of modules to change/enhance/replace/invert/etc. perl's core object model.

Whether it is good to have such a plethora of ways and means (that you have to go looking for) instead of a Single True Way To Do It, Blessed By The Core, is a separate discussion.

Update: Yes, Perl OO is constrained, and yes, it was grafted onto an existing language; I don't agree that the constraints are a consequence of the grafting. I think they are an intentional design decision (though from recent evidence, Larry wouldn't make the same decisions now).

Update: Seems we just disagree on what hack means. To me it means poor features based on external constraints (whether that be time, backward compatibility, grafting new features onto old code, or whatever). I think the limitations of Perl OO due to intentional design, not constraint, so I would call it minimalist rather than hacked.

Update: Perl has no useful subroutine prototypes even for non-methods, by the definition of prototypes in other popular languages. The purpose of Perl prototypes (user subs that work like builtins) doesn't apply to object methods.

Update: It's strange to see multiple inheritance cited as a reason to call Perl OO hackish. It's the one feature that isn't what I would call minimalist. It's also hard to see how you could accidentally use it. It's not my fault, Officer, the language made me use multiple inheritance. Click go the closing handcuffs.