i'll probably mess around with it some, at least maybe for identifing which complex your actually using (if you could easily tell the difference between a parrot complex and a perl complex it would be easier)

JimmyZ: thanks, this isn't so much what i want though, i'm curious how much or little of perl6 NQP (and PGE) are of perl6... there's no language spec that i know of, just wanted to know if anyone has documented the differences

btw... something was mentioned a _long_ time ago about jhiard(sp?) offering shell accounts to some people... I could check my logs about it (which would take quite some time BTW), or I can ask again here.

i have to say ruby and smalltalk have influenced my opinion on OO meta programming quite a bit, i have yet to find an OO language that rivals ruby for meta programming capabilities, but perl6 looks more like the kind of language i like all things considered, i like all the other features it has that aren't OO because OO isn't 'the one true way'

i think it kind of speaks for functional programming that in all the implementations i have seen they can never stay 'purely functional' and be a productive language, but many of the ideas from them have made there way into non-functional languages

in the DataMapper ruby library they effectively have a role called Resource that lets them turn any object into a persistable object without screwing up inheritence (so you don't have to inherit from some table class or w/e)

say you had a big project and wanted a few random bits of data to be persistent, thats where you could define a simple role to include in a few objects and have them behind the scene's know how to persist themselves based off the role rather than the more traditional approach of inheriting from some DB table object, which you see a lot of

i misunderstood the aim of the question. i wasnt asking why roles are a good idea, but why there would need to be a method called when composing a role into a class, in other words why would a progammer want to have access to such a method.

datamapper uses the included method to keep track of all of the objects that are supposed to be persistable too, so every time something includes Resource it adds that to another object to keep track of that

so you have Person, which includes Resource, so it knows to make a table called person, then you have Worker < Person, so worker is a child of Person, this shouldn't be a new database table, it should be STI

__ash__: yes, there are two classes of such problems. One is the so-called "inferior run-loop problem" when eval()s die under certain circumstances and are caught later on. The other one is quite new and we don't know yet what's the problem