This document is the beginnings of a "cookbook" for working with object oriented code in perl6. See below to learn how to contribute.
Caveats:
- This document has no official status whatsoever. It's not endorsed or approved by anyone. It exists solely to provoke discussion, gather comments, and eventually, after the Apocalypses come out, to gather the "best practice" solutions of the perl OO community.
- You can treat these recipes as a proto-FAQ: whenever an object-oriented discussion occurs on perl6-language, I will attempt to summarize the issues in question and add them here.
- If you are looking to this document to provide comfort that perl6 will look like perl5, don't -- at least not for a while. It will eventually gravitate towards that, but it isn't there yet.
Recipes:
So far, the recipes presented herein are intentionally abstract, in that they ask questions that can be asked of any object oriented language. Most have been directly or indirectly inspired by the RFCs, perl6-language, perl6-internals, the Parrot source code, previous Apos/Exes, etc.
Because the recipes present questions that will invariably be asked, most will probably make it into the final Cookbook -- but their answers may not. Indeed, the solution to some recipes may simply be "you can't do that". That is an acceptable answer, though hopefully an infrequent one.
Just because a recipe is here doesn't mean perl6 will support the solution out-of-the-box. Some things might be extensions that people desperately want, but are not part of the core.
Solutions, Examples & Discussion:
The solutions to each recipe are provisional: the source code presented lies somewhere between completely accurate and completely fictional, depending on the recipe. The "Status" of each recipe gives a rough indication of how accurate the recipe is considered to be. Each will gradually be modified to the "actual" approaches and syntax, as the appropriate Apos/Exes come out, and as the perl6 community adopts and extends those decisions.
Anything that is even more hypothetical than the rest of it (for example, keywords that are likely to change, behaviors that have big, big implications elsewhere, etc) is presented in red.
Status:
Each recipe is followed by a "Status" notation, which gives a rough, informal idea of how close the given solution is to the actual perl6 Ways To Do It. The scale is as follows:
| Accepted: |
The solution is confirmed, e.g. the appropriate Apocalypses have come out to settle the issues, the recipe has been edited to match, everyone agrees on the right way to do it, for some definition of "everyone" and "agrees". |
| Very Likely: |
The design team or other contributors have indicated their preference for the solution, at least as a working theory. |
| Likely: |
The solution would seem to logically fall out of previously determined design decisions. |
| Unlikely: |
The solution is probably going to be changed, as soon as it is decided what to change it to. |
| Rejected: |
The solution is confirmed not to exist, e.g. You Can't Do That. |
| Draft: |
The initial status of every recipe, until it's been edited to something else. |
Note that these status designations are arbitrary; just because something has been "accepted" doesn't mean it won't be un-accepted later. The designations represent a best guess at the current point in time.
Issues:
Recipes are occasionally followed by "Issue" notations. These call out particular issues, problems, or conflicts raised by the solution given. More typically, you can look in the discussion thread located under each recipe, where people will have raised more issues, questions, etc.
More FAQ
Is this Intended to Become Official Documentation?
I hope to be able to contribute it to the community as a small piece of the much-larger effort that will be documenting perl6.
Is this Intended to Become a Published Book?
Not at the moment. As you may have observed, it's just crude preliminary stuff. I suppose it is theoretically possible that parts of it *might* eventually find their way into treeware form, probably as part of a larger documentation effort (so if you post or email me a suggestion, I'm going to assume you intended to give me permission to use it) -- but I suppose it mostly depends on how much people want to contribute to it, and how encompassing we can make it.
Why isn't this a Wiki?
For now, I'm thinking the slight delay between any discussions and my summarizing them here as recipes is probably a Good Thing: I want this document to become a record of the consensus, and not of the back-and-forth discussions that led to it. Most of the Wikis I've seen have been of scattered quality, and could benefit from far more aggressive editing.
That doesn't mean we don't want your input! Indeed, this project will only be successful if you help: see How To Contribute for more information.
Are there going to be more recipes?
Tons more. I have about 250+ recipes already marked for entry somewhere, and that's just a few hours of brainstorming. I'll be putting them in as the perl6 design moves along. For now, I'm just putting the ones in that have the greatest implications.
What's this "Cognitivity" logo at the top of the page?
It's our company. We're donating the space to do this because we have a commercial product that's based entirely on perl5, and we are fully committed to converting it to perl6 as soon as it's available. We do customized online training software (CMS/LMS) for large & small corporations, so if you know anyone that needs a heavily customizable online training system, let them know about us. (And let us know that you referred them -- if they decide to purchase our services, we'll donate a commission to the Perl Foundation in your name.)
Mike Lazzaro
mlazzaro@cognitivity.com
