On Apr 26, 4:54 pm, Rich Hickey <richhic...@gmail.com> wrote:
> On Apr 13, 2010, at 9:37 AM, Dan wrote:
>
> > I'm a Java developer; I work on a project that has adopted Clojure's
> > data structures as a convenient implementation of immutable sets,
> > maps, etc. In attempting to add type parameters to the Clojure
> > interfaces, I noticed a conflict in the definition of
> > IPersistentVector. I assume the problem exists when programming in
> > Clojure, too.
>
> You should note that by doing so you are superimposing homogeneity on
> collections that are otherwise heterogeneous.
No, it does not limit expressibility at all to formally state the
constraints on input/output types that are otherwise informal. You
can always use "Object" as the type argument to all these types to
express heterogeneity.
The conflict I'm describing is the same whether the constraints on
interface implementations are formally or informally stated. The type
parameters simply help to clarify the intended contract by expressing
it formally.
> > Put another way, the problem is that if I have anAssociativewhich I
> > know maps integers to strings, and I invoke seq(), I don't know what
> > kind of values I'm going to get.
>
> Objects
...
> One way to look at the Seqable in high-level interfaces is just as
> specifying a sequence of whatever the value type is for the ultimate
> concrete implementation. Java supports return type covariance, so you
> could put a more specific signature on seq for IPersistentMap.
>
> In any case,Associative shouldn't constrain the seq or value type of
> the collection. All it specifies is that, given keys you can get items.
So, to parameterize Associative in a way that properly expresses the
contract you're describing, it looks like this:
public interface Associative<K,V,T> extends IPersistentCollection<T>
{
Associative<K,V> assoc(K key, V val);
...
}
There's no connection (stated formally or informally) between the Seq
element type T and the key/value types K and V. That's certainly
doable; it just strikes me as unnecessarily confusing. The way I'd
design it is to remove the "extends IPersistentCollection" clause
entirely.
Anyway, thanks for helping to clarify the intended meaning.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
