A few clarifications were added to the original thread 'how typish are roles'.

In the subthread 'where constraints as roles', started by Trey Harris,
the discussion from the previous week continued.

Last week, Trey asked
if a where clause or junctive type defines an anonymous role, while
a type parameter defines a lexical role, and suggested adding this
information to S12. Larry Wall replied, saying that a where clause
is there for pattern matching...but went on to note other possibilities.
Jonathan Lang felt that S02 gave some indication of what Trey suggested,
and that where clauses and junctive types should not be turned in to
roles: roles and junctive types should be turned in to where
constraints.

Earlier,
TSa noted that multi-method dispatch is not yet in S06 and asked if
someone could explain the voting mechanism used to select the dispatch
target.

This week, Audrey Tang replied that the plan had been for Larry Wall to
review it in Brazil, but that it may now have to wait a while as Larry
cannot make it to Brazil. She tried to answer the question on voting,
and elaborated further on #perl6. TSa summarized her explanation.

Earlier,
in ticket [perl #40443], Matt Diephouse noted that it was decided
at OSCON 2006 that vtables and methods should be separated.

Jonathan wondered if this should be postponed until the object and namespace
issues have been dealt with. Allison Randal summarized the results of
her last conversation with Chip Salzenberg on the topic. Jonathan thanked
her for the specifications and said he would work on an implementation.

This week, Jonathan reported the implementation in r15039. Allison
suggested a two release cycle for deprecating the old syntax. A bug
she reported with Punie was addressed in r15048, but some tests continued
to fail (the bug was covered in
'[perl #40626] [BUG] :vtable fails for subclasses of core classes ').
There was further discussion about optimization, with it being
agreed that first the functionality would be added, and later the code
could be improved.

Jonathan Worthington noted that if you have a ParrotObject instance
and write $S0 = foo, $S0 will contain the name of the class. He
finds this problematic because you cannot overload what class it
stringifies to. He would like to get rid of this but asked if anyone
was relying on the current behavior. He wants to get rid of it in a
week.

Patrick R. Michaud joked that he thought a week was too long to wait
for its removal. He had no objections so long as tests still pass.
Allison Randal agreed with a week, provided tests pass.

Later, Jonathan wrote that he had been confused when he wrote the post;
the code is being used in PGE, for instance.

Bob Rogers considered different approaches to eliminating the continuation
barrier from action invocation and wondered if his latest idea was worth
pursuing. Allison Randal replied that she saw the temptation in the solution,
but was glad Bob had paused to ask because it would ultimately lead in the
wrong direction. They discussed the matter further.

Kevin Tew implemented :init some time ago but cannot check it in because
it requires a flag. Currently he is using PObj_private7_FLAG; Leopold
Toetsch suggested PObj_private2_FLAG but that broke tests. He would
like to know what flag he should use.

Jonathan Worthington asked if PObj_private3_FLAG could be used, as it
is labeled as unused.

Leopold Toetsch suggested 2 or 0. Kevin included his failing test results
with these flags.

Paul Cochrane reported a "is this still working" comment he found in
config/gen/makefiles/root.in. He found that it didn't work, and
wondered if this was something which should be fixed. If so, someone
else should look at it because Paul does not have privileges to do it.

In ticket [perl #40631], Jerry Gay requested some tests for native
PMC types in the t/pmc directory. At the moment there is just one test
for each which verifies if they can be created. The testing should be much
more extensive.