Browse thread
Problem correlating input and output type
-
Goswin von Brederlow
-
Tiphaine Turpin
-
Goswin von Brederlow
- Tiphaine Turpin
-
Goswin von Brederlow
-
Tiphaine Turpin
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Tiphaine Turpin <Tiphaine.Turpin@i...> |
| Subject: | Re: [Caml-list] Problem correlating input and output type |
Goswin von Brederlow a écrit : > Tiphaine Turpin <Tiphaine.Turpin@irisa.fr> writes: > > >> Goswin von Brederlow a écrit : >> >>> [...] >>> >>> Can anyone think of a way to express this so that the type system keeps >>> track of which callbacks are already connected? >>> >> Runtime checking would be much easier (but still a bit hackish). >> > > But runtime checks will only show the error when the GUI object is > instantiated. Some obscure dialog might not pop up in month. [...] > But how do you translate that into ocaml objects? > > I see two requirements in your problem that are difficult to combine: - static checking by an "ordinary" type system - dynamic connection of objects. First, I believe that it prevents anything imperative (because such typing ignores the execution flow). A functional approach may succeed in some sense, but I don't think that it would be practical. As for the combination with objects, In my (humble) experience with objects in Ocaml, I found that typing even reasonably simple designs is not a trivial task. So, combining that with the earlier hack would quickly become a nightmare. My personal opinion would be to drop the second condition, and make the connection of your objects static. I would try to define the objects as functors, with one module parameter per connection, and connect all that using (possibly recursive) module definitions. I'm curious to know what solutions object-oriented people could propose, in particular with dependency injection. Tiphaine