pugs.blogs.com | pugscode.org | pugs.kwiki.org | paste: sial.org/pbot/perl6 | <stevan> Moose... it's the new Camel ":P | .pmc == PPI source filters!
Set by Alias_ on 16 March 2006.
00:00 mncharity joined
mncharity I had a very odd dream last night that people had forgotten that pugs oo wasn't working, were energetically puzzled by no one writing big oo projects over the last year, and were mad at me for not telling them! :-) 00:06
So, I note, class A {has $.x;} sub f(){A.new} f().x remains unchanged. 00:07
00:10 llp joined, justatheory joined 00:22 rashakil joined 00:31 Quell joined
mncharity & 00:35
00:36 penk joined, pen1 joined
meppl gute nacht 01:02
01:06 flounder99 joined 01:15 oylenshpeegul joined 01:23 Ymmv joined 01:35 jserv-- joined
svnbot6 r10359 | lwall++ | CGI util test had bogus eval 01:38
theorbtwo - 01:41
01:46 oylenshpeegul left
TimToady I have just realized that pugs tests misuse "not" as a unary operator all over the place when it's currently defined as a list operator. Hmm. 01:52
01:58 _SamB_ joined
TimToady that's interesting...true 1,2,3 does not parse the same as not 1,2,3 02:01
02:01 llp left
audreyt because not is listop 02:20
why is "not"listop again? 02:21
02:28 mako132_ joined, bsp joined
audreyt currently not is a listop that returns undef on 0arg, True if all args are false, and False otherwise 02:29
I wonder why is it specced that way in p5 :) and also why "true" doesn't work the same way as "not"...
(or vice versa)
FurnaceBoy so... 02:31
it's really not(a || b ...)
TimToady just rewrote the precedence table... 02:32
FurnaceBoy "none of"
TimToady actually, I think we can combine comma with listop while we're at it. 02:34
with a little handwaving... 02:35
I think we aren't going to be able to teach people not to write things like: 02:36
ok not -r 'doesnotexist.t', "-r returns false on non existant files";
audreyt which means not becomes unary?
TimToady see S03 :)
audreyt (and do we go ahead with the plan of killing the ?=$_ for unaries)
TimToady I think so. 02:38
audreyt k 02:40
02:41 hikozaemon joined
pmichaud takes a peek at S03 02:47
TimToady hang on, updating again. 02:49
pmichaud okay
TimToady svn up or wait for p6l logger 02:50
pmichaud svn up'd 02:51
interesting that 'and' is combined with '<==' 02:52
TimToady not anymore 02:53
pmichaud oh, sorry, wrong message
02:53 justatheory joined
pmichaud okay, so to make sure I have this right 02:54
TimToady the "loose unary" category now maps nicely to the "everything tighter than comma" category.
pmichaud foo 3, bar 4 parses as foo(3,bar(4)) (more) 02:55
TimToady listops still parse pretty much exactly like they did before.
pmichaud foo 3, bar { baz }.xyz parses as foo(3, bar({baz}).xyz) ?
02:55 Quell joined
TimToady I think that's probably the most natural interpretation. 02:56
pmichaud okay, good, because that's what my parser will likely do
pmichaud tests
TimToady I'm wondering whether we can make foo 3, bar { baz };.xyz mean the other thing. 02:57
pmichaud no, please
TimToady at some point parens are fine
pmichaud that looks to me like foo 3, bar { baz }; $_.xyz
TimToady It would just be applying the postfix rule to a statement, but yes, it would drive the golfers nuts. 02:58
pmichaud "at some point parens are fine" :-)
TimToady Anyway, listops are all kinda weird anyway, so we can just handwave them all to the same precedence level, given it's kinda sort left-associative when it's not being list associative anyway... 03:00
*sorta
pmichaud TimToady: works for me 03:04
TimToady and I'm happier with "and" separated out from the pipes.
pmichaud definitely -- that looked very odd 03:05
TimToady probably easier to remember that way despite being an extra level.
audreyt makes sense.
pmichaud and it's official that the named unaries always have an operand?
i.e., don't assume $_ ? 03:06
TimToady yes.
pmichaud excellent
audreyt but what about -e ?
and "exit"? 03:07
TimToady speaking of which !-e "foo" doesn't parse
exit; is a term.
audreyt exit 1;
so exit is still "optional unary"
TimToady that's a named unary. :)
only if MMD lets us.
audreyt i.e. it has both () and ($) forms
which is not at all diff from ($?) forms
since it needs to be parsed as both term and unary 03:08
TimToady I'm getting rid of the $? forms because it duplicates the .foo forms mostly.
audreyt unless we say that exit() must be written as such when ambiguous
TimToady just make it a listop?
audreyt so ($?) becomes listop
is that the idea? 03:09
TimToady lemme think
audreyt (-e becoming a listop would be odd.)
pmichaud (fwiw, I still don't have an issue with optional arguments to named unaries, I was just asking)
TimToady I think we just require exit() if ambiguous. 03:10
audreyt (I think defaulting to $_ can go, but other forms of defaulting still introduces ambig, and we need to bias against ($))
so ($?) parses as ($) and require () for the () variant
say exit; # fine 03:11
TimToady require () when ambiguous, you mean
audreyt say exit < 3; # not fine
yes
TimToady yes, shift over reduce.
"longest token'
audreyt which is not different from how PGE and Pugs treat them currently
TimToady or P5, for that matter. 03:12
audreyt right. ok. so, what about -e?
simply require
-e $_
?
.file_exists ?
TimToady or .is_exists?
audreyt .is_exists
TimToady .is_dir etc.
.is_there?
audreyt was thinking about that
"no it's here, not there" 03:13
TimToady .is
audreyt too confusing with trait auxisllary
TimToady yeah...
audreyt ._e
TimToady yeah, I was just wondering that myself
audreyt may not be a bad idea 03:14
TimToady but also wondering about _e $file
audreyt that is, remove the conflict with unary -
TimToady seems a bit gauche.
pmichaud =e
audreyt "lacking social polish"
pmichaud oh, nm
won't work as .=e
audreyt TimToady: if there is a postfix "int" 03:15
what does
TimToady .-e is actually available, for all that.
audreyt $foo.int
prefer?
or, better example, postfix factorial !
$num.!
does it go to prefix or postfix?
why is $x.++ prefer potfix
postfix
but $x.meth calls meth($x)? 03:16
or is it "if there is postfix, use that"
otherwise use prefix?
because if that rule is in place
then .-e works.
TimToady cause nobody defined postfix:<meth>?
audreyt yeah, that's what I'm wondering
i.e. the $foo.meth call is actually a fallback to prefix 03:17
TimToady foo() is already ().foo
audreyt and would parse as "$foo meth" when got a chance
TimToady semantically
huh?
audreyt but if we have both prefix ! and postfix !
then "! $x" and "$x !" parses differently
and we said that "$x.!" prefers postfix
but if no-one defines postfix !, and there is already prefix ! 03:18
TimToady $x ! is always illegal
audreyt maybe we can get "$x.!" parse as prefix
nono, I mean someone defined
sub postfix:<!> ($x) { [*] 1..$x }
TimToady yes, but the syntax "$x !" is illegal. no space allowed.
audreyt ok. then "$x!" vs "!$x"
TimToady I with you on the semantics
audreyt so if there is no postfix:<!> defined yet 03:19
then "$x.!" goes back to "!$x"
but "$x!" is parsefail
and that gains us ".-e"
TimToady right.
audreyt interestingly that means ".-----" is a provisional call on ----- 03:20
TimToady well, assuming that the declaration of prefix:<-e> makes it syntactically visible as postfix:<-e> but not, er, as a postfix.
audreyt or maybe we do require that a prefix prototype is already seen for non-identifiers
yes, that you said.
but ".unseen" is always provisional call
TimToady yes, falls out for idents 03:21
audreyt it's only on ".--something-not-identifier" we need a predeclaration of either pre or post
ok, I like that.
TimToady affix:<-e>
audreyt I think simply "postfix:<-e>" is sufficient :)
er I mean
prefix:<-e>
TimToady except that allows $x-e
audreyt right, typo 03:22
TimToady and if you want to disallow it you declare your own postfix.
hmm.
audreyt makes sense
TimToady what if there's a conflicting infix
audreyt I like .-e a lot more than .is_exists
TimToady: longest token 03:23
TimToady oh wait, there's always a dot
audreyt .--moose-declared trumps .--moose - declared
if it's declared
yup
pmichaud yes, essentially the dot rule becomes something like <dot> <%postfix|%postcircumfix|%prefix> ?
preferring postfix and postcircumfix to prefix?
TimToady yeah.
audreyt *nod* 03:24
and a |<ident> finally
TimToady sneaking <[=*+?]> in there somehow
heh. foo().@ 03:25
audreyt fortunately -e is not [=*+?]
wow. useful.
@$_ becomes .@
TimToady ().$ 03:26
one little problem $x.$method 03:27
audreyt put that before ident 03:29
03:29 FurnaceBoy_ joined
TimToady but it would see .$ before that. 03:29
audreyt before ident = same as prefix
so longest win
var is longer than a simple $
pmichaud but we can't look up from the hash
TimToady we can't put all those into the hash.
pmichaud <%prefix> 03:30
it'd have to go before the <%postcircumfix|%postfix|%prefix>
TimToady well, the .$ rule could resolve it its own self.
audreyt and require 2char lookahead
that too
03:30 KingDiamond joined
TimToady we can perhaps allow postfix:<.$> with an explicit dot to allow only the dot form. 03:31
pmichaud TimToady: just committed the revised grammar with the updated <?ws> and long dot rules 03:32
TimToady pmichaud++
pmichaud (in case you want to peek when you get a chance)
TimToady still don't know what my chances are the next few days... 03:33
pmichaud it still has the issues with precedence among prefix/postfix, but we'll cross that bridge when we get there :-)
TimToady: np, thanks for the help on it 03:34
audreyt what does $obj.@methods mean anyway?
what bout $obj.%method_name_and_arguments?
TimToady those don't mean anything right now. 03:35
audreyt nod, mostly because they are illegal in p5?
TimToady we could break .$method and force it more symbolic defer-like
though .($method) doesn't work...
and .::($method) kinda gives the wrong idea. 03:36
audreyt .$method is a symbolic lookup
and never treat $method as anything but a string, right?
TimToady right.
audreyt then probably keep it that way is fine
may make sense to generalize to .@method 03:37
TimToady so .::($method) works, but kinda implies there's a package name on the front.
audreyt yeah.
TimToady .*@method maybe.
.?$method
audreyt yeah.
though .?$method lose the "fail if lookup fails" 03:38
otoh, it's much more likely to fail when you put names into a var
pmichaud back later 03:39
audreyt otoh, I think $obj.$method is p5ish and worth keeping. maybe .@meth and .%meth should not work after all
TimToady .+$method isn't quite right either. Want .**{1}$method
audreyt well, I proposed .:$method for that but that was shot down...
TimToady .:method($method) 03:40
audreyt yeah. bad idea
TimToady reminds me of the lying P5 exec semantics...
audreyt I think the parser can work with .$method
TimToady me too.
on the other hand, .::($method) would be more consistent with other sym stuff 03:42
and $::("foo") doesn't imply any package either.
audreyt and it's fortunately in tokyo to said :: is not a prefix caster. 03:43
(that's not english, mostly because I'm multitasking on visa stuff :))
(if it's caster than it would mean .prefix:<::>(...))
so .::($method) can work 03:44
and would make hobgoblins happy
TimToady though we currently have Package.::.{$sym}
03:45 scw_ is now known as scw
audreyt Package.%.{$sym} 03:45
according to the new pre-as-dot-post rule.
03:46 particle_ joined
TimToady Hmm %(Package) is different from %Package. 03:46
audreyt that falls out from symderef-requiring-:: 03:47
so was like that for some time now
maybe it's possible to have just Package.{$sym}
TimToady arguably longest token is ::( there
and do metatype stuff with .[] and .(), I guess. 03:48
or ^Packge 03:49
little problem that ^foo as a unary operator is looser than ^foo.bar 03:50
But don't really want to make ^Dog a special form.
since that would clobber ^int($x) and such.
so we might end up seeing a lot of (^Dog).methods and such. 03:51
unless we go with something else for .meta shorthand.
03:51 _SamB_ is now known as SamB
TimToady Maybe it's all Dog.^methods and such. 03:52
same problem with prefix:<^>, same solution...
and I guess ^Dog could still be the metadog as long as people don't expect to write ^Dog.methods 03:54
"everything in the range of Dogness"
audreyt Dog.^method is the same as 03:55
Dog.^.method
so I don't see a big difficulty in explaning the .^method form
TimToady cool
audreyt cool. I look forward to spec :) will fix -e and make .prefix work 03:56
TimToady Cat^..^method
audreyt $foo.+++ means calling postfix ++ with + semantics
strange but true 03:57
bbiab :)
04:06 penk joined
TimToady I don't see how. It'd have to be $foo.++.+ since we require dot on prefix-as-postfix 04:11
the only other parse is $foo.++ + where final + is infix
But a .+.++ parse would require violating longest token.
audreyt $foo.+method 04:17
calls all methods (1 or more) 04:18
principle of most surprise
or the meth modifier doesn't apply to symbolics?
because $foo.+int should work.
04:25 KingDiamond joined
TimToady I think $foo.+::("++") would actually be clearer... 04:27
or $foo.+postfix:<++> 04:29
so I'm inclined to say that the .+ forms have to be alpha (or maybe ::) 04:30
04:35 kanru joined
audreyt so there needs to be two hashes 04:37
one for symbolic unary one for named unary
TimToady why? 04:39
audreyt because one is subject to + and one is not 04:40
"int" is named unary
"-e" is symbolic unary 04:41
.+int works, .+-e not.
TimToady -e is named unary
the constraint has nothing to do with precedence level
audreyt ok. still
right. sorry. I meant ident unary
and nonident unary. 04:42
TimToady that I'll grant you
$x.say("me too") 04:43
prefix:<say>
probably prohibited with extra args 04:47
that is, the prefix-as-postfix fallback.
100.^(:by(2)) 04:48
05:14 elmex joined 05:34 Quell joined
svnbot6 r10360 | lwall++ | Whacked a lot of the =$+_ defaults. 05:39
05:41 Quell joined 05:44 Quell joined 06:19 tardisx joined 06:32 marmic joined, iblechbot joined 06:56 kanru joined
gaal antlerless brown moose sleep ferociously 06:58
07:01 avar joined 07:12 neoesque joined 07:38 elmex joined 07:40 kane_ joined 07:59 kanru joined 08:02 froh-doh joined 08:15 lypanov joined 08:19 bsb left 08:24 lisppaste3 joined 08:54 tardisx joined 09:05 lypanov left
svnbot6 r10361 | audreyt++ | * unTODO now-passing tests. 09:11
09:31 nnunley joined 10:01 chris2 joined 10:04 tardisx joined 10:12 ludan joined 10:24 tardisx joined 10:39 jserv-- joined 10:56 kane__ joined 10:59 kane___ joined 11:04 chris2 joined 11:28 tardisx joined 11:55 kanru joined 11:57 mako132_ joined 12:01 jsiracusa joined 12:20 iblechbot joined 12:21 kolibrie joined 12:23 trym joined 12:24 weinig joined 12:58 f0rth joined, f0rth_ joined 12:59 f0rth joined 13:06 iblechbot joined, nnunley joined 13:07 nnunley joined, shachaf joined 13:08 jserv-- joined
[BlueT_at_Mars] jserv--: @@ 13:12
13:20 khisanth_ joined 13:21 elmex joined 13:23 justatheory joined 13:31 rashakil joined 13:42 cdpruden joined, KingDiamond joined 13:43 hexmode joined, chris2 joined 13:53 kanru joined
svnbot6 r10362 | fglock++ | PCR - <p6ws> renamed to <ws>; :ratchet - Match::Ratchet is closer to a 'Capture'; basic named captures 14:06
14:13 Limbic_Region joined 14:21 rashakil_ joined 14:37 rindolf joined
rindolf Hi all. 14:38
14:40 FurnaceBoy joined 14:52 szbalint_ joined 14:54 szbalint_ is now known as szbalint 15:15 Ymmv joined 15:23 cdfh_ joined
TimToady mumble, blear, gah, mornings are lovely, and I hate 'em. 15:28
15:28 IR7080 joined
rindolf TimToady: hi. 15:29
TimToady howdy! 15:30
rindolf TimToady: what's up?
IR7080 .
hello everyone
im kinda new to perl6
rindolf TimToady: torturing some lambda-camels?
IR7080 ive been reading the perl6-all mailing list stuff
looks like one hell of a language
TimToady just rewrote the precedence table yesterday, rindolf
IR7080: in both senses, yes. 15:31
IR7080 too bad its no clearer than chinese
PerlJam IR7080: I find perl6 *much* easier to read than chinese :)
TimToady the chinese think chinese is rather clear
rindolf TimToady: so now the p6 operators have different precedence?
TimToady just some of the looser ones
true and not are now tighter than comma 15:32
PerlJam TimToady: I take it you're still trying to unify precedences where ever you can?
TimToady just unified comma with listops last night, with a little handwaving.
actually had the pipe operators unified with "and" for a bit, but then decided that was a bad plan. 15:33
PerlJam TimToady: don't you mean "True" or did that change again too? :)
TimToady True is a value; true is a function
PerlJam oh
TimToady and *that's* why True is uppercase.
PerlJam maybe perl6 is like chinese then :) 15:34
TimToady I'm hoping to learn chinese one of these days.
perl6 too. 15:35
rindolf TimToady: heh heh.
Well I'd better get back to my todo list.
That or set my desktop wallpapers to the new ones. 15:36
TimToady have the appropriate amount of fun.
PerlJam The subtlties of pronunciation make chinese really hard for the western tongue IMHO (I've only had a small exposure though)
rindolf New major KDE version - new work - new backgrounds.
TimToady learning a new phonological systems is difficult for anyone over the age of 2 15:37
IR7080 yep
PerlJam will never forget the anglo EE with chinese wife trying to explain the difference between two words that both sounded like "shi"
TimToady if you happen to know what "retroflex" means, it becomes clearer. 15:38
but the main problem is that you have a bunch of neurons hardwired to classify sounds,
and those two sounds basically fall into the same recognizer if you're an english speaker 15:39
just as Japanese have trouble distinguishing our r and l
to do phonetics/phonology as a linguist, you have to figure out how to discount what your english recognizers are telling you, and listen to what's really there. 15:40
in tagmemics this is called the etic/emic distinction.
PerlJam interesting ... that's like artists who have to make a mental effort to draw what they see rather than what they think they see. 15:41
TimToady yes, very much so
in fact, the training is similar
an artist will turn a picture upside down, and copy it that way.
to learn phonetics, you take tapes of random languages and just try to imitate them without trying to think of them as language. 15:42
and then you try to figure out what you did with your mouth to make those sounds.
PerlJam for some reason the aural analog to turning the picture upside down seems harder
must have something to do with the rather large chunk of my brain wired for sight 15:43
(vs. the smaller chunk wired for sound)
TimToady It's temporally based--you have to do the imitation immediately without thinking about it.
rindolf Wallpapers changed. :-)
Now back to my todo list. 15:44
TimToady some people just can't turn off the signal from their native phonological processor; they should not become phoneticists.
I think it helps to be slightly autistic.
PerlJam waits for "Hearing on the Right Side of the Brain" to be published.
TimToady also helps to be a musician, probably. 15:45
PerlJam The human brain also seems to be wired to interpolate where ever it can. This may make a good survival trait, but it sucks when trying to capture reality.
rindolf PerlJam: free speech is a left-hemisphere function.
FurnaceBoy I thought it was a Constitutional right! 15:46
TimToady I'm more into free association.
FurnaceBoy you're just a free radical.
rindolf FurnaceBoy: I'm talking about freeform speech as opposed to singing and poetry.
PerlJam douses FurnaceBoy with anti-oxidants
TimToady FurnaceBoy: then why don't I feel more charged up? 15:47
rindolf FurnaceBoy: of course left-handed people have the left and right hemisphere switched.
TimToady or just mixed up.
FurnaceBoy ah... I never knew that.
I knew there was SOMETHING up with them ;-)
TimToady I think in general, some functions are switched and some arent'. 15:48
FurnaceBoy goes back to crashy USB driver...
TT, that was interesting regarding learning to hear.
TimToady but it's not a perfect swap. reminds me of bidi pairs...
rindolf TimToady: ambidextrous people have them mixed up.
FurnaceBoy typographers also use the "page upside-down" trick.
PerlJam my 4 month old twins are already showing signs of being right handed, but when my 4yr old son was their age he was quite ambidextrous and it's only recently that he's stopped using his left hand so much (except that I've been encouraging him to throw balls and things with his left hand lately) 15:49
FurnaceBoy sometimes helps judging letterspacing. but you can train your eyes to see patterns instead of letters (takes time).
TimToady the basic skill is to "relax" a part of your brain that wants to not relax. 15:50
FurnaceBoy yes!!!!
disengage.
de-train.
TimToady helps to be running an interpreter rather than a compiler. 15:51
FurnaceBoy :-)
raw input rather than cooked.
TimToady "seeing what's really there" is a pervasive goal for me. 15:52
rindolf PerlJam: Pete_I said he had to stop being ambi-dextrous so he can stop being dyslexic.
TimToady it extends to things like "gee, this precedence table is screwed up"
I'm pretty good at the disengaging. I have more difficulty with the reengaging... :/ 15:54
I sort of hate making decisions.
which is why sometimes when I do make decisions they seem like snap decisions.
(because I know I don't dare hesitate) 15:55
(and because I know I'll just disengage again later anyway).
but it can certainly give the appearance of waffling.
PerlJam that's me. If I give myself time to waffle, I will and I won't be able to make a decision
TimToady I think the trick for a language designer is to pay attention to the things people are carping about, and attempt to waffle on those. 15:56
but you also have to pay attention to your own gut feelings occasionally.
because people tend to carp about surface issues, and a designer has to get down to deeper issues 15:57
PerlJam people typically only see the surface of the water bed, not what's beneath :) 15:58
TimToady It's funny, because in this case they're stuck on the etic side rather than the emic side.
but the bikeshed hopefully contains a bicycle. 15:59
I wonder if bikesheds attract tornadoes?
16:00 gugod joined
TimToady I also wonder if mobile homes attract asteroids, but it's hard to get a large enough statistical sample there... 16:00
sorry, told you I was into free association... 16:01
16:02 Ymmv joined
PerlJam TimToady: as long as you limit your IRC activity to #perl6 and #parrotsketch, I will not despair of your free association (Particularly stay away from #perl ;) 16:03
16:05 pdcawley_ joined
particle_ bikesheds attract tornadoes with a force directly proportional to the product of their masses... 16:05
16:05 pdcawley joined
TimToady do you play a graviton on TV? 16:06
particle_ some days i do. want an autograph? 16:07
szbalint Association is good. I do it all the time, mostly about obscure things...
TimToady Heh, I'd love to see the signature of a graviton...
particle_ come closer :)
Limbic_Region [TimToady] - it would spin you around in your seat (twice) 16:08
TimToady More than that, if it's heavy enough.
wouldn't it be funny if black holes came with integral spins... 16:09
Limbic_Region isn't sure if TimToady understood his joke or just knows more about the topic
TimToady I suppose they must, at some level.
Yes, I know gravitons are spin 2
Limbic_Region apparently he just knows more about the topic 16:10
well - are predicted to have a spin of 2
TimToady My oldest son is a quantum physicist. How could I not?
Limbic_Region oh really - cool beaners and moldy chicken
so does he go for 10 dimensions or 26?
TimToady doesn't like string theory at all. 16:11
likes quantum gravity.
particle_ that's so five minutes ago
TimToady part of the reason he went to U Maryland is because they're, er, heavily into quantum gravity there.
particle_ is rereading 'a brief history of time'
PerlJam It's hard to get excited about string theory (or M theory) until it makes some useful predictions.
Limbic_Region doesn't live to far away from U Maryland's main campus 16:12
TimToady Aron lives in Silver Spring.
particle_ nice town. i have family there 16:13
Limbic_Region wow - close. Not as close as when I lived in Ellicott City but still pretty close
if I had ever gone to college - that's what I would have studied (if I had studied that is)
TimToady yeah, I got one of them too... :/ 16:14
PerlJam Limbic_Region: There's nothing stopping you from being an autodidact :) 16:15
TimToady he obviously is one.
but you have to decide to be one at some point.
my younger son is extremely bright, but hasn't learned to think yet... 16:16
particle_ there's no common law autodidact?
TimToady maybe he's just a late bloomer like me...
PerlJam well, L~R is an autodidact in a general sense, but why "would he have studied quantum gravity" (if he had studied) instead of "is studying" or whatever? 16:17
Limbic_Region intends to win the lottery so that he can audit classess he finds appealing without the necessary prerequisites and fund opensource and well um - play
PerlJam TimToady: how old is he?
(your younger son) 16:18
TimToady almost 17
particle_ wonders if lr plays the lottery
leaving home taught me to think
Limbic_Region particle_ not as often as I should
PerlJam TimToady: I've got 2 brothers, 26 and 28 who have yet to find their place in the world. 16:19
TimToady well, hey, I'm still working on that myself... :)
particle_ your place is over there ==>
TimToady and... 16:20
PerlJam TimToady: you're firmly established as the perl6 language designer. that's quite a good place to be (for you :)
particle_ <== don't forget over there
PerlJam I would suck as a language designer.
TimToady so do I, but I just try to suck less, I guess... 16:21
particle_ after how many years, and the language still isn't right? ;)
TimToady It's like sending out a fleet of exploratory ships. You know most of them are going to run aground, but you do it anyway. 16:22
Juerd stevan: ? 16:23
PerlJam goes back to finding the code he was working on 3 weeks ago. 16:24
TimToady wanders off to run aground again...
PerlJam (this is why I would suck as language designer. I wrote a program but didn't stick it in svn and now I can't find it)
FurnaceBoy :( 16:25
Juerd PerlJam: We don't know how often TimToady designed Perl 6 before sticking it in version control ;) 16:26
TimToady let me put it this way--I ran svn add for the first time yesterday. 16:28
rindolf TimToady: seriously?
TimToady all the design docs were put there by other people. 16:29
Juerd is impressed
TimToady It's possible I've run it before and just forgot, but by and large, I don't initiate things like that.
it's part of my personal disability not to initiate. 16:30
IR7080 how long do you guys think it will take to put perl6 out, a stable 6.0 ?
Juerd IR7080: It'll probably be released somewhere around, or during, Christmas.
TimToady when deja news first came out, merlyn did a scan of my old articles, and discovered that all but one of them were followups to someone else.
Juerd TimToady: Haha :)
IR7080 excelent
Juerd TimToady: And the one remaining post was the first announcement of Perl 1? 16:31
PerlJam TimToady: I have a similar disease I think.
particle_ IR7080: he didn't say *which* christmas
Juerd I *had* this disease, and somehow managed to get rid of it a few years ago.
TimToady I think merlyn actually missed a few, but the pattern is definitely there.
PerlJam IR7080: my personal opinion on the subject (and this changes over time, so ask me again in a couple of months) is that we will see the first alpha release of "the" perl6 compiler before the end of this year. 16:32
TimToady It was a growth action for me to complain about morning on an IRC channel that nobody was talking on yet.
I had to decide to do that.
particle_ pj: sure, you work with the guy writing it, no? 16:33
PerlJam particle_: no, I don't work with pmichaud; not for 2 years or so now.
IR7080 let us hope he meant "this" christmas
particle_ ah, sorry
TimToady "meaning" christmas doesn't help. only working on it helps.
Juerd PerlJam: Is than an opinion, or estimation, or assumption? :)
PerlJam: Or just a wild guess :) 16:34
PerlJam Juerd: SWAG :)
Juerd What's that?
IR7080 www.google.com/search?q=define%3Asw...unofficial
PerlJam Scientific Wild Ass Guess
IR7080 "Curtain window treatments that can be hung on a rod or attached to a mounting board"
TimToady it'll be done sooner if you help, IR7080. Would you like a commit bit?
IR7080 yeah,
i was about to comit to the svn some changes, on the ... file 16:35
yeah
PerlJam TimToady: I'm not so sure of that assertion. A certain book by Fred Brooks comes to mind ;)
TimToady this is not a late software project, by definition. It'll be done when it's done.
stevan Juerd: ??
Juerd stevan: Ah, there you are :)
stevan: You pinged me
IR7080 the best i can do is /maybe/ help on syntax errors made by the devs on the POD s
Juerd stevan: Probably because I asked you :) 16:36
stevan Juerd: yes, you were asking something about Roles
TimToady you could write tests maybe
PerlJam TimToady: It's all about perception. There is a perception by the vast majority that perl6 is indeed late. (man those people suck! ;)
Juerd stevan: Indeed. Is there a good overview for end-users?
stevan Juerd: not really, not at the moment anyway
Juerd stevan: Of how to choose between class and role, and maybe a design best practice?
stevan: Hm - that's very unfortunate :)
rindolf stevan: is DBIx::Class going to be based on Moose? 16:37
stevan Juerd: I think the basic assumption goes something like this:
Juerd I'm doing a talk about Perl 6 OO tomorrow, and expect this question from the audience if I don't come up with the answer first
stevan if you were thinking of using a mixin, java-style-interface, abstract-base-class
then use a role
PerlJam stevan: that begs the question: why *wouldn't* I use a mixin, etc. ?
Juerd I was about to say that... 16:38
stevan rindolf: mst has been talking about using Moose with DBIx::Class yes, but not sure how planned that is
TimToady because those are all degenerate cases of role
PerlJam Juerd: I know, I'm trying to help you out :)
stevan PerlJam: a role is a mixin which can do some conflict checking
Juerd Also: why roles, not multiple inheritance?
stevan TimToady: exactly :)
Juerd: you can use MI too, but MI gets messy after a while
Juerd I don't get what "degenerate case" means 16:39
stevan when you use roles instead, you get the method conflict resolution
Juerd stevan: Do you happen to have examples?
stevan Juerd: No, but what kind of examples are you looking for? I can maybe make some up
Juerd stevan: An example of how something would be implemented with, and how it would be implemented without roles. Something that shows they're not just theoretical fluff. 16:40
stevan yes, let me whip up a few
PerlJam stevan, Juerd; a tutorial on roles would make a good article for perl.com :)
Juerd stevan: That would be great. Thanks :)
PerlJam: Indeed; I could certainly use one :)
TimToady that's hard, given that the whole point of roles is to represent theoretical fluff. :)
Juerd Have I shown my spooky photo, by the way? photo.juerd.nl/verkeer/zeedijk.jpg
TimToady: ... :) 16:41
It was very windy, and I couldn't hold my camera stable enough.
I'm going to try again soon. 16:42
TimToady motorcycle?
or burned out headlight?
Juerd Normal headlight, as far as I know
TimToady the shadows aren't doubled...
Juerd The beams don't cross close to the car
TimToady or did you use a flash? 16:43
Juerd And the second shadows would often fall besides the tree
No, these are headlights
High beam
Juerd goes outside to check if they still both work
TimToady how close together?
Juerd afk
PerlJam assumes Juerd is going to measure the distance now :) 16:44
particle_ calculates the resolving power 16:45
TimToady I think he was standing in front of the car blocking the cross lighting.
particle_ no human shadow 16:46
TimToady but I think I see a doubled shadow on the 4th tree from the right.
pasteling "stevan" at 71.234.63.100 pasted "Classic Equality Role" (19 lines, 288B) at sial.org/pbot/17223
PerlJam TimToady: He's standing in the cone of darkness between the lights. And the shadows do look doubled in the trees that are further out.
particle_ i think that's flowers & pole, not double shadow
PerlJam it's hard to tell though
16:46 sri_ joined
stevan Juerd: this is a very common example given for things like roles 16:47
in Ruby it would be a mixin, in Eiffell it is deferred class
TimToady but the line of the shadows shows that the right light is to the right of the observer while the left light is to the left of the observer.
Juerd 1 m
TimToady so it has to be two lights.
Juerd stevan: Thank you much. I'll look at it in a minute
TimToady just with little crossover.
1 m is pretty close together. 16:48
stevan TimToady: could you please make sure I am correct on the syntax, I have been a little out of the loop lately
PerlJam stevan: do you have a non-parameterized example?
stevan PerlJam: the parameter in there just makes not_equal_to type safe
you could remove it and it would do the same
Juerd TimToady: We have normal sized cars.
PerlJam Juerd: for europe :)
particle_ thought juerd might be a shriner 16:49
pasteling "stevan" at 71.234.63.100 pasted "Classic Equality Role (no parameters)" (18 lines, 272B) at sial.org/pbot/17224
Juerd 1m is the distance between the centres of the lights
PerlJam Juerd: are you sure it's not a motorcycle? :)
Juerd I am :)
PerlJam I'm in Texas, so apply the usual stereotypes :) 16:50
stevan the stars at night, are big and bright!
stevan reminds PerlJam he must complete the song by law
PerlJam heh
stevan they will fry you if you dont
PerlJam Bush isn't governor anymore! 16:51
Juerd photo.juerd.nl/tmp/headlights.jpg
TimToady you have to use {...} to stub a method.
Juerd Now I'm going to read stevan's examples :)
TimToady and a type parameter would be ::T 16:52
stevan ok
TimToady then you can use as bare T within the scope.
Juerd stevan: Ahh - this is also the first time I understand how parameters are useful :)
stevan Juerd: cool :) 16:53
Juerd TimToady: I was indeed in between the lights
wolverian Juerd, your subs haven't taken any parameters before? :)
Juerd wolverian: My classes never have, and I've never had roles.
pasteling "stevan" at 71.234.63.100 pasted "Basic plugin example" (21 lines, 287B) at sial.org/pbot/17225
stevan Juerd: this is how you might use Roles for "plugins"
16:53 m__ joined
stevan currently people usually do mixins (liek CGI::App) and MI (like Catalyst) for plugins 16:54
Juerd stevan: What's App::Base's function?
stevan but roles will actually be a much safer way to compose with plugins
16:54 weinig joined
stevan Juerd: think of it as a base class for all applications maybe 16:54
Juerd stevan: Does App::Logger, or My::App lack an "is App::Base"?
stevan oh yes,.. sorry 16:55
class My::App is App::Base does App::Logger {}
Juerd Hm, so a single class can do several roles, that each define equally named methods?
stevan no
Juerd So another role couldn't provide another &run? 16:56
particle_ app::base is meant to be an abstract base class?
stevan if you combine several roles, and there is a name conflict, then the composition fails
particle_ oh, i see
stevan particle_: kind of, but it's abstractness is mostly there because I couldnt come up with something for it to do :)
Juerd stevan: Then I don't understand why roles are useful for plugins, in this example.
particle_ a method needs to be defined in a class before it can be defined in a role 16:57
stevan The App::Logger::run will be called if you did My::App.run()
Juerd particle_: That'd be... very redundant :|
16:57 Qiang joined
wolverian particle_, no. 16:57
stevan particle_: in this example yes, only because i use next METHOD within the Role
Juerd stevan: And "next METHOD" calls App::Base::run?
particle_ right.
stevan Juerd: yes
Juerd stevan: Seems useless for plugins, to be honest, if two plugins can't use the same hook. 16:58
stevan Juerd: I agree, this is why I added method-modifiers to Moose
TimToady could if they were declared multi, I think.
stevan TimToady: but they wouldnt all be called though
it just wouldnt fail in the composition 16:59
TimToady next METHOD is defined to work with multis too.
stevan oh yes
very try
true
TimToady: but wont that impose some kind of ordering on the role composition?
which one is called first? 17:00
TimToady multis are ordered by type.
stevan ran into this in Moose, but decided it was a feature :)
TimToady if they're the same type
then you have a tie
but you could still call them all with .* and then do last METHOD to stop.
stevan yup
TimToady it's just that would take the collusion of the class. 17:01
it might be something better handled with wrappers.
particle_ points to qpsmtpd
stevan yes, this puts an aweful lot of burden on the plugin developer
Juerd: well, maybe the plugin example is not so good 17:02
TimToady I'm not sure plugins are going to be the best use-case for roles
that's very much in the realm of mixins.
Juerd I was thinking an array with .? would be better :) 17:03
TimToady and when you mixin, you get hiding rather than collisoins.
stevan TimToady: they are working pretty well in Moose with the before/after/around method modifiers as well as inner() and super() calls
TimToady and next METHOD would work fine.
before/after/around *is* wrapping
stevan yes exactly :)
Juerd stevan: But - I think the logger example also isn't really great
stevan but they can be composed
TimToady but in P6 you probably just want .wrap
Juerd stevan: I'd want multiple things to wrap around run...
stevan TimToady: yes
Juerd: yes, I agree, not the best example 17:04
particle_ turns on the two turntables
Juerd So, to summarize: I still don't understand why roles are useful
stevan waves his hands in the air,... like he just doesnt care
TimToady well, have you read the traits paper?
Juerd No
stevan Juerd: They are also good for Java-style interfaces 17:05
TimToady that would be a good place to start, I think.
Juerd I lack knowledge outside Perl...
TimToady What makes you think I know Smalltalk?
Juerd I had no idea I was implying that.
stevan Juerd: an interface just defines a set of methods and a name
then you class "implements" the interface by providing actual code for those methods 17:06
Juerd stevan: But a role's method gets precedence over the outer class's
stevan: Would the role have "next METHOD" in each method?
stevan then you can treat instances of that class as if they were that interface ,.. regardless of the class they actually come from
TimToady Juerd: no, the class's method takes precedence. 17:07
stevan the local class to be more specific
Juerd TimToady: Oh - then I don't get stevan's first example anymore :)
stevan class beats role, role beats superclass
Juerd As then the role's run wouldn't be used...
.oO( and this is supposed to make programming *easier*? )
stevan no, harder
:P
Juerd Why?
stevan just kidding
particle_ scissors cuts paper 17:08
stevan roles are hard to see the usefulness until you really start actually using them
Juerd Nobody seems to have good examples of exactly when and why it's useful, and its complexity is off my chart...
TimToady read the Traits paper.
Juerd stevan: Has anyone used them?
stevan Juerd: they are better in complex situations actually
Juerd: nothingmuch has done a fair amount of playing with them in perl 6 and Moose
I have been using them in Moose (as plugins :P) 17:09
Juerd Then perhaps I'm better off asking nothingmuch?
stevan there are a few papers out there about refactoring the Smalltalk collection heirarchy and Java.IO package using traits
Juerd TimToady: I might, if I can find the time in between now and tomorrow morning.
stevan: Are traits the same thing as roles?
stevan Juerd: basically yes, but traits have a few more features
Juerd Are these traits the same traits as Perl 6's traits? 17:10
17:10 bpederse joined
TimToady no 17:10
stevan I honestly think it will take a little while before we discover the true usefulness of traits/roles
people need to start using them in real-world designs 17:11
Juerd stevan: ... (!)
They need to start using them without any idea, without any guidelines, without concrete thoughts...
stevan Juerd: no, when you start using them,.. you start thinking in roles more
and as more and more people use them, it will become more clear where they fit in 17:12
Juerd I wonder if the wheel was invented like it. "Nice, shiny, geometrically correct. What is it?" "I call it... the wheel" "I see - and how do you use it?" "I haven't quite figured that out yet, but in a few centuries from now, all cars will have several of these." "What's a car?" "I have no idea."
stevan I doubt the inventors of OO knew exactly where it would be best used 17:13
Juerd: exactly!
particle_ traits are a form of polymorphism which allows a SI hierarchy, and also allows subclasses to have different behavior from their superclasses 17:14
Juerd Doesn't really make me enthusiastic about it.
TimToady MMD is defined in terms of roles, not classes.
stevan they are much more exciting in a SI language
Juerd I think I'll just ignore roles for now. 17:15
TimToady it lets you finesse the difference between named typing and duck typing
Juerd And try to fill 45 minutes with other stuff, and then say "I was going to discuss roles too, but I'm out of time. Maybe next year!"
:)
stevan :)
17:16 fglock joined
stevan .does(Lunch) 17:16
Juerd Well, that's a good example. 17:17
You !isa Lunch, you do Lunch.
Can't really relate that to technical stuff, though...
17:17 penk joined
TimToady let's hope Stevan.handles(Lunch) 17:17
stevan sandwich.does(Consumable)
Juerd Why *does*, not *is" consumable? 17:18
TimToady they really are for doing type analysis without commitment to objecthood.
stevan pizza.does(Consumable)
Juerd TimToady: Care to explain that?
stevan Juerd: to avoid making the commitement of a Consumable base class which all my foodstuff inherits from
Juerd stevan: And that's needed, or useful, because...? 17:19
TimToady this is all explained in the Traits paper in much better detail...
stevan Juerd: also please see the paper on refactoring the smalltalk collection hierarchy
TimToady the basic problem is that classes are used for two completely different things
stevan they demonstate that composing with roles saves many unneeded methods
TimToady 1) managing the creation and destruction of objects 17:20
2) type specification
stevan Juerd: see www.iam.unibe.ch/~scg/Research/Traits/ (1st and 3rd papers in the list)
Juerd The problem is that these papers are lots of reading, and I have approx. 3 hours.
stevan no, you have 365 days + 3 hours ;) 17:21
Juerd I didn't really expect to have to do this much research for this talk, so I didn't schedule any time for it.
TimToady just think, there's really no such thing as an abstract class.
Juerd I sort of assumed that if so much effort was put into it, there'd be some (Perl 6) documentation, and examples, about it.
TimToady a class is about real objects. roles are about abstractions.
Juerd TimToady: That is nice
TimToady: And understandable. I wish I could think of a way how that'd work, though. 17:22
Maybe I've just done class OO too much... 17:23
TimToady when you want to do type reasoning, you don't really care what the composition of an object is, you only care what interfaces it supports.
roles can be thought of as mere interfaces with some default implementation for handiness.
particle_ .print()
TimToady and a bit of generic instantiation thrown in for good measure. 17:24
Juerd TimToady: I know inheritance can be used for this, and often is. There probably is some negative side about inheritance that I don't get yet.
TimToady Roles are actually a unification of several things in the Comp Sci field that a language would otherwise have to incorporate separately.
see C++, for instance.
17:25 ruoso joined
TimToady yes, like diamond inheritance. roles solves that. 17:25
Juerd Fsck; have to go. 17:26
PerlJam TimToady: So would macros though; what makes roles special? (still trying to help Juerd :)
17:26 [BlueT_at_Mars] is now known as BlueT_at_Mars
TimToady ciao. 17:27
Juerd Please pretend I'm still here, and talk to me; I'll read everything when I'm back (as little sense as that makes if I'm still here)
afk
TimToady roles can be thought of as a funny way to write macros
all generics are sorta-macros 17:28
PerlJam macros don't do conflict resolution though
TimToady roles try to be particularly hygienic with respect to typology
these macros do. :)
PerlJam roles give you finer control over conflict resolution rather than always bailing out. 17:29
TimToady they're more like declarative macros than imperative though.
so in that sense "does" is more like "use". 17:30
you request the interface, and some implementation comes along for the ride.
kolibrie could something like serialization be written as a role? any object could do the roles YAML, XML, Perl?
TimToady certainly. 17:31
particle_ you'd probably want to use templates for that, too
for the roles, that is
PerlJam To me roles are what "types" should be and classes are just heavy weight versions :)
17:32 ludan joined
TimToady classes are roles that happen to have working constructors. :) 17:32
kolibrie so really almost everything should be written as a role? 17:33
TimToady but yes, roles are the real "types" in Perl 6.
ludan hi
TimToady don't go off the deep end.
as long as a class can be used as a role, it doesn't much matter 17:34
PerlJam kolibrie: while you can probably write everything as a role, it is unadvisavle to do so :)
pmichaud has trouble lexing "unadvisavle"
PerlJam kolibrie: roles are just a tool to be used like any other.
pmichaud looks too weird
kolibrie wants to know, like Juerd, when roles are the right tool, and when not 17:35
TimToady if it's natural to write a type as a class or a subset or an enum, by all means do it that way. all of these can be used for type matching.
PerlJam kolibrie: Do as oft happens in the world of programming languages: implement everything under the sun using roles. Eventually you'll figure out where you should have used something else :) 17:36
pmichaud there's more than one ONE way to do it :-)
TimToady inheritance has to be good for something...
FurnaceBoy blue eyes 17:37
dimples
baldness
pmichaud estate taxes
kolibrie I often think of roles as a way to add functionality to a bunch of unrelated classes 17:38
TimToady but, in fact, what OO calls inheritance has very little to do with real inheritance.
a proto based language like Self is much closer, where everything is just a clone of its parents.
pmichaud ah, I remember Self
TimToady that's another language I don't know that I know all about... :) 17:39
pmichaud I'm in the same boat. It was a big topic at OOPSLA '87
but I was busy at DisneyWorld
TimToady I think inheritance is a beautiful match to derived grammars, because both the base grammar and the derived grammar are real objects. 17:42
but that's because grammars are rather platonic.
most of world is aristotelian, however. 17:43
inheritance is lousy at modelling gene pools.
"What would my great-great-great-great-grandpappy do? 17:44
17:45 trym joined
TimToady Inheritance also only works well for computers with central CPUs where everyone can see the same class definitions. 17:46
17:46 larsen joined
TimToady As we move toward distributed computing, type information gets distributed more like a gene pools info. 17:46
*pool's 17:47
and every object needs to carry around its own DNA, not ask its great-great-grandparent what to do.
It scales, as long as there's enough sex. 17:48
FurnaceBoy If I had a dollar... 17:49
PerlJam TimToady: or a suitable source of mutations :) 17:50
FurnaceBoy curses ECC!
17:51 DaGo joined
TimToady I've spent long enough sitting cross-legged on this mountain. Need to go primp for work... 17:52
PerlJam: I first read that as "munitions", which also have an effect on the gene pool... 17:55
&
17:55 penk joined
PerlJam I bet if all of the perl6 naysayers spent some time on #parrot and #perl6, they'd see that there is some progress being made and so wouldn't say so much nay. 17:55
I wonder if it would be useful to have a this-week-in-#parrot-or-#perl6 web page 17:56
ruoso PerlJam, it would be really nicee
PerlJam, I'm not having time to read the logs myself...
kolibrie naysayers like saying nay. builders like building.
pmichaud volunteers PerlJam
PerlJam pmichaud: But then I'd have to pay attention to what's going on rather than just dropping into the middle of things like I normally do 17:57
pmichaud or just log the channel and summarize it afterwards :-) 17:58
PerlJam maybe just summarizing the svn logs would be enough.
pmichaud that would be interesting (and possibly very useful)
PerlJam this week on #perl6/#parrot: stuff changed. radically. :-)
pmichaud we just need the "radical change index"
"how much did things change this week?"
17:59 elmex joined
ruoso "what you thought you had to learn last week that is dead this week" 17:59
PerlJam Hmm. Summarizing the log wouldn't be enough since TimToady occasionally sneaks conjectural stuff in with out putting it in the log message (or marking it as conjectural in the document :)
17:59 bernhard joined
FurnaceBoy just label ALL his commits. 18:00
coloured background.
ruoso heh
pmichaud one could claim that most everything here is conjectural :-) 18:01
ruoso pmichaud++
PerlJam change per unit time is easy enough to generate, the problem is perceiving that change as progress. How do you know that things are moving towards a goal? 18:02
particle_ moves the goalpost yet again 18:05
18:18 aufrank joined 18:27 FurnaceBoy_ joined, rashakil joined
Juerd Why have both roles and classes? Would having only roles not suffice? 18:48
(If they could instantiate) 18:49
PerlJam: I bet if some of the perl6 naysayers spent time here, there'd be some serious discussion about roles on slashdot :) 18:50
18:51 justatheory joined
Juerd nothingmuch: pingishness 18:57
particle_ juerd: tmtowtdi 18:58
if you want an SI model with roles, use it. 18:59
if you want a MI model with classes, use it.
Juerd Sure, but adding stuff just to add more ways to do it is a bad idea. 19:02
That's PHP's approach :)
I like my programming language properly abstracted.
particle_ well then... sometimes, roles are the proper abstraction 19:03
Juerd Sigh.
This is so circular.
particle_ :)
Juerd self-referential, recursive, etc.
particle_ qwhine? ;)
Juerd Let me put it differently: what are the benefits of inheritance compared to composition? 19:04
Why do we need inheritance, ignoring backwards and cultural compatibility?
merlyn if all you have is composition, you need an easy way to show delegation 19:05
I imagine you can prove that inheritance is nothing more than good delegation onto a composite 19:06
but I'm not smart enough to figure out the difference
19:06 justathe1ry joined 19:07 weinig is now known as weinig|away
Juerd merlyn: Can you explain what you mean with delegation? 19:11
Juerd can't really parse it with the definition he knows
merlyn $myobject.some_method gets sent to $myobject.some_attribute.some_method
so you can build up a "car" from an "engine" and "wheels" and "gas tank"
wait, ignore that example 19:12
ruoso Juerd, rules can be applied to instances, while inheritance refers only to classes?
Juerd merlyn: So it was the same definition. 19:13
merlyn: I don't understand the relation between inheritance and delegation
A role can also has $.foo handles <bar baz>
merlyn if I can't inherit from my superclass, I'll have to compose an object of that superclass, and delegate all methods to it
Juerd ruoso: s/rules/roles/, I guess, and then I still don't get the point :) 19:14
ruoso Juerd, sorry... it's roles, indeed...
Juerd merlyn: Why would you have to delegate?
merlyn to get my ->foo to really be my parent's -.foo
darn it, using p5 syntax. :)
Juerd merlyn: There's no parent, but you already get the role's foo if you call foo on $bar, where $bar does the role that has foo. 19:15
Juerd rereads that
Juerd hopes merlyn can parse it :)
ruoso inheritance is a type of role, isn't it? 19:16
19:16 gdickie joined
stevan points out that we all how our roles to play on this great stage of life 19:17
Juerd: I think merlyn is talking about prototype style OO
in prototype OO, if a method fails to resolve to a local definition, it tries passes the call onto it's prototype 19:18
which is basically delegation
because the prototype-slot is really just another slot 19:19
it just has special meaning during method dispatch
Juerd But Perl 6 doesn't do that, right? 19:20
stevan Juerd: no, Perl 6 does not have Prototype based OO
at least not by default ;)
Juerd if Foo does Bar, and Bar does Quux, and they all have a method xyzzy, will composition then fail? 19:21
stevan not nessecarily 19:22
Juerd Depending on?
stevan Bar.xyzzy can override Quux.xyzzy
and Foo.xyzzy can override Bar.xyzzy
however
if you had Baz, which has a method .xyzzy 19:23
and you did Foo does Bar does Baz
it would fail
Juerd Okay
stevan because the Baz.xyzzy and Bar.xyzzy would conflict
only when you compose one or more roles will it possibly conflict
Juerd So - roles/composition can be used in all sane cases of classes/inheritance, with the added benefit of getting a clear error message up front if you try to "inherit" from two classes that both claim a certain method name? (ignoring MMD) 19:24
stevan yes
Juerd Why the h*ck still have classes, then?
stevan in that sense, it can make MI easier to manage 19:25
Juerd It's safer for MI, practically equal for SI.
stevan because classes deal with the allocation/initialization of instances
particle_ btw, if you're going to compose with more than one role, you can specify methods to exclude, so there's no conflict
Juerd stevan: But why don't roles?
19:25 penk joined
stevan particle_: no, that is traits 19:25
Juerd: because then if Roles do that,.. you are back at classes again,.. as if you never left
particle_ oh. rats.
Juerd stevan: Which is back, because? 19:26
stevan: Which is bad, because?
I guess I'm asking: what do roles give us except protection against name clashes...
Why not abstract these two things into one thing 19:27
ruoso Juerd, you can use roles to compose classes or instances
Juerd So you only have to learn one thing (which is a HUGE benefit)
ruoso but you must use a class to get an instance
stevan Juerd: decoupling the more mundane details for things like instance allocation/intialization and method dispatch and other lower level class things from the more abstract idea of "types" and "behaviors"
Juerd ruoso: That's not an explanation...
stevan: Why is this decoupling needed or useful? 19:28
stevan Juerd: regular OO says "a Class is a Type"
Juerd Perl has never ever done "regular OO"
And probably never will.
stevan Foo $foo = Foo.new();
Juerd It has had "classes" without having classes. packages sufficed.
stevan Juerd: Perl's OO is regular enough for this
Juerd: lets stick with idiomatic Perl 5 OO for the moment 19:29
Juerd Why do types matter?
All I care about, when I'm about to call $foo.bar, if $foo.can('bar').
stevan because $foo->isa(Foo)
then you are duck typing
Juerd I might sometimes want to know if something does a certain interface
stevan yes
then you want roles 19:30
Juerd But why would I be interested in is-a relations, ever?
stevan $foo.does(Bar)
Juerd: you may not be, but that is not how everyone views it
Juerd Why would <someone> be ...
:)
stevan some people place more importance on isa than others
Juerd Why do they?
What are their arguments, besides being used to isa/typeof
stevan dunno,.. gotta ask one
:)
Well, to be honest in a dynamic language like Perl/Ruby/Python it is less of an issues 19:31
we have duck typing
Juerd What's duck typing again?
stevan if it quacks(),.. its a Duck
rather than $donald.isa(Duck)
it is what you said,.. $donald.can(quack) 19:32
then you know donald is a Duck
19:32 ruz joined
stevan but in more static langauges, the isa() relations are more important during compile time 19:32
but being stuck within the confines of isa() type relationships is no good 19:33
not everything fits into that type of model
Juerd I understand why roles are more useful, I think
ingy `_`
Juerd I don't yet understand why classes are still needed.
stevan because if we didnt have classes, roles would have nothing to compose into ;) 19:34
Juerd It seems to me that roles can do everything that classes can (but with different semantics and names, but I fail to find relevance)
If roles had constructors, you wouldn't need to.
stevan well
then you end up with some not-so-general roles 19:35
ruoso Juerd, isa relations are important in modeling also
Juerd ruoso: Why?
ruoso: And wouldn't does relations suffice?
stevan Roles work well in the very abstract parts of a model
particle_ class attributes, attribute inheritance?
stevan then you can get specific in classes
ruoso what makes more sense: Duck does Animal? or Duck isa Animal?
nothingmuch Juerd: pong 19:36
note: i'm sick - i'm zoning out, but i will still backlog
so you can /msg
Juerd nothingmuch: Oh, if you're sick, I won't bother you. Nevermind.
nothingmuch sick == bored but incapacitated
Juerd particle_: No different in roles
nothingmuch so i'm actually potentially interested, as long as it's not too hard ;-) 19:37
gdickie It might be useful to have roles which provide constructors: does ConstructFromFileByDeserialize, does ConstructFromHash
stevan ah Juerd I found a good example
Juerd nothingmuch: I'm seeking knowledge re classes versus roles. Especially, when does one use classes instead of roles. And whether inheritance is still needed for anything.
nothingmuch: Word has that you've already played with roles, and are probably the most knowledgeable about them now 19:38
nothingmuch my rule of thumb has been (so far) that if it makes Liskov happy then it's inheritence
but anything else should default to roles
and
it's been working for me
Juerd Liskov?
nothingmuch one sec, wikipedia link 19:39
aufrank stevan: example coming? 19:40
nothingmuch en.wikipedia.org/wiki/Liskov_substi..._principle
stevan aufrank: yes
nothingmuch i don't agree that the Liskov substitution principal always be in place
i much prefer duck typing 19:41
roles let you have the benefits of ducktyping with some formalism thrown in
and they are much safer to both cherry pick, and add everything but the kitchen sink
PerlJam Juerd: by tomorrow you'll be an expert in all of this, right? ;)
nothingmuch two extremes that MI is not very good for
Juerd nothingmuch: I wish I understood that article. It's over my head 19:42
nothingmuch it's really quite simple:
Juerd PerlJam: By tomorrow I'll be dead.
nothingmuch any code that has code
err
sorry, (i'm sick ;-)
PerlJam Juerd: basically liskov says that derived classes can be used anywhere superclasses can 19:43
nothingmuch any code that has a variable/whatever containing calls that assume a certain class is being acted on
like $uri->host; $uri->schema;
19:43 elmex joined
nothingmuch should always be 100% supported by any subclass 19:43
subclasses may change implementation details
or add to an interface
but not change it in an incompatible way 19:44
particle_ that's a *very* strict definition of subclassing... and in combination with a language supporting roles, i like it.
Juerd sends the Traits paper (143 pages) to his laser printer
Juerd prepares for a sleepless night
nothingmuch Juerd: double sided please =)
Juerd nothingmuch: Duplexer is broken.
nothingmuch: It's theoretically okay to do a role, but override a method in an incompatible way? 19:45
Can a role inherit from a class? 19:47
PerlJam Juerd: no.
Juerd Can you "does" a class?
nothingmuch Juerd: in Perl there will prolly be a way to cheat
that is, use a role as a class or vice versa 19:48
in theory they are distinct
PerlJam nothingmuch: you can easily cheat with a mixin :)
nothingmuch exactly
Juerd nothingmuch: Disregard cheating please :)
PerlJam (and delegation)
particle_ can a role inherit at all?
nothingmuch particle_: it can does
the main thing about roles is that instead of being order sensitive, they are symmetric
PerlJam particle_: roles are composed (of other roles).
particle_ sure, but i expect isa and does are orthogonal
nothingmuch and any clash between two roles that is not resolved is an error
particle_ isa is for classes, does is for roles 19:49
Juerd What's the verb missing in "class : inherit : is-a :: role : ? does"
What's the verb missing in "class : inherit : is-a :: role : ? : does"
implement?
use?
nothingmuch the verb is "consume" usually
PerlJam implement sounds good to me.
nothingmuch roles compose, and are then consumed by a class
PerlJam: that's more like interfaces
Juerd consumption would imply that someone else can no longer use it ;) 19:50
PerlJam nothingmuch: yeah, I guess so.
Juerd If I consume food, someone else can no longer eat it.
nothingmuch I think either is equally OK
Juerd Not in its original form anyway :)
PerlJam nothingmuch: but roles can be used like interfaces just fine :)
nothingmuch yes that's true =)
Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T 19:51
this could sound better as:
PerlJam roles are like classes but without hooks into the type system (until they are composed into a class)
nothingmuch If you read about it in the superclass's docs you can use it on the subclass with no exceptions 19:52
ruoso you can't have an instance of a role
nothingmuch (liskov substitution principle)
particle_ or, "everything you can do, i can do better"
nothingmuch particle_++
PerlJam ruoso: you can (sort of).
ruoso roles "decorates" classes
PerlJam, how? 19:53
nothingmuch ruoso: decoration is a verb that usually describes altering an existing class 19:54
ruoso nothingmuch, that's what a role can do
nothingmuch not really
PerlJam ruoso: at least I remember Larry saying at one point that if you attempted to instantiate a Role, then an anonymous class was generated that "does" the role.
nothingmuch existing == methods in place
PerlJam (perhaps that's changed)
nothingmuch roles cannot override things in the class (in theory)
in Moose you can do that though
ruoso PerlJam, yes... that's not an instance of the role...
nothingmuch which is probably naughty
PerlJam ruoso: but it looks that way from the outside. 19:55
ruoso PerlJam, ok... but "looks like" != "is" :)
FurnaceBoy_ url for roles?
nothingmuch duck typing ;-)
anyway, i'm off
PerlJam FurnaceBoy_: dev.perl.org/perl6/doc/design/syn/S12.html
nothingmuch Juerd: i hope i helped more than I harmed ;-)
PerlJam FurnaceBoy_: read the whole thing :) 19:56
FurnaceBoy_ thx
Juerd nothingmuch: You've all harmed more than helped, I'm afraid. 19:57
Before, I knew nothing about the subject
Now, I know the differences, but seriously and heavily doubt that it's useful to still have classes.
Or, that it's useful to have roles, if protection in MI fixes the main problem too.
particle_ a little learning is a dangerous thing 19:58
Juerd I really do not understand why we would ever need both classes and roles.
particle_ well, it puts the burden of constraint on the programmer, instead of on the language designer 19:59
Juerd And I don't understand when inheritance is better instead of composition - regarding semantics and use.
PerlJam Juerd: you can't have roles without classes. Roles only make sense when you can compose them into a class.
Juerd particle_: That's my major concern indeed.
PerlJam: Sure, but that's because it's designed like that.
PerlJam: It doesn't have to be like that. Roles could have constructors.
PerlJam Juerd: But think of roles as reusalbe bits of behavior that aren't tied to a particular class, but can be used in any class (to facilitate duck typing for instnace)
pasteling "stevan" at 71.234.63.100 pasted "Roles as "Kinds"" (36 lines, 589B) at sial.org/pbot/17231 20:00
stevan Juerd: please look at this paste
particle_ pj: not any class... unless they're specifically designed for that
Juerd PerlJam: Being tied or not isn't terribly relevant for semantics, is it?
stevan this is where the traditional isa model can break down
PerlJam particle_: what do you mean?
Juerd stevan: Understood. But is there any isa model that cannot be expressed equally in roles? 20:01
stevan Juerd: dunno, I havent tried them all yet ;)
Juerd Have you ever encountered one?
stevan Juerd: not that I can think of no 20:02
Juerd Why would we support traditional inheritance if we could mechanically translate without breaking anything...
Or - why would we not just implement inheritance in terms of composition.
stevan Juerd: because composition and inheritence are two very different things
Juerd ...
stevan In composition, the methods are copied into the classes namespace
more aliased actually 20:03
PerlJam Juerd: why would we use C++ if we can use C with macros?
Juerd stevan: Does that *matter*?
stevan Juerd: yes,
you cannot dynamically uncompose a role
Juerd stevan: Why would I, a programmer, care about why Baz's methods work on an instance of Foo?
stevan Juerd: *you* may not, but *i* might
Juerd Why would you, a programmer, ...
stevan it all depends on how black you want your OO box to be
Juerd: I like metaclasses :) 20:04
Juerd Is there any difference in semantics, for an end user that doesn't play with internals or metamodels?
stevan Juerd: probably not all that much
Juerd If you play with metamodels, you're likely to draw your own plan anyway :)
stevan however, compsition is a much more 'final' act
Juerd Would anyone be hurt in any way if roles had constructors, "class" was an alias for "role", etcetera? 20:05
stevan yes,.. me :)
Juerd And if you had no way of knowing that it was an alias?
Ignore your knowledge of internals for a second
stevan ok
then yes, you are correct
in fact the last P6 metamodel prototype had : Role.isa(Class) and Class.does(Role) 20:06
which made classes and roles completely interchangeable
Juerd Why spend any effort on blocking this interchangability? 20:07
On implementing two models when one is a subset of the other, in practical terms?
TimToady roles are immutable. classes are mutable.
Juerd TimToady: Can you explain that with an example?
stevan actually let me clarify ,.. they were not 100% interchangable
TimToady I never do examples.
My brain doesn't work that way.
stevan Class handled the method dispatch and isa relationships 20:08
TimToady especially when I'm overdue for lunch...
stevan Roles just handled methods and attributes
TimToady: why are roles immutable?
TimToady biab &
Limbic_Region just gets mean when he hasn't had sufficient sustenance
. o O ( I probably get stupid too but am too busy being mean to notice ) 20:09
Juerd TimToady: Perhaps not an example, but further clarification of what exactly is (im)mutable, then?
20:09 justathe1ry is now known as justatheory
stevan Juerd: immutable == cannot be changed , muttable == can be changed 20:10
Juerd stevan: Would it be bad, in practice, to have one thing that does both method dispatching, and methods and attributes?
stevan: What cannot be changed. The name, the value of attributes, the composition/@ISA, the virtual array of methods, ...?
stevan Juerd: of course not, thats what a class does
Juerd: ask TimToady, I dont see roles as immutable myself 20:11
Juerd You keep speaking in terms of definitions, instead of requirements. That constantly makes me think there's a huge XY problem.
It appears you're not solving any actual problem, just shifting the landscape because it's a fun exercise, because you think it's needed (without being able to explain why it's needed) -- that can't be true, given your levels of competence. 20:12
Each requirement usually has a motivation, like "speeds up development" 20:13
or "makes implementation easier"
stevan Juerd: have you ever made a class, which was not "complete"
Juerd or "makes things predictable"
this just seems to "add another way to do it", which I can't really grok to be very reasonable :)
stevan: Yes, and I already understand that roles are better than classes in many occasions 20:14
I just don't understand yet why difference between classes and roles is needed.
Or what benefit it has.
stevan because sometimes you want an inheritence relationship 20:15
and sometimes you want to compese
compose
if two methods conflict in a composotion, then it dies
if you are using MI
then it lives
without an isa() relationship, you dont have a superclass 20:16
Juerd You've said that, and I asked why you would want inheritance instead of composition -- as consuming methods or inheriting them makes no practical difference for as far as has been explained to me.
stevan to call SUPER::foo()
you can't call SUPER:: if there is no SUPER:: to call
you can handle this manually like in C++, and call Bar::foo 20:17
Juerd Couldn't there be a SUPER with roles?
stevan nope
Juerd Why not?
stevan there is no super relationship
roles are composed
a role does not have parent roles
Juerd The model of the composition could be stored 20:18
stevan it only has a list of roles which it is composed with
Juerd: now you have classes
its very circular
Juerd Quite.
That's my gripe
stevan add a little to roles, you get classes
take a little away from classes,.. look you got roles
Juerd There's no fundamental difference that seems important enough to me to differentiate.
stevan i just said it
SUPER::
Juerd Oh, nevermind. 20:19
20:19 aufrank joined
stevan and since when roles compose they dont care about ordering 20:19
Juerd We're not getting anywhere.
I have no idea what approach to take to explaining classes and roles tomorrow. 20:20
20:20 qu1j0t3 joined
stevan skip it :) 20:20
Juerd I can explain how to use them.
I can explain that roles have protection, and that classes have SUPER
stevan Juerd: to be honest, my guess is that you wont use them much 20:21
Juerd But I can't explain WHY to use them.
stevan I will use them more
Juerd And I can't explain why classes don't have protection, and why roles don't have SUPER.
stevan nothingmuch will probably use them too
chromatic better use them, there were his idea to put them into P6
Juerd I think it's wiser to have one thing, that does both what roles do and what classes do. 20:22
I'm not convinced that a hybrid is impossible.
stevan Juerd: it is not impossible 20:23
but if you have to do it,..then I would rather have classes, which can be composed into one another like roles, as well as inherited like traditional classes
Juerd They're not incompatible. Well, they are, but only by design, and not as a result of anything else. 20:24
stevan yes basically
Juerd I think that's incredibly stupid.
stevan however,.. how would you compose an isa() relationship?
if isa() relationships are order sensitive
and does() are not order sensitive 20:25
20:25 amnesiac joined
Juerd It does make sense to not be able to consume a class that inherits. 20:25
stevan then when I compose a class into another class, how do I deal with any isa() it hash
Juerd: there are a lot of edge cases
Juerd There are?
stevan I wont even start on the composing of attributes
Juerd Are they documented somewhere?
stevan my test suites
the traits paper 20:26
(you have to probably read them all though to get a good list)
Juerd Test suites are driven by definition, or are the definition. They're typically not driven by requirement or problems.
stevan Juerd: I wrote tests to assure that the edges cases succeeded or failed as expected
trust me ,.. they exists 20:27
Juerd Books have to be written about this, tutorials too. Perl itself needs documentation. Example code needs to exist. This is something new to most people.
stevan yup
totally agree
Juerd This better all be around by the time Perl 6 is released.
Because I think Perl 6 will die of ridicule if it's not :(
stevan Juerd: traits/roles are getting a lot of buzz in teh OO community 20:28
Juerd Understandable.
stevan there are implementations in Java, Smalltalk, C#, C++ (i think), Perl
Juerd But keeping classes. I'm not sure that that is smart.
stevan we wont be laughed at for having roles
Juerd I'm not laughing, indeed.
stevan Juerd: getting rid of classes is not smart :)
they will laugh at us for that for sure 20:29
Juerd stevan: If roles are modified slightly to do what classes did, nobody would notice.
stevan Juerd: but then you have a whole new set of edge cases
Juerd: to be honest, I think you might want to attempt to write an implementation
roles sound really simple until you try and actually make the damn things work 20:30
Juerd A set of edge cases that are documented and return useful diagnostics is easier to handle than two different models used together, which are incompatible by design but one depends on the other, again, only by design.
stevan Juerd: I am not the designer, so I cannot speak to the "by design" restrictions 20:31
but knowing the guts of how classes work, and the guts of how roles work, I think you are simplifying things a little too much
ruoso one thing I think I agree with Juerd is that roles and classes are much like the same thing...
the difference is in the use of them 20:32
stevan if *everything* inherits from Object, then you can never have a class which does not inherit
and Obejct is where .new() lives
Juerd if, indeed
stevan Juerd: so now we are back to making out own constructors all the time?
stevan doesnt wanna stick with p5 20:33
Juerd But that everything inherits from Object is a design definition, not justified by any reason that leads back to increase of productivity.
stevan wrong
Juerd You could have a role Constructor.
And compose that into your role.
stevan this is only slightly better than having to write sub new { bless {} => shift } all the time 20:34
Juerd "Object has .new, so if X doesn't inherit from Object, you can't re-use the .new method and have to roll your own." is bad logic.
Especially if roles are primarily meant for code reuse
stevan X will *always* inherit from Object 20:35
Object might be composed of the Constructor role
that works
Juerd If having to type "does Object" is the problem, then "class Foo" can be a macro that expands to "role Foo { does Object;"
stevan Juerd: please read the trait papers
Juerd I'm off to read the traits paper.
The 143 page one that I just printed.
stevan enjoy :) 20:36
Juerd Did I mention that the workshop starts at 8:00, and that it's 22:35 here?
20:36 coumbes joined
stevan I hope you printed the one about the smalltalk coll hierarchy? 20:36
ruoso anyway...
Juerd stevan: Dunno.
stevan Juerd: send me a plane ticket, I will be glad to come help ;)
PerlJam I was away for a while, but it still sounds like Juerd is almost arguing "Why do we have C++, I can do all that stuff in C"
ruoso what if role and class are the same, but you still have isa and does
?
Juerd Traits - Composing Classes from Behavioral Building Blocks
PerlJam (almost, but not quite)
Juerd stevan: I'm not convinced you could help.
stevan Juerd: help? oh no,.. just entertain and annoy :) 20:37
ruoso heh
Juerd stevan: Your explanations are recursive, and that doesn't work with an audience that doesn't have this in their minds yet.
stevan Juerd: sorry, I am a very meta-circular guy
Juerd Things that "just are", are great only if they've "just been" for at least a generation. 20:38
stevan Juerd: if we want we can talk about how Class is an instance of Class
Juerd No, thanks.
stevan :)
Juerd I understand THAT, by the way.
But only because it's explained by terms I'm already deeply familiar with.
s/by/in/
stevan yes 20:39
Juerd I wouldn't understand that if I were new to OO.
stevan roles can be defined in terms of roles as well,.. but its a little weirder
Juerd Well, the DEFINITION of roles is no problem. I can do that.
I can't explain why we need both classes and roles.
explaining things is much harder than defining them.
ruoso because of the constructor?
stevan Juerd: read the papers,.. they are much smarter and more articulate than I will ever be
Juerd You should try it. It's a nice exercise. 20:40
stevan Juerd: not my thing ;)
arguile Can you reference the papers you're talking about again? I didn't catch them and the discussion sounds interesting
stevan waves goodbye to Juerd and then promptly falls off the cutting edge of OO
Juerd ruoso: That's definition again. The definition is that roles don't have constructors, and cannot be instantiated. But they COULD.
stevan arguile: see here www.iam.unibe.ch/~scg/Research/Traits/ 20:41
Juerd The paper I'm reading now is titled Traits.
20:41 justathe1ry joined
ruoso Juerd, but then the constructor would conflict while composing 20:41
PerlJam Juerd: I believe it was Richard Feynman who said something like, "If I can't explain it to a college freshman, then that I means I don't understand it" Regardless of what he actually said, the sentiment is quite true.
Juerd Subtitled Composing Classes from Behavioral Building Blocks.
stevan arguile: I recommend the 1st and 3rd papers
Juerd ruoso: Only because of definition.
ruoso: Sorry, but I'm going to ignore you for a while.
arguile stevan: Thanks
stevan arguile: your welcome
Juerd: I got a shout-out in "Traits ? Composing Classes from Behavioral Building Blocks" 20:42
he talks about Class::Trait and how it comparse to the smalltalk model
Juerd stevan: I'm approx 100 pages removed from that part.
stevan :) 20:43
stevan wonders why the dutch read so slow ;)
Juerd IRC
stevan :D
Juerd Oh!
Can someone re-model Mail::Box to incorporate roles?
(without implementation) 20:44
Maybe that would help.
stevan goes to look
Juerd It uses inheritance quite heavily
So there must be cases where composition would be better...
PerlJam Are there any prototype roles stuff in the pugs examples? 20:45
stevan Juerd: the first bit i see is all his has-a relations
Mail::Message has-a Mail::Message::Body and has-a Mail::Message::Head
those could possibly be roles 20:46
PerlJam ah t/oo/roles 20:47
Hrm.. those tests look mostly like roles-as-interfaces 20:48
stevan Juerd: I would also suspect that if you broke down the Mail::Box::Message:: subclasses, you could make some of them into roles
Juerd Foo is Bar, Bar does Quux. Quux has a method xyzzy. Does Foo have xyzzy?
20:49 pmurias joined
stevan yes 20:49
inherited from Bar
Juerd stevan: Shouldn't has-a be implemented with, err, "has"?
stevan Juerd: you can do it that way 20:50
Juerd has Mail::Message::Body $body handles *;
(What's the syntax for saying you handle all the thing's methods? :)
)
stevan which is very similar to doing it as a role
PerlJam Juerd: that looks good to me (considering *'s new role (heh) as the Whatever indicator) 20:51
Juerd Are role attributes that do not have accessors accessible from the class that consumes the role?
stevan Juerd: this is one of those ugly edge cases
the assumption is yes
Juerd PerlJam: You have no idea how much I've been avoiding non-technical uses of the word "role" today :)
stevan really has to go walk the dog 20:52
and I fear I am disturbing Juerd's reading :)
Juerd What reading? 20:53
Ohh, you mean that stack of paper that has page 2 on top?
stevan woofs
Juerd Is there a way to indicate that your role requires methods it doesn't define by itself? 20:54
stevan Juerd: yes, ... role Foo { method bar { ... } }
any class which comsumes Foo will be required to implement bar
PerlJam stevan: overloaded use of ellipsis there. 20:55
Juerd But that doesn't fail until runtime
stevan PerlJam: :)
Juerd: no, it fails at class composition time
Juerd Then an older definition no longer holds. Okay. 20:56
20:56 weinig|away is now known as weinig
PerlJam Hmm 20:56
stevan Juerd: by "older" do you mean one from a superclass?
Juerd I'm considering not explaining Perl 6 *classes* tomorrow.
stevan: No, in time.
stevan: The definition that ... does fail() - fail() is imperative, so assumed to be runtime. 20:57
20:57 Gothmog_ joined
Juerd "Forget classes, use roles." 20:57
stevan ~ time is fleeting,... madness,.. takes its toll ~
Juerd "And here's how:"
PerlJam Juerd: you could just leave roles as an interesting, if confusing topic at the end and then give them links to go look up stuff for themselves.
stevan does the Time Warp and goes to walk the dog for real this time
21:00 kanru joined 21:01 cdfh joined
nothingmuch is completely out of focus: 21:01
i read this: "Patrick R. Michaud Re: lvalues and "is rw" parameter passing" as "lvalues and is r 21:02
Juerd PerlJam: But I think roles are easier to explain, and more useful.
nothingmuch walue parameter passing"
and i asked myself why is he contradicting himself?
Juerd Blergh. They DEPEND ON classes, so if I explain roles, I have to do classes too
PerlJam yep 21:03
I think it's interesting that a role-method will hide an inherited method of the same name and a class-method will hide a role-method 21:07
I don't remember the justification for that ordering.
But coupled with roles that define but do not implement methods, there doesn't appear to be a way to say (in the role), "the class that this role is composed into must have a foo() method" and have that foo() method come from a superclass. 21:09
(unless you just happen to define things that way)
21:12 justatheory joined
PerlJam Hm. I guess you can do role Foo { proto method bar { ... } } class A { method bar { print "hi" } }; and class X is A does Foo will use A's bar method 21:15
PerlJam really needs to re-read the synopses
Juerd feather.perl6.nl/~juerd/classes_roles.png 21:16
Is that more or less correct?
aufrank Juerd: did you mean to label the individual bubbles? 21:17
or am I supposed to recognize the structure without any labels?
PerlJam I would guess that the red things are classes and the blue things are roles. 21:18
aufrank I get it 21:19
azuroth it's nine below zero!
aufrank are you asserting that what I get is nine below zero? 21:20
Juerd Image updated
azuroth no, I'm saying it's cold!
Juerd PerlJam: If that's obvious, then I did something right: ) 21:21
PerlJam Juerd: yep :)
Juerd aufrank: If I did it right, unlabeled should speak for itself.
Try the updated image, which indicates more impossibilities
Eh
PerlJam um ... the image looks the same.
Juerd Right.
Still had to enter my password 21:22
PerlJam ah, better
Juerd I hope my audience will not have many colour blind people in it :)
aufrank at least you used blue and not green 21:23
Juerd aufrank: I knew about that :)
ruoso is color blind, but saw it clearly
azuroth a class can't own a role ?
21:23 marmic joined
Juerd azuroth: Nothing can "own". 21:24
azuroth (is that what the red to blue with black line is)
PerlJam azuroth: "own" doesn't make sense. Pick another verb.
azuroth: that's "inherit"
azuroth ahh
Juerd inkscape++ # quick drawings 21:25
aufrank Juerd: I remember something about being able to "does" a class
do you know if that's still around (or if it ever was)?
azuroth isn't that what the left parts are?
Juerd aufrank: What has been said here the past few hours indicates that that isn't possible.
azuroth: No, those are classes that consume ("do") roles 21:26
azuroth oh, sorry, read that wrong
thought before typing :-) probably need a coffee
aufrank ok. I am pretty sure I remember some handwaving about a class also being available as a role for the purpose of composition
Juerd This will be the first time I have a diagram in a talk. 21:27
aufrank but it makes more sense without that
Juerd stevan: When you're back, please review feather.perl6.nl/~juerd/classes_roles.png 21:30
stevan Juerd: looks sane, but more details would help to confirm that assumption 21:31
stevan has to go cook dinner though
Juerd stevan: What kind of details? 21:33
qu1j0t3 nice diagram 21:34
Juerd Added legend 21:39
aufrank Juerd: do you want to add any dotted lines to the role that does another role? 21:41
Juerd Dotted line means "is the same thing"
aufrank well then maybe add that to the legend, as lubs like me might not get it ;) 21:43
and anyway, isn't the role within a role the same thing as one of the external roles?
if the three roles are A, B, and C, B does A or B does C, but I can't tell which because there are no dotted lines from that role in B 21:44
PerlJam aufrank: er, what? He's illustrating that you can build roles out of other roles. Naming the roles aren't important.
Juerd No, the legend gets too crowded then
And certainly I don't want names here. 21:45
particle_ juerd: blue isa blue should also be shown crossed out, i believe 21:46
aufrank I wasn't suggesting names, just that you use the dotted line to convey identity from the "done" role to one of the other roles, just like you did for classes
but it's not a big deal 21:47
particle_ dotted line is like an explosion, to a close up, or something... right?
aufrank particle_: "is the same thing" says Juerd 21:48
particle_ ah, yep. grt.
Juerd particle_: Good one!
aufrank has to leave the office now
good luck on the presentation tomorrow, Juerd 21:49
Juerd Thank you 21:57
(image updated)
21:59 jsiracusa joined
particle_ i can think of a few more relations 22:00
superclass & subclass can't both does role 22:01
(the same role)
Juerd particle_: Documented where? 22:02
ruoso particle_, wouldn't it result in the same thing?
particle_ and there's one more, but it's really messy
wouldn't it conflict?
Juerd I think I don't want that level of detail by the way, but I would like to know more
particle_ i think if the role is defined already, it can't be redefined
that's what "is immutable" means
Juerd particle_: What's there to conflict, if you have two *equal* roles? Absence of order makes me think it's set-like: duplicates are ignored.
particle_ hrmm, maybe that's the case 22:03
PerlJam particle_: sure a superclass and subclass could "does" the same role.
particle_ so parent and child could both specify, but child specification is optional
pj: if parent does it, child does it is implied, yes?
juerd++ # i like this picture a lot 22:04
PerlJam particle_: child overrides role overrides parent as far as method use goes. 22:05
Juerd particle_: There is no child/parent in roles :) 22:06
Oh, nevermind
particle_ the child / parent is in c...
Juerd Too much context switching
(drawing, slides, irc, still browsing through the traits paper)
particle_ ...and not sleeping 22:07
Juerd What's the syntax for an "is rw" method? 22:11
Does it return an lvalue like in Perl 5?
particle_ class Bar is rw { 22:13
has $.readwrite_attr;
}
Juerd No, not an automatically generated one :) 22:14
particle_ $bar.readwrite_attr++; say $bar.readwrite_attr; # 1
Juerd I want to show what's generated
particle_ oh
Juerd But it's perl5 lvalue-like
So boring 22:15
Skipping...
particle_ wanders off for a bike ride 22:16
mugwump so. how are type constraints (subset) supposed to ever be applied at compile time? 22:19
22:42 fglock left
TimToady mugwump: by basing them on something immutable. 22:48
but the main point of typing in P6 is not type safety so much as MMD. 22:49
Juerd TimToady: /home/juerd/classes_roles.png
TimToady: Do you think I have the most important uses and impossibilities covered?
TimToady you wanna try that url again?
Juerd Ehm, hehe :)
TimToady: feather.perl6.nl/~juerd/classes_roles.png 22:50
The weird thing is that I have no idea how that /home "URL" ever made it into my browser.
I never type that...
(in a browser)
(in a browser's address bar)
TimToady they know where you are... 22:51
Juerd Apparently :)
mugwump TimToady: it would just be nice if code that it impossible to run because of conflicting type constraints could be noticed during compile time 22:53
TimToady if the type constraints are based on immutables, then it can be known at compile time.
mugwump where are those described? I think I misunderstood your answer the first time 22:54
oh, n/m, found it 22:55
TimToady roles are basically immutable once they're defined. they fill the role of closed classes without being closed classes.
stevan doesn't quite see them that way, but that's because he's thinking about the infrastructure behind them.
mugwump right. oh, cool, a Tuple type
TimToady Tuple? we got rid of that. 22:56
it's now Seq.
what are you reading?
mugwump It's on S02
TimToady not any more... :) 22:57
Juerd TimToady: No "role Foo is also { ... }", then? 22:58
TimToady: Or would you have to do "role Foo does Foo is instead { ... }"? :)
TimToady phone...
Juerd role Phone does Ring
mugwump I had a thought before, you should be able to curry types... 22:59
though an explicit syntax for it is probably unnecessary 23:00
Juerd has 34 slides 23:01
Should be more than enough.
For 45 minutes :)
mugwump: Hm? Str.assuming(...)?
:)
mugwump role Mapping [ Key does eq, Value ] { }; role Hash [ Value] is Key [ Key does str, Value ] { }
or something like that 23:02
in that instance, "Hash" is a curried version of "Mapping"
Juerd Can []-parameters/arguments be used with classes too?
mugwump I don't think that makes sense 23:03
I agree with roles being parametric, but classes are concrete
TimToady "role Foo is also" is like saying "for large values of 2" 23:05
Juerd Why? 23:11
mugwump a mismatch of concepts; roles don't capture "is"-ness 23:13
(guess)
23:19 rashakil joined
TimToady classes are type containers; roles are type values 23:19
23:20 Quell joined
qu1j0t3 's head explodes 23:23
23:27 _meppl joined
mugwump classes is, roles do. Therefore it makes little sense to say what roles are 23:28
makes about as much sense as trying to infer substance from observation
TimToady you're using substance in a rather medieval sense... 23:29
mugwump role Existence is Turtles_All_The_Way_Down { ... }
Hmm, perhaps "Observable_Universe" beats "Existence" there 23:30
ah, better not keep trying to combine metaphysics and programming. usually gets me into trouble :) 23:31
23:33 rashakil_ joined 23:58 obra_work joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!