Fork me on GitHub
#clojure-dev
<
2016-01-18
>
mikera03:01:56

FWIW it seems unfortunate that 'conj' is misnamed 'cons' in the Java source for IPersistentVector. Apart from the confusing naming, it means that you can't have a Clojure vector that also implements ISeq because the names clash but have different required semantics

meow03:01:12

that's odd

ghadi05:01:49

I think if Clojure had a do-over some of the impl hierarchies would be realigned

ghadi05:01:56

but you don't get no do-overs

bronsa09:01:20

@mikera: I don't think that's true. cons is IPersistentCollection/cons, backing all the conj implementations

bronsa09:01:47

ISeq doesn't have a cons method, clojure.core/cons is just new Cons(..)

mikera09:01:26

ISeq does have a cons method, returning ISeq

mikera09:01:06

This gets called with cons semantics in various places in the Java code base

mikera09:01:17

I seem to remember trying to make something that implemented both ISeq and IPersistentVector, and it broke a few things anyway....

mikera09:01:12

Could possibly be fixed, but either way the name is confusing.

mikera10:01:52

I think the root cause of the problem was that anything implementing ISeq has to return another ISeq, but that doesn't work if you implement a vector which wants to return a different vector type (e.g. a small tuple overflowing to create a clojure.lang.PersistentVector)

bronsa11:01:03

ah, I see what you mean

bronsa11:01:41

ISeq/cons is just IPersistentCollection/cons with a covariant return type

bronsa11:01:54

it's still the conj implementation

bronsa11:01:42

I think that the problem is that RT.conj sequentially tests the object for ISeq and then IPersistentCollection

bronsa11:01:13

and invokes the most specific method