Perl 6 using Perl 5 modules
When the official release of Perl 6 is released and I start to write some Perl 6 programs using Perl 5 modules, will I get any errors? How will this be handled? Will all of the Perl 5 modules have to be ported over and converted to Perl 6 code? Can I have a basic perl6.pl file while using the standard perl 5 IO::Socket module or whatehaveyou?
Re: This week's summary
A. Pagaltzis [EMAIL PROTECTED] writes: * The Perl 6 Summarizer [EMAIL PROTECTED] [2003-12-16 11:57]: bear in mind that the authors of the paper use the term 'trait' for what we're calling a 'role' (We already have traits you see). http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf -- Traits paper I think it deserved mention that at least Larry has taken to capitalizing Trait when referring to the paper's idea of Traits that we call roles, and leaving trait lowercased when referring to traits of the Perl 6 fashion. I'm reasonably sure that Larry hadn't actually mentioned this at the point when I wrote the summary. -- Beware the Perl 6 early morning joggers -- Allison Randal
Nature of traits
I've just been rereading the recent discussions, and I noticed something that I missed the first time: Larry Wall wrote: Traits are not definitional but rather operationally defined in the worst way. That's why traits are renegade roles. They don't play by the rules. In other words, a trait effectively has an installer routine which gets run whenever you apply it to a particular object (that is, is const calls const::INSTALL or something of the sort). I've been trying to puzzle out what the distinction between roles and traits is so that I can understand why traits need to be handled differently than roles are - in particular, I was thinking in terms of why traits don't fit into the order of precedence for method calls (that is, class || role || superclass). If I'm right about the installer, the answer would seem to be that the trait gets to choose (by means of the installer) where it fits into said chain, if at all - it could insert itself into the class's ISA list, tell the class to treat it as a role, or maybe even wrest control from the class, effectively treating the class definition as a role or superclass of its own and then masquerading as the class to outsiders (effectively putting itself ahead of the class in the order of precedence chain). Or it could do none of the above, thus requiring its namespace to be explicitly referenced if you want access to any of its methods or attributes. The point is that - if I'm understanding the current thoughts on the subject - the difference between a trait and a role is that a trait's interaction with a class is programmable. How am I faring? = Jonathan Dataweaver Lang __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Re: Nature of traits
Jonathan Lang writes: I've just been rereading the recent discussions, and I noticed something that I missed the first time: Larry Wall wrote: Traits are not definitional but rather operationally defined in the worst way. That's why traits are renegade roles. They don't play by the rules. In other words, a trait effectively has an installer routine which gets run whenever you apply it to a particular object (that is, is const calls const::INSTALL or something of the sort). I've been trying to puzzle out what the distinction between roles and traits is so that I can understand why traits need to be handled differently than roles are - in particular, I was thinking in terms of why traits don't fit into the order of precedence for method calls (that is, class || role || superclass). If I'm right about the installer, the answer would seem to be that the trait gets to choose (by means of the installer) where it fits into said chain, if at all - it could insert itself into the class's ISA list, tell the class to treat it as a role, or maybe even wrest control from the class, effectively treating the class definition as a role or superclass of its own and then masquerading as the class to outsiders (effectively putting itself ahead of the class in the order of precedence chain). Or it could do none of the above, thus requiring its namespace to be explicitly referenced if you want access to any of its methods or attributes. The point is that - if I'm understanding the current thoughts on the subject - the difference between a trait and a role is that a trait's interaction with a class is programmable. How am I faring? That seems to be it. A trait, from the user's perspective, is something declarative that happens other than inheritance or role composition. If you're wondering why roles aren't unified with traits, it looks like a linguistic thing. We only have so many naming conventions. Traits are the catch-all of encapsulated behavior. You put something that happens behind a name, and it does what it needs to in order to fulfill its duty. For the things more specific, there are concepts more specific. I think traits are a brilliant idea though. If you're going to hack, it's nice to have a standard way to encapsulate the hack. Luke