abstraction sketching

[EECOLOR]

Changes:

names I think important concepts should have clear names.

For AKey I just chose Key. AttributeKey was too much space for the concept and there was not much of it tying to attribute. The A in AKey did not add much, I kept reading it as 'a key'.

For KVPair (previously name Attr) I chose Attribute. I felt there was no value in separating the mechanism from what it's used for. It also made the Metadata class more readable. As for the length of the name (compared to Attr), I think it's justified. If you want to use the short version in non-user facing code, we could add an alias for that.

implicit keys are (again) lowercase and vals

Lower case so they can be more easily identified during debugging. Making them an object required the use of extends which caused an imbalance where the key had the same name as the value.

Key is now final again

You can explain the benefits of this better than I can.

exposing attributes of metadata

I am convinced that we should not force the user of the code to jump through hoops because we made a certain property private.

And some other minor changes. Let me know what you think.

[EECOLOR]

Ohw, I also added an apply on the Empty class that allows for Empty[A] to return the empty value for A

[paulp]

Key is too generic a name for a top level type unless you want to obtain specificity from the package, meaning it can be called Key if it's in a metadata package.

Both "empty" and "apply" are used so heavily throughout scala code. When you start combining things and have to have some idea what's going on, these names are liabilities.

It's very intentional that the type class member method is not called apply. Imagine another dozen type classes, each with one method. Do you call all the methods apply? It locks you out of composing typeclass code in a single instance, but more importantly it's just confusing as shit.

[paulp]

Oh, you mean on the Empty object. Probably I should have looked at the code first.

[paulp]

The apply you added is in the package object in psp-std, and I prefer that arrangement. I could go for either empty or emptyValue.

def empty[A](implicit z: Empty[A]): A = z.emptyValue

[EECOLOR]

I prefer that arrangement

Go with whatever you like best :+1:

[EECOLOR]

Both "empty" and "apply" are used so heavily throughout scala code. When you start combining things > and have to have some idea what's going on, these names are liabilities.

Not sure where you are pointing at

[paulp]

I wasn't, I was talking crazy. I thought you were talking about a different thing.

[paulp]

I'll merge this and tweak it a little further and also rename the packages.