>> This always struck me as out of tune with functional programming, and
>> now that I'm thinking about FP and OO hybrids, I can finally figure
>> out why: encapsulation works differently in FP than in OO.
>
> I think if you combine this with the fact that subtyping allows any
> type to represent a potentially-unbounded algebra and you have the
> explanation. This is why Scala needed to add the semi-magical
> "sealed" modifier. Subtyping is a major pain, but it's quite central
> to OO.
>
For my coding style, "sealed" is to Scala as "final" is to Java.
There are two general problems that the record-of-types solve. The
first is monkey patching: I have a data structure, and I have a
function that can *almost* be applied to the data structure, but
there's a bit of nudging that needs to be done to make it work. By
allowing a new structure to be defined with the necessary behavior, it
can fit into that spot. Also, I note that static typing of these
monkey patches solves the most common problems. The second is
organizing behavior with its data. Sometimes a noun + behavior is
really what you're looking for. This is useful anywhere you see
functional types that look like: ('a -> 'b -> 'c) -> ('c -> 'd) -> ('a
-> 'b-> 'c -> 'd) -> 'a -> 'a option (or whatever)
I really don't find covariance and contravariance to be that much of a
nightmare once you get out of the mutable data structure space and
nominal typing. We'll see if that changes as I develop further on
Ashlar.
Does anyone have a link to a good blog post on how anonymous classes
work on the JVM? I'm curious if I should be looking more at that
space.
~~ Robert.
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
