Re: Solving compositional problems with Perl 6 roles

$elf does Thief; # hmm ... that reads funny

Maybe that's because when we coudn't divorce the person from their actions, naming a (sub)class Thief made sense, but now we can have groups of actions that can be enacted by a range of People, maybe we should name such groups by the collective term for those actions:

my Elf $elf does Thieving;
[download]

And

my $indivual is Employee 
    has HomeAddress, TelephoneNo, ParkingSpace 
    does Program, Manage, FirstAid;
[download]

I wonder if P6 will allow lists to does, is, has and the like? It would certainly make the syntax more friendly.

Reads quite nicely, and seems quite intuative that if the employee gives up first aiding, removing that Role has little impact on the rest of his persona. Maybe:

$individual stops FirstAiding;
[download]

Then that dear old Elf from earlier sees the light and repents:

$elf stops Thieving;
[download]

Of course, it doesn't flow completely right. There would be no point in:

$indivual does Thieving;
[download]

Unless the compiler has the smarts to turn that into:

$individual isn't Employee;
[download]

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Comment on Re: Solving compositional problems with Perl 6 roles Select or Download Code

Replies are listed 'Best First'.
Re^2: Solving compositional problems with Perl 6 roles by dragonchild (Archbishop) on Aug 22, 2004 at 03:09 UTC
That would imply that the possession of one trait implies the removal of another. Now, you're starting to talk Prolog-style levels of compiler knowledge. While this wouldn't necessarily be a bad thing, and would be implemented in the definition of the trait, I can see how this would be quite reasonably construed as some serious action-at-a-distance ... ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^3: Solving compositional problems with Perl 6 roles by BrowserUk (Patriarch) on Aug 22, 2004 at 03:45 UTC
I'm not sure what you mean by "That..."? `... does Program, Manage, FirstAid;` [download] was meant to imply the equivalent of `... does Program does Manage does FirstAid;` [download] with `$individual stops FirstAid;` removing the latter Role when appropriate. Unless your referring to the last bit about the compiler mapping `$individual does Thieving;` to `$individual isn't Employee;`, in which case, my attempt at humour failed completely. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply] [d/l] [select]
Re^4: Solving compositional problems with Perl 6 roles by dragonchild (Archbishop) on Aug 23, 2004 at 12:16 UTC
Actually, I think that your attempt at humor was actually a good idea, in disguise. I can see where one would like roles to be exclusionary - if `$foo does X`, that means you cannot have `$foo does Y`, so there should be a way of specifying that in the definitions of X and Y. But, as I said earlier, this is starting to sound like Prolog. (Not necessarily a bad thing, mind you ...) ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply] [d/l] [select]
Re^2: Solving compositional problems with Perl 6 roles by Ovid (Cardinal) on Aug 22, 2004 at 06:09 UTC
I wonder if P6 will allow lists to does, is, has and the like? It would certainly make the syntax more friendly. Yes, but how would it be implemented? When you have a variadic operator, how do you avoid slurping up the rest of the line? If only one argument is allowed and the operator always return the object it's acting on, the current chaining idiom works. Cheers, Ovid New address of my CGI Course.	[reply]
Re^3: Solving compositional problems with Perl 6 roles by BrowserUk (Patriarch) on Aug 22, 2004 at 07:10 UTC
I'll admit to having very little idea of what problems that would cause for parsing. I guess the list could be bracketed, but that wouldn't look so nice. Another alternative is to have the list terminated by the presence of the next keyword which may be possible, but could also be a problem depending on how the parser is implemented. Another is that the absence of a comma after the final argument is indicative of the end of the parameters for that operator, so the next token must be a new operator (or the end of statement. SQL parsers seem happy to cope with comma seperated lists of args between keywords. How much difference there is between that and parsing Perl I'm not sure. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks