Re: A thought for later -- POD tables
Aaron Sherman <[EMAIL PROTECTED]> wrote: > Still, tables are useful, so here's a simple way to get the kind of > table we see above, without the HTMLish trap of pseudo-layout: > > Because one of the features of POD is that documentation tends to be > readable in markup form, an C<=>-introduced markup seems like it would > not work well. Instead, we use C<< H<...> >> (headings) and C<< T<...> > >> (table body) like so: > > H< C<$_> | C<$x> | Type of Match Implied | Matching Code > > T< Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> > I worry that, with that syntax, someone might try to nest a table. I also think that the H<>/T<> syntax is a bit wrong--to use CSS terminology, tables are a block construct, not an inline one.[1] Instead, I'd recommend something like this: =table C<$_> | C<$x> | Type of Match Implied | Matching Code =row Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> (I'm not sure how good the alignment is on that--Gmail's compose window uses a variable-width font.) This makes it syntactically impossible to nest a table, removes the slightly odd-looking H<>/T<> syntax, and is still very readable. It's also not dependent on the distinction between tabs and spaces (see 'make' for why this is a Good Thing). To help deal with wide tables, lines that don't have a =table/=row directive (but do have other content) would be appended to the previous line: =table C<$_> | C<$x> | Type of Match Implied | Matching Code =row Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> [1] Actually, in CSS a table is neither an inline nor a block construct--it's considered its own category, because normal block constructs have a default width of 100%, while tables are only wide enough to hold their contents. Same difference... -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker There is no cabal.
Re: A thought for later -- POD tables
Brent 'Dax' Royal-Gordon wrote: Aaron Sherman <[EMAIL PROTECTED]> wrote: Still, tables are useful, so here's a simple way to get the kind of table we see above, without the HTMLish trap of pseudo-layout: Because one of the features of POD is that documentation tends to be readable in markup form, an C<=>-introduced markup seems like it would not work well. Instead, we use C<< H<...> >> (headings) and C<< T<...> >> (table body) like so: H< C<$_> | C<$x> | Type of Match Implied | Matching Code > T< Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> > I worry that, with that syntax, someone might try to nest a table. I also think that the H<>/T<> syntax is a bit wrong--to use CSS terminology, tables are a block construct, not an inline one.[1] Instead, I'd recommend something like this: First off, I agree that looking at CSS makes sense as a point of reference, but this should make just as much sense for troff, texinfo, ps, text, etc. A header+table lines work just fine for an internal representation, and there are times you want to say: Function Name Developer Time Table foo() ajs1mo. bar() brent 2dy. fiz() larry 2mo. Release name QA Testing Time super_foo()randal 2wk. mega_bar() dan3wk. and so on. The idea being that sometimes you wish to re-head your columns witout re-calculating layout, which is why I chose a heading and table pair. =table C<$_> | C<$x> | Type of Match Implied | Matching Code =row Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> That's (the above comments aside) the same thing, and as I said when Luke suggested it, it seems fine if that's the way we'd prefer to go. I do want to make sure that there's some way to associate a caption, though. HTML doesn't have a real caption concept, but many markup languages do. Is the general consensus,then, that an C<=>-introduced form would be better? I do agree that we don't want the capability to nest tables, as that DOES break POD down into a presentation system, which it was never meant to be. So perhaps the balanced syntax is too misleading there.
Constructors and mixins
Sorry if this has already been asked and answered, but in doing a little research
about Perl 6
mixins (http://www.perlmonks.org/index.pl?node_id=384858), I ran into some questions
that I
couldn't figure from either A12 or "Perl 6 and Parrot Essentials."
First, how does one access the instance in a constructor? Let's say I need to create
a child node
of a parent node:
method new(Class $class: Node $parent) {
$:parent = $parent;
my $self = $class.bless(0, $parent); # is this correct?
$parent.add_child($self);
return $self;
}
I'm also trying to figure out method disambiguation with mixins. A12 states that
mixins are to be
implemented via anonymous inner classes and related via inheritence. Thus, a later
mixin will
override a previous mixin, but this seems to cause the problems we already have with
mixins:
$driver does SanitationEngineer does RaceCarDriver;
So my $driver who does some racing as a hobby now has no choice but to drive his dump
truck like
mad through the streets. That dump truck had better have darn good brakes. Is there
some other
method (pun not intended, but I'll take it) of disambiguating these? The delegation
syntax looked
promising, but it seemed to be a compile-time tool.
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Constructors and mixins
On Sun, Aug 22, 2004 at 08:04:48AM -0700, Ovid wrote:
: Sorry if this has already been asked and answered, but in doing a little research
about Perl 6
: mixins (http://www.perlmonks.org/index.pl?node_id=384858), I ran into some questions
that I
: couldn't figure from either A12 or "Perl 6 and Parrot Essentials."
:
: First, how does one access the instance in a constructor? Let's say I need to
create a child node
: of a parent node:
:
: method new(Class $class: Node $parent) {
: $:parent = $parent;
You can't set a private attribute before there's an object. And in general
these things should be done in the BUILD routine, which is an instance
method, rather than the constructor, which is a class method.
: my $self = $class.bless(0, $parent); # is this correct?
No, has to be named notation.
: $parent.add_child($self);
That would work since the object is explicit.
: return $self;
: }
:
: I'm also trying to figure out method disambiguation with mixins. A12 states that
mixins are to be
: implemented via anonymous inner classes and related via inheritence. Thus, a later
mixin will
: override a previous mixin, but this seems to cause the problems we already have with
mixins:
:
: $driver does SanitationEngineer does RaceCarDriver;
That's just a problem with run-time mixins in general if you can't know
in advance that you're going to want both roles. That's why we
encourage as much of that to be done at compile time as possible.
There is a little hope, though. You can't do the binding above at
compile time, but you could make a compile-time role that does both
those things and decides how to mediate them, then mix that role in
at run time.
You can also create your own anonymous class at run time that incorporates
both roles simultaneously and disambiguates them. But you still have to
know that you're going to want both.
: So my $driver who does some racing as a hobby now has no choice but to drive his
dump truck like
: mad through the streets. That dump truck had better have darn good brakes. Is
there some other
: method (pun not intended, but I'll take it) of disambiguating these? The delegation
syntax looked
: promising, but it seemed to be a compile-time tool.
Roles can encapsulate delegation. Dunno if that helps you.
In my experience, race car drivers *do* drive their trash trucks like
they're in a race. At least, I assume my local trash truck drivers
are also racers from their behavior...
Larry
Re: Constructors and mixins
Larry wrote:
You can also create your own anonymous class at run time that incorporates
both roles simultaneously and disambiguates them.
Or, presumably, you could use an anonymous role directly:
$driver does role {
does SanitationEngineer;
does RaceCarDriver;
method drive {
given .vehicle {
when Truck { goto &SanitationEngineer::drive }
default { goto &RaceCar::drive }
}
}
};
Damian
