On Sun, Dec 14, 2003 at 09:05:37PM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: > I think the class is still the final arbiter of what its objects
: > are--there is no other entity that holds all the reins. If a class
: > chooses to include a role, and that role violates the normal rules of
:
On Sun, Dec 14, 2003 at 11:17:25PM -0500, Chip Salzenberg wrote:
: According to Larry Wall:
: > If, by the time the entire program is parsed, nobody has said they
: > want to extend an interface, then the interface can be considered
: > closed.
:
: What with C and its various wrappers, when can th
Larry Wall wrote:
> I think the class is still the final arbiter of what its objects
> are--there is no other entity that holds all the reins. If a class
> chooses to include a role, and that role violates the normal rules of
> roles, the class is still responsible for that (or else you need some
According to Larry Wall:
> If, by the time the entire program is parsed, nobody has said they
> want to extend an interface, then the interface can be considered
> closed.
What with C and its various wrappers, when can the program
be said to be fully parsed? <- anticipating "Mu"
--
Chip Salzenbe
On Sun, Dec 14, 2003 at 03:16:16AM -0600, Jonathan Scott Duff wrote:
: So, if we follow the rules in the Traits paper, a role may have no
: semantic effect if the object's class already provides the necessary
: methods. To *guarantee* that a role will modify an object's behavior,
: we need some sy
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Sat, Dec 13, 2003 at 01:44:34PM -0800, Larry Wall wrote:
>> On Sat, Dec 13, 2003 at 12:50:50PM -0500, Austin Hastings wrote:
>> : It seems to me there's an argument both ways --
>> :
>> : 1. Code written in the absence of a role won't anticipat
On Sat, Dec 13, 2003 at 01:44:34PM -0800, Larry Wall wrote:
> On Sat, Dec 13, 2003 at 12:50:50PM -0500, Austin Hastings wrote:
> : It seems to me there's an argument both ways --
> :
> : 1. Code written in the absence of a role won't anticipate the role and
> : therefore won't take (unknowable) st