main bit This page looks very fancy in a modern browser, with "stylesheets" and "layout" and thing, but frankly I prefer the way you're seeing it here. Congratulations for not crumbling to the Browser Upgrade Initiative! Support the Web Designer Downgrade Conclusion!
a man slumped on his desk, from 'The Sleep of Reason Produces Monsters'



Damn, this looks really good, and I missed the first twenty minutes. 

In a nutshell, FIT is a wiki that interfaces to a unit test library. So anyone
can type in tests, run them, and check the results. The tests are defined in
Wiki tables, in HTML. The code is written in Perl, Python, Lisp, C# and Lisp.

This will teach me to stay home earning a living.

Brian about using FIT in Perl (this is where I come in), Test::FIT is an example

Brian (freepan guy) has a kwiki for every module directory in his Perl
makefiles, and it outputs the Kwiki data into a t/ directory, which runs the
tests in a Perl stylee. - so perl Makefile.PL; make test, will work fine.

Which means that if users find a problem, they can see output in an HTML file
generated in the t/ directory.

Module::Install - automatically installs modules when they need it. From CPAN,
I guess? Anyway, it gets around the problem of needing Test::FIT

Allows people to share Tests.

Multilingual modules -  the tests can be in anything. And you can point FIT
tests to anywhere, so people can build write FIT servers that can run tests on
other people's machines.

You can do transclusion: you can pull test tables from other people's sites.

Freepan = a CPAN for all languages, implementing the same modules in multiple
languages. (Brian felt "sorry" for languages like Python and Ruby that don't
have CPAN)

FIT could be the specification language for this.


Q. Usual question about wiki security. What about the bad people (where, as
OSCON, bad people is instantiated as "microsoft")

A. Usual answer. If people are bad, good people will fix it. It's not hard?

Q. What about really accurate test data, that gets munged by HTML:

Brian has Kwiki code to allow HERE documents.


And of course I missed the first forty-five minutes of the Damian and Larry
show, by virtue of spending my time missing the Ward talk.

They're currently talking about method invocation, and attributes, which are
the new, C++ish way of doing class stuff. By far the most interesting bit of
this so far is the "unary dot", which takes the default value as its invocant.
So you can have:

Attributes and methods really are new features. Classes look like this:

    class Blah {
        has Int $fred;
        has Str $sheila;

And methods are invoked using "." rather than "->". The old in-a-package
subroutine system works, but I imagine it's somewhat depreciated (and

Attributes are by default private to the object, but if you state that they're
public, accessors are automatically created, which you can override. So you
can fix broken public attributes.

There's a built-in Proxy object that lets you create objects that stand for
other objects, where you can just change individual behaviours.

Perl6 provides static inheritance, using traits. (I missed the trait bit, but
think of it as compile-time attributes)

class Animal is Lifeform {

Submethods is a method that does not get inherited. Useful to temporarily
change methods halfway down the hierarchy, but then restore the old root

Object construction: creation and initialisation are separated. 

You can inherit a "new" method, and there's a submethod BUILD which gets
called to initialise attributes etc.

Builds are called up the hierarchy as you go. All the BUILD's are called in
turn, so you don't have to override anything, and then call a super's

There's also a CREATE method, which overrides the *creation*, so you can set
up what object is created.

This is reassuringly making a lot of sense, even if my notes don't. I wonder
if it's not filling Perl with more baggage, but I think that's just a
transitional state. There are a lot of stuff in here where it's obvious what
the right thing to do is, once you shake away a lot of Perl5 thinking.

Allows multiple dispatch - where identically-named methods are called based on
what the classes are of the paraenters.

So if you have

multi handle(Window $a, Mode $b)
multi handle(VisibleWindow $a, OnMode $b)
multi handle(VisibleAndRoundWindow $a, OnAndDancingMode $b)

it'll pick the one that most closely describes the parameters.

"Like function overloading in C++, except it's not broken"

Actually, much more like Objective C, in its runtime.