From: Duncan C. <dun...@wo...> - 2006-03-30 16:25:57
|
On Thu, 2006-03-30 at 16:01 +0100, Axel Simon wrote: > On Thu, 2006-03-30 at 15:46 +0100, Duncan Coutts wrote: > > > > This is not type safe. Under the typed model + untyped view system > > we > > > > can't extract a model from a view. > > > > > > Ok, I probably meant UntypedTreeModelClass then?! There might be > > similar > > > issues in the other widgets. > > > > Maybe you did. Hmm, not sure. I don't think there's much useful you > > can do with an untyped tree model however. One can poke about in an > > untyped model but one can't attach it to a new view or get any data out of it. > > Well, I added this case back in when I realised that you'd have to put > it back in when you added the typed view. For symmetry we might want to > have this function. I'm not quite sure what you mean. Yes it'd be possible to have it for a typed view. You're saying we should have another version for an untyped view that returns an untyped model? I thought we agreed that having both was worse since the main problem was the complexity of the API. I'm probably just misunderstanding. > > It'd be simpler to just prevent people from getting the model out of a > > view. That's what you did in one of the other views. > > > > Of course, with a typed view.... > > > > :-) > > Yeah, yeah... > > If you'd change that to a version of a typed view and a typed model, > then the user can't extract an untyped model from a typed view You can get an untyped model from a typed model. In fact a typed model is already an untyped model. Everything that's an instance of TypedTreeModel should also be an instance of TreeModel. It's just that one can't go the other way. > (except if we'd use dependant Epigram types...). Hence, the GetModel functions > should probably go in their untyped variant. > OTOH, we can have SetModel functions that take an untyped view and an > untyped model and the function would work for a typed view and typed > model, too. So do we really need a different API as you said back in > Nottingham? > > This stuff is kinda confusing. Yeah. I'm getting confused. :-) > I actually started to write the tutorial, so I should really put > something in there about this issue (even if it is just for us/me). Ok, my sort-of equivalent plan was to actually implement a typed view system. I'll try and prepare a minimal patch to do that and see how much that uglifies the API and what it really does to end users programs. I originally thought that I could change the model on a view to one of a different type by doing something like having a function: changeModel :: View a -> IO (View b) where we'd unset the renderers and anything else like that. However even this is unsafe because the user can still use the old view at the old type. So the actual situation would be: untyped view proposal: * can't change model without unsetting and setting up all the cell renderers again * can change the model to one of another type typed view proposal: * can change the model to one of the same type without doing anything to the cell renderers * can't change the model to one of another type (without creating a new view) both!: * can do all sorts of things * incomprehensible API Ho hum. No perfect solution. Duncan |