]> On Tue, Oct 21, 2003 at 03:29:21PM +0100, Richard Jones wrote: > 1. 'return' from a function. eg: > > let foo x = > if x < 0 then return "OSL"; > (* long & complex code *) > return "some other string" let return x = x > 2. abstract data type syntactic sugar: > > let hash = Hashtbl.create 16 in > hash#add "foo" 10; or: hash->add "foo" 10; > hash#add "bar" 20; or: hash->add "bar" 20; > > The syntactic sugar is that if a module contains a type called > M.t (literally "type t"), and obj has type M.t, then: > > obj#call [ or: obj->call ] > > is exactly equivalent to: > > M.call obj As pointed out in another post, there are type issues with this. These new constructs have to be polymorphic in the same ways that objects are. If you want an object interface to something, it is probably best to just do it that way. > I think this change would help a lot of Java programmers (<gr>) who > would otherwise tend to jump immediately on using objects, which are > an area where OCaml is weaker. I'm curious what the argument for Ocaml objects being weaker is. For the most part, the OCaml object system is much more flexible, mostly because class inheritance and type inheritance are kept seperate. Are you complaining that coersion has to be explicit, and that you can't cast to a more specific type? I would suspect most instances of needing these casts in Java is due to Java's much weaker type system. There are some problems where an OO solution maps well to the problem. There are many other problems where trying to force it into an OO model only obscures the problem. Ocaml is nice in that it gives you a choice. The flexibility occasionally means that a particular model may not be as easy to use as in a language where that is the only model available. Dave ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners