As sort of an academic exercise, I've been thinking about how one could re-envision Perl's object model using closures as objects, without using the bless() function (because otherwise, of course, that's not really re-envisioning Perl's object model — it's just modifying it slightly). The current stumper in this endeavor for which I'm considering possible approaches is how to handle inheritance.
It occurs to me that to play to the strengths of a closure-based object model, one should not simply parrot the implementation of inheritance (or other OOP characteristics) from some other object model. Rather, the concept of inheritance (via mixins, class hierarchy, whatever) should be deconstructed to arrive at a set of base benefit requirements. This might be a menu from which appetizers and entrees need to be chosen according to rules of good taste or (preferably) it may even be possible to boil it all down to a single set of roughly universal basic principles of the benefits of inheritance.
When a client says to you "I need you to design an e-commerce system for me," that's great. You know what you're aiming for in a very general sense, the same way you know what you're aiming for when you say "I need to come up with a means of implementing inheritance in this object model." It doesn't really tell you what that design needs to accomplish in any specific terms, though. You'll have to discuss the needs of the client's web presence and business requirements to deconstruct the larger "e-commerce system" solution into a set of project requirements. That's the sort of thing I'm looking for with regard to coming up with a means of implementing inheritance via a closures-based object model in Perl.
That being said, I'm open to ideas. I have some ideas about how to proceed, but they're half-baked at best and I don't want to pollute the waters from which your mudpuppy-like (edit: I mean that in the best possible way, as a metaphor for "leading to great things from humble origins", or something — okay, so my metaphors need work) suggestions and inspirations might evolve into lungfish, ultimately providing me with the basis for the development of a full-fledged air-breathing mammal (or system of inheritance, as 'twere).
Note that one doesn't necessarily even need to know much about closures, et cetera, to be able to contribute to this. The real point of this meditation is to examine what's needed of a "new" implementation of inheritance. Of course, ideas that apply specifically to what I'm trying to do would be greatly appreciated.
After some comments below, I've refactored the core question of this as follows: What are the fundamental problems inheritance is meant to solve, and how can we solve them in relation to a closure-based object model for Perl 5.x?
|print substr("Just another Perl hacker", 0, -2);||- apotheon
CopyWrite Chad Perrin
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||