Should we include exercises? | IRC logs: irclog.perlgeek.de/perl6book/today | source: github.com/perl6/book/
Set by moderator on 8 November 2009.
03:22 snarkyboojum joined 10:22 mubot joined 12:55 masak joined 14:22 PerlJam joined 18:17 lichtkind joined
jnthn 40 mins to meeting? 18:23
moritz_ right
jnthn 'k
moritz_ my report for this week: 18:38
about two typo fixes
read the awesome diffs from chromatic++
that's about it
dalek ok: 30057bc | masak++ | src/basics.pod:
[basics] more minor fixes
 18:43
ok: a6cee3d | masak++ | :
Merge branch 'master' of github.com:perl6/book

  \tsrc/basics.pod
ok: 25e3c18 | masak++ | src/classes-and-objects.pod:
[OO] added three questions

to have exercises), or they could perhaps be incorporated in the text itself. I plan to write full answers to these three questions as well.		 19:00
19:01 pmichaud joined
PerlJam greeble 19:02
pmichaud hola
moritz_ oh hai
jnthn oh hai
moritz_ please see the question in /topic 19:04
exercises yes/no?
moritz_ votes for "yes, where appropriate" 19:05
PerlJam I wouldn't call them "exercises", but I vote yes too
jnthn I'm happy enough to have them, yes. 19:06
(more)
moritz_ PerlJam: how would you call them?
PerlJam I'd say "things to try" rather than "exercises".
the latter seems less fun than the former
jnthn I wonder if we could somehow make them relate to the examples too.
Like, "grab the example code for this chapter, and then extend it to do X" 19:07
moritz_ has lots of ideas for "things to try" for the first chapter
jnthn Maybe that won't always be appropriate though.
pmichaud I think "things to try", "exercises", or "What next?" would be a good thing to have
moritz_ on noes 19:08
netsplit
moritz_ can't see jnthn anymore
PerlJam you know what he looks like :) 19:10
moritz_ ok, so we have no objections to excercises
any other things we want to discuss? 19:12
PerlJam Where to focus? 19:14
Do we want to try to polish a particular chapter?
or still just "write stuff"?
moritz_ writing the subs chapter
or extending the basics
would be my suggestion 19:15
19:18 mberends joined
dalek ok: 5a61748 | masak++ | src/classes-and-objects.pod:
[OO] added answer to the first question
 19:18
19:22 masak joined
masak sorry I'm late. I got logged off and didn't realize it. 19:23
PerlJam: "things to try" works for me. 19:24
I find I have lots of extensions to write about for the OO chapter, whose example I created,
moritz_ anything else we want to discuss? 19:29
masak people are welcome to read and comment on the exercises I just committed. 19:31
that also forms the whole of my report for this week. :)
moritz_ ok, then let's adjourn what remains of this meeting ;-) 19:32
mberends skims masak++'s OO chapter 19:33
masak well, it's my example. jnthn++ wrote most of the explanations. :) 19:34
mberends masak: Q: doesn't it say somewhere that roles should be the primary container for methods?
masak mberends: never heard of such a thing.
mberends "behaviors" as S12 puts it 19:35
masak how could that be a practical rule-of-thumb?
mberends dunno, just read it sometime
masak I guess I'd still treat such roles as classes, using punning.
moritz_ that doesn't work if you teach about classes (but not roles yet)
mberends consults S12
masak even apart from that, I personally believe that Task should be a class. 19:36
YMMV.
mberends masak: S12:87 19:38
masak reads
mberends: funny, I read that totally differen.t
mberends nobody seems to follow that advice yet
masak s/\\.t/t./ 19:39
mberends: 'factor out common code' as in avoid re-defining the same method in various places in a complicated class hierarchy.
not as in putting all methods, evar, in roles.
mberends the implication is: people, you're often using classes when you *should* be using roles 19:40
masak aye, sure.
cf. Ovid's blog posts.
mberends right
hence my Q: is there an opportunity for the OO chapter to mention roles? 19:41
masak that's a different Q :) 19:42
mberends heh
masak I don't see why not.
but so far I've only been writing stuff for which I have good examples.
jnthn++ has been thinking a bit about parametric roles, I know.
so I leave it to him, for now.
mberends ok, whatever jnthn++ writes will be good. guaranteed. 19:43
masak: I'll try to think of a different example to add to the OO chapter, involving inheritance and/or roles. 19:45
19:47 dukeleto joined 19:48 carlin joined, hicx174 joined, japhb joined
PerlJam I think the OO chapter should mention roles *before* inheritance. 19:48
masak mberends: the chapter is currently called classes-and-methods. arguably, roles should sit in a different chapter, or the chapter should be renamed.
19:49 jnthn joined
PerlJam roles should be given prominence as the preferred mechanism of code reuse. 19:49
jnthn uff. That netsplit is a pain.
Been reading in the log. :-) 19:50
On the roles thing...
mberends masak: it would be nice to mention roles alongside classes
masak jnthn: welcome back!
jnthn tbh, while I think roles are great and their use should be encouraged, I also think there's a place for classes too. 19:51
masak mberends: nod. patches welcome. :)
jnthn: aye.
jnthn There's 2 aspects to draw out here.
imho anyway
mberends masak: patch should only take a couple off weebs ;)
masak :P
jnthn The first is that does and isa are different relationships, fitting different situations. 19:52
masak there's something to be said for teaching classes first, and then layering on roles.
mberends aye
jnthn The second is that classes *still* are the thing in Perl 6 that handles instance management.
mberends ayaye
although you can "new" a role and it gets punned
masak mberends: yes, but that's still a class being instantiated. 19:53
dalek ok: 5992bee | masak++ | src/classes-and-objects.pod:
[OO] added answer to the second question
masak is having too much fun writing these answers 19:54
jnthn So I think the valuable question is probably something like, "does the example in the OO chapter show something that's a reusable chunk of functionality, or is it more related to management of data related to an instance of something"?
19:54 dalek joined
jnthn Of course, that's a blury line. :-) 19:54
mberends yes it is 19:55
jnthn I think ideally...
* Classes are presented first if only because they're so much more familiar to people. That means we can introduce the has/method keywords without having just thrown the concept of roles at the reader. 19:56
* If we can manage it, the example that presents classes is something that is not so much an obviously reusable chunk of functionality
On punning - yes, but it makes a class that does the role, and instantiates that. I'm not quite sure we can explain punning without explaining what a class is first. :-) 19:57
moritz_ agreed
jnthn What I'd like to avoid is to introduce roles by saying "well, in the previous example, we used a class, but really it was a bad example and we shoulda done it as a role" 19:58
mberends and I'm confused by combining two guidelines: 1. you should use roles for behavior inheritance 2. you can use roles punned into classes for instance management. Mistaken conclusion: do everything with role definitions, you'll get punned classes whenever it seems to be necessary.
the keyword 'class' appears to be redundant 19:59
moderator irclog.perlgeek.de/perl6book/today | source: github.com/perl6/book/ 19:59
jnthn mberends: I'd s/inheritance/composition/ in there. 20:00
I can see the temptation to come to that conclusion. 20:01
mberends is blissfully confused, and not bothered by that
jnthn I kind of see classes as still representing entities, and roles as being building blocks of functionality. 20:02
I guess the other distinction is about mutability. 20:03
(Roles are immutable, classes not) 20:04
mberends but the class created by punning a role is a class, therefore mutable 20:05
jnthn But I'd like to hpoe that one doesn't come into play too often. :-)
masak my third answer prompted an interesting follow-up question about thread safety.
dalek ok: 55a54bc | masak++ | src/classes-and-objects.pod:
[OO] added answer to the third question
masak but overall, I really like how those three questions show the extensibility of the example.
jnthn masak: It's safe 'cus we didn't implement threads yet.
;-)
masak (and the versatility of Perl 6)
jnthn: :)
jnthn mberends: That doesn't change the fact that if the role is done, it's still the unchanged role that you're doing. 20:06
mberends: It's basically like: $pun = class :: does R { } 20:07
mberends jnthn: if a misguided programmer (me, for example) tries to uses 'role' everywhere, at what point does that approach fail? 20:09
jnthn mberends: In a sense, it probably does not. 20:11
mberends: In another sense the system now doesn't distinguish chunks of functionality from entities.
I guess that's a "documentation" point. 20:12
mberends nom & 20:13
jnthn :-)
PerlJam mberends: Ask Ovid. :) 20:24
21:41 japhb joined 23:02 mubot joined
mberends oh. the meeting is over. goodbye. 23:31
23:31 mberends left

Powered by Cro and the Raku® Programming Language.

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

Thank you!