Melbourne Scala User Group Google Group

Re: Questions about Cake patterns

tonymor...@gmail.com (Tony Morris) — Fri, 24 May 2013 00:46:33 UT

I have been moved by Ken Scambler!

--
Tony Morris
[link]

Re: Questions about Cake patterns

ken.scamb...@gmail.com (Ken Scambler) — Thu, 23 May 2013 23:59:47 UT

This is a badge of honour! :)

I'll look further into Argonaut.

Re: Questions about Cake patterns

lo...@me.com (Lachlan O'Dea) — Thu, 23 May 2013 12:29:55 UT

[...]
These practical consequences are what compels me and at least one other guy
I thought this blog post was
good: [link].
I'm not sure if that's the one you meant.
Lachlan.

Re: Questions about Cake patterns

tonymor...@gmail.com (Tony Morris) — Thu, 23 May 2013 11:08:12 UT

Haha, it's just a bad idea that needs to stop existing!

--
Tony Morris
[link]

Re: Questions about Cake patterns

brhutchi...@gmail.com (Ben Hutchison) — Thu, 23 May 2013 11:06:39 UT

Dont worry Ken,

Your Tshirt will arrive shortly ;)

[link]

Ben

Re: Questions about Cake patterns

tonymor...@gmail.com (Tony Morris) — Thu, 23 May 2013 08:14:56 UT

The point is that this effort toward a statement or guideline is (at
least) arbitrary and so apologising along the path of its formulation
(e.g. with handwavy adverbs) leads you into a hole, even when qualified
with those apologies (emphasise: EVEN THEN). This technique, even taking
into account apologetics in any form, leaves you with nothing or a

Re: Questions about Cake patterns

ken.scamb...@gmail.com (Ken Scambler) — Thu, 23 May 2013 06:17:38 UT

Fair enough; that's why I didn't say "never" or "do not". Also, I normally
use runtime checks for my smart constructors, so I probably don't see the
useful cases as much as you do.

Re: Questions about Cake patterns

tonymor...@gmail.com (Tony Morris) — Thu, 23 May 2013 05:55:05 UT

Sure that is a bias. I see way more people using abstract val
appropriately than not.

However, in this case, formulating a rule leads to not only incorrect
information, but discouragement from writing neat code. In other words,
the statement, "do not use abstract val in trait" implies "do not always

Re: Questions about Cake patterns

ken.scamb...@gmail.com (Ken Scambler) — Thu, 23 May 2013 05:44:17 UT

Well the initialisation order thing "generally" comes up a lot when people
use abstract vals, whereas the useful cases (where you need a fixed val as
part of a type path or import) come up less frequently, at least in code
I've seen.

Re: Questions about Cake patterns

tonymor...@gmail.com (Tony Morris) — Thu, 23 May 2013 04:52:13 UT

This is not true.

Without abstract val, many useful constructs become impossible. In
particular, smart constructors and therefore, data hiding. This fallacy
is so prolific that some have gone to the effort of attempting to debunk
it in blogs and so on, but that hasn't been effective.

What is generally a bad idea is (de)referencing an abstract val during

Re: Questions about Cake patterns

agoo...@greatcactus.org (Andrew Conway) — Thu, 23 May 2013 04:48:09 UT

Ah! Thanks Ben. I had wondered about that myself too.

Re: Questions about Cake patterns

ken.scamb...@gmail.com (Ken Scambler) — Thu, 23 May 2013 04:46:55 UT

Bring on trait constructors, whenever they figure out how to do it. It
should be mentioned that it is generally a bad idea to use abstract vals in
a trait (as opposed to just def).

Re: Questions about Cake patterns

brhutchi...@gmail.com (Ben Hutchison) — Thu, 23 May 2013 04:44:17 UT

Hi King,

One difference is that is allows mutual dependence between any number
of traits, whereas inheritance forces the dependencies to be acyclic &
directed.

trait X { self: Y, Z => ...}
trait Y { self: X, Z => ...}
trait Z { self: X, Y => ...}

The idea, as Ive heard it, is that you can break your functionality

Re: Questions about Cake patterns

kinglung.c...@gmail.com (King Lung Chiu) — Thu, 23 May 2013 04:19:54 UT

Hi Ben,

This reminds me of a question I've had for a while:

Since this self-typing effectively mandates that the concrete type
must extend / implement UserRepositoryComponent in order to use the
trait, how is it different to having the trait directly extend
UserRepositoryComponent (without implementing

Re: Questions about Cake patterns

brhutchi...@gmail.com (Ben Hutchison) — Thu, 23 May 2013 02:18:46 UT

Hi Nicholas,

re 1: basically, that means that the current trait must have a
UserRepositoryComponent mixed into it, to be instantiated. In other
words, the this pointer (self) must have type UserRepositoryComponent,
hence the name 'self type'.

So you can assume to any fields/methods that UserRepositoryComponent