On Fri, Jul 29, 2011 at 9:27 AM, Robert Fischer <smokejumpe...@gmail.com> wrote:
>
> 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.
Autogeneration of decorators, basically.
> 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)
In this sense, objects are an abstraction layer of a type with haskell
type classes and ML functors, both of which serve to bind types with
operations on said types. Which is why I brought them up in the
original post. A couple of side notes: a) this highlights, to me, the
silliness of the name "object oriented programming"- it's as silly as
"functor oriented programming" or "type class oriented programming".
b) I note that both type classes and functors don't have downcasting,
and avoid the whole co-/contra-variance issue because you can't put
them in a container.
>
> 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.
I find this sentiment- expressed now twice in this discussion- more
than a little bit surprising. I mean, even in Ocaml, whose user base
includes a huge percentage of type theorists, the general method for
handling co-/contra-variance issues is to just avoid them like the
plague. Even the people who understand the subtleties of the issue
(and I don't count amount that number) tend to avoid it. The
introduction of co-/contra-variance issues into Java with generics
caused a huge amount of sturm und drang in the Java community- the
resolution of which, as near as I can tell, was for the vast bulk of
Java developers to simply ignore the issues, and revert to subverting
the type system and using run-time checking instead (i.e. explicit
casting).
And being immutable doesn't save you. Map.insert or List.cons both
"insert an element into a container"- what is the type of the
container (passed in and returned)? You can try this out for yourself
if you like- Ocaml has both purely functional objects and polymorphic
variants, both of which are immutable and both of which are
subtype-able.
Brian
--
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.
