brainstorming lists: gist.github.com/203173 paste.lisp.org/display/88288 IRC logs: irclog.perlgeek.de/perl6book/today source: github.com/perl6/book/
Set by moderator on 9 October 2009.
11:13 masak joined 17:17 dalek joined
moritz_ I CAN HAZ PUSHED TO book, BUT dalek EATED IT 18:18
anyway, I'd appreciate review of the MMD chapter
jnthn oh noes!
moritz_: I'm refraining from further coding today to do book tasks. ;-)
moritz_ ;-) 18:19
jnthn moritz_: Something to commit to the OO chapter comes first, and then I'll try and review your MMD bits. :-)
moritz_ great
jnthn Just giving my OO scribblings a read through, then commit coming. :-) 21:21
dalek ok: 2873520 | jonathan++ | src/classes-and-objects.pod:
Start writing the classes and objects chapter, based on the already committed example.
 21:30
jnthn I've got some ideas for adding to that to cover some more OO features too, but that explains I think all of the example. :-) 21:31
moritz_ jnthn: the things I wrote so far also cover more than the initial example
jnthn moritz_: nod 21:32
moritz_ jnthn: which IMHO is a good thing, because you should be able to understand the example rather soon
jnthn moritz_: I intend to discuss other features as extensions (like, things we could add to the initial example), so far as I can.
Unless it's just way to strained to do so.
*too
moritz_ +1
jnthn But without actually adding them to the initial example code. 21:33
moritz_ for the regex chapter I decided to start with a simple example
and then when the regex features are explained, I start with the JSON grammar
jnthn So that the initial example isn't over-taxing.
moritz_ and takl about grammars, goal matching etc.
jnthn +1 to that approach too
I think we just have to pick what works best for each chapter, but keep "by example" as the philosophy. 21:34
That is, it's better to be explaining code than talking abstract concepts.
moritz_ has a hard time sticking to that
if somebody wants to add more examples to the stuff I wrote - feel free ;-) 21:35
jnthn Yes, it's hard.
moritz_ hej 21:36
I have a nice idea for extending the OO example
jnthn Ooh, do tell. :-)
moritz_ for inhertance
a RandomTask or so
that executes dependencies in random order 21:37
jnthn Actually
I had thought of ParallelTask
moritz_ you could use such things to test the 'make -j ' feature
jnthn Which would give an opprotunity to explain >>. too.
moritz_ without actually using concurrency
+1
jnthn The reason I'm a bit "hmm" about it though...
...is that it's the dependencies that can be done in parallel
Or in a random order.
moritz_ people will ask "why not use real threads?" 21:38
jnthn Rather than the task (as in, the callback).
moritz_ we need a better name, yes
jnthn Like, Task::ParallelDependencies
moritz_ aye
jnthn But that sucks a bit too.
I'm thinking that we maybe have a separate example and even chapter to cover roles. 21:39
moritz_ wfm
jnthn That way, we don't have to be too object-heavy. 21:40
And can even have another chapter inbetween.
On something else.
Or at least, we then have a more managable chapter.
moritz_ well, the OO chapter isn't exactly huge yet 21:41
jnthn moritz_: True.
Well, I've not much feeling for how text here maps to book pages though.
moritz_ the regex chapter is 50% larger already, and still missing most grammar features 21:42
jnthn Hmm
moritz_ (but maybe that needs splitting too)
jnthn To me the bigger motivation was more "separate main example".
moritz_ if we consider saying good-bye to the idea of having just 6 chapters, we can keep the chapters short 21:43
jnthn Oh, I'd always thought that too cute to be practical. ;-)
I wasn't entirely sure if it was a serious suggestion or not at the time.
moritz_ probably just an idea 21:44
jnthn aye
For MMD, for minor fixes, any objections to me just commiting fixes?
moritz_ please go right ahead 21:45
jnthn (spotted a grammar-o)
21:45 colomon_ joined, last_ joined
jnthn One other question 21:47
multi to-json(Num $d) { ~$d }
multi to-json(Int $d) { ~$d }
moritz_ jnthn: you say that 'has $.done' is equivalent with 'has Bool $!done; method done() { return $!done }
jnthn I think the second of those is redundant?
moritz_ shouldn't it be a multi?
jnthn moritz_: It's not a multi today.
moritz_ jnthn: akshually that number business is going to change a bit
jnthn In Rakudo.
Does the spec say it should be?
moritz_ we'll have Int !~~ Num by latest spec
afaict
but rather Int ~~ Numeric and Num ~~ Numeric
jnthn ah, ok
Still that could then become one thingy. 21:48
moritz_ aye
jnthn Anyway, won't change it, just something I noticed.
moritz_ you can add a # TODO: clarify numeric types or so
and in the OO chapter: we should mention explicitly that 'has $.thing' means that inside the class assignment has to happen to the !-twigiled attribute 21:50
jnthn good idea, done that
moritz_ that's something that has bitten just about everybody so far
including masak and me
jnthn moritz_: I do expalin that later on...maybe it should be mentioned earlier too though.
moritz_ oh, I'm not so far yet
jnthn Add a TODO note or jfdi
If you feel strongly it should be earlier than it is, or if it's not strong enough.
moritz_ jfdi++ 21:51
does 'handles' work on array attributes? 21:52
rakudo: class A { has @.a handles <push> }; A.new.push(5) 21:53
jnthn "specially"
p6eval rakudo 827734: OUTPUTĀ«You used handles on attribute @!a, but nothing in the array can do method pushā¤in Main (file <unknown>, line <unknown>)ā¤Ā»
jnthn moritz_: I always feel a bit "hmm" about that bit of the spec.
moritz_ there's something special with delegating to an array?
jnthn Rakudo is following spec here...
Yes
Spec is like, if it's an array then look through it to find an object that can be delegated to. 21:54
And if it's a hash, whine
Note that it goes on the sigil
Not on what's actually inside.
moritz_ erm.
jnthn So if the sigil is $, handles always works as expected.
Yes, "erm" is a good comment on this.
If your delegation object happens to be an array: 21:55
has @handlers handles 'foo';
then Perl 6 assumes that your array contains a list of potential
handlers, and you just want to call the I<first> one that succeeds.
(that's c/p from S12)
moritz_ just read it, yes
jnthn And hash a bit below.
Though that's not implemented.
'cus I'd not so keen on implementing conjectural things when we've enough non-conjectural to do. ;-)
dalek ok: 97f1702 | moritz++ | src/classes-and-objects.pod:
[OO] this sentence no verb ;-)
 22:05
jnthn Verbs overrated. 22:06
moritz_ indeed. 22:07
dalek ok: 639cb7a | jonathan++ | src/multi-dispatch.pod:
Some minor grammar tweaks and other little bits in the MMD chapter.
 22:17
moritz_ jnthn++ # lots of fixes and improvements 22:22
jnthn moritz_: Impression of objects/classes bits? Too gutsy? Too detailed? 22:23
moritz_ jnthn: I think it's very good, but maybe requires too much prior OO knowledge
wrt object/instances/methods 22:24
any general thoughts on the MMD chapter? 22:25
jnthn Well, question is who we're writing for. I was thinking existing programmers, not programmer newbies.
moritz_ right, that's the question 22:26
it
jnthn MMD chapter - for the first example, it depends what comes before it. Like, it assumed .trans
And .join, map, etc
If those have been covered plenty before, that's fine.
moritz_ .trans probably not
we have to add that somwhere
but the rest, yes 22:27
jnthn It may be prettier to use the @things.map({...}).join(...) rather than doing both sub and method call syntax though.
That bit of the code looked a bit of an eye-full mixing them.
moritz_ re OO - I just found it's an area where there's a lot of confusion
jnthn And "what order do those bits get done in"
I didn't spot anything particularly wrong in the explanation of multi-dispatch though. 22:28
moritz_ recently a programmer asked, after half an hour IRC discussion "so an object is the same as an instance? if somebody had told me that before..."
jnthn Hmm, yeah.
moritz_ right, it can use stilistic cleanups
jnthn Aye.
The substr example seemed a bit of a "sudden" jump from what came before to me. 22:29
I'm not sure why.
moritz_ it needs a heading inbetween
jnthn I just did a double take and felt I'd missed something somehow.
That'd help.
It may be that we don't need two arity related examples.
The details on candidate sorting matched up with my understand on the whole though. 22:30
I think multi-methods bit wants to be moved to OO.
moritz_ wfm
jnthn Avoids forward references.
And means we can use an extension to the existing example. 22:31
object vs instance - yeah...I've probably mixed my terms too. 22:32
moritz_ just introduce them as aliases the first time you use them ;-)
jnthn I tend to view them as two aspects of the same thing.
I'll tend to talk about them as objects when I just want to refer to them casually.
But I'd usually say "instance of class X" rather than "object of class X" 22:33
I'd never really thought too much about when I used which. :-)
But you're right, it needs consideration here.
dalek ok: c100c05 | moritz++ | src/regex-and-grammar.pod:
[RX] more about grammars, goal matching
 22:34
ok: dc98ead | moritz++ | src/multi-dispatch.pod:
[MMD] use method form of map consistently
moritz_ I also tried very hard to use I<candidate> very consistently whenever I refer to a single routine, not the whole multi
it sometimes reads a bit weirdly 22:35
jnthn I didn't find it so weird.
moritz_ good
jnthn But maybe I'm just too used to seeing it called "candidate" in the code all the time. ;-) 22:36
moritz_ anyway, bed time here 22:39
good night
(and thanks for the review)
jnthn thanks for yours too - night 22:42

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!