[Lazarus] Java's Document & Elements model

[Marco van de Voort]

On Thu, Jun 26, 2008 at 08:01:20AM +0200, Graeme Geldenhuys wrote:
> only have a single instance in memory.  This could be very handy for
> SynEdit if it supports multiple views into the same document (eg:
> Editor window is split in two and each part is viewing different
> sections of the same text document. Edit one and the other is
> automatically in sync.).

Maybe you should try to create a synedit that implements the document
interface? I'm sure it works for trivial components, but only if you try it
will real components you know if it makes sense.

There are some downsides to this approach I can imagine (though some
apply less to owner draw widgets sets as afaik Swing i):

- You have one datastructure for all widgets, and are stuck with it by
  design.  No ability to have your own design of datastructure if needed
  (e.g. the gap buffer you mentioned yourself)
- You can't use widgetsets datastores. (admitted, those are rare) This
  partially also is like the first one, if the interface of the
  datastructure of the widgetset and the document model don't match in
  philosophy you'll
  have to twist yourself to get it done.
- You have to call a lot of methods/handlers that won't be overriden that
  often, just in case. Performance bottleneck.
- Java String is OOP, but a Pascal string is not. The fully OOP paradigm
  thus might not translate as well. (otoh, the java string might be mostly
  final, and then it is not that much of a problem. Java has been too long
  ago for me to reproduce that from memory)
- You have to rework all existing source to match your new interface.
- Lazarus doesn't allow reworking the datastructures in the first place
  because of Delphi compat.  
- If Lazarus is to be built on top of fpgui, and  fpgui has/requires its own
datastructures that might create a double datastructure problem. Most
widgetsets only require callbacks that govern what is in the current view,
not the whole data.

All of this is stuff you usually only find out in practice. Hence the remark
to try it out with a few non trivial components before you decide to force
it on (fpgui) programmers globally. In general I think this is more
something for a 2.0 or even 3.0 release, when the consequence are more
clear, and there has been lots of experimenting.