Re: [Gzz] New PEG: containment--benja

[Tuomas Lukka]

On Mon, Oct 28, 2002 at 08:06:49PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >>Changes
> >>-------
> >>
> >>For now, let's handle containment through a
> >>``gzz.zzutil.Contaiment`` class with the following methods::
> >>
> >>  public static String getContainedText(Cell c) {
> >>  // ...
> >>  }
> >>
> >>  public static Enfilade1D getContainedEnfilade(Cell c) {
> >>  // ...
> >>  }
> >>
> >>These methods interpret the containment structure and return the
> >>respective representation of the content.
> >>   
> >>
> >
> >It might be good, for flexibility, to consider this a kind of
> >Index, and use IndexManager (or if you don't like that idea, create
> >another class like IndexManager where you can ask for these).
> >
> >If we just have one implementation of the interface, it's too easy
> >to break encapsulation. 
> >
> 
> In which way? I see these as convenience methods: the containment 
> mechanism specifies the structure, Containment just provides a 
> convenient interface for it.
>
> Of course it might be nice to be able to have different implementations 
> of the interface which represent containment in different ways, BUT this 
> is impossible without having edit methods in the interface too. The way 
> I proposed it above, Containment has only methods for reading, and 
> writing has to be done manually; this doesn't work if the structure 
> isn't well defined independent of the Space implementation.

I see this as an architectural issue. *Even* if we have only a single
implementation, it is useful to behave as the implementation might change,
because you get cleaner code that way.

If you have code that explicitly handles the containment dimension in 
a lot of places, it gets really hard to read (remember last winter's
codebase ;), but if we separate it, it's easier to see what's going on.

Am I making myself clear at all?

> >>Additionally, new ``p``/``P`` bindings as (IIRC) specified by Ted:
> >>``p`` puts the left window's cell at the end of the right window's
> >>list of contained cells; ``P`` does the reverse. (Actually, let's
> >>use the prefix mechanism explained in PEG 1022: other window if
> >>no cells are marked; the marked cells, if any; in the future,
> >>the cell identified by number, if any.)
> >>   
> >>
> >
> >This is too vague; is there a call in Containment that is used?
> 
> No, in the proposal Containment has only the two methods above.

I think that it should also have these. Better have them in one place
than all over, even if we're never going to change the structure.

> >What are its semantics? Effects on other cells?
> >
> 
> If 'cells' is the prefix argument (i.e., the marked cells in the order 
> they were marked, or a list containing only the other window's cell, if 
> no cells are marked), and 'cursor' is the current cursor position, I'd say,
> 
> def endOfContainList(cell):
> last = cell.s(d_contain)
> c = last.s(d_contain_list)
> while c and not c.s(d_contain, -1):
> last = c
> c = last.s(d_contain_list)
> 
> return last

> for cell in cells:
> if cell.s(d_contain, -1) or cell.s(d_contain_list, -1) or 
> cell.s(d_contain_list):
> cell = cell.zzclone()

Ouch. That sounds much too complicated and context-dependent. 
Making a clone *sometimes* but not always is bad :(

> if cursor.s(d_contain):
> endOfContainList(cursor).insert(d_contain_list, 1, cell)
> else:
> cursor.connect(d_contain, 1, cell)
> 
> Hm, I admit that this is a little more tricky than I first thought ;-)
> 
> The cloning is IMHO needed if the cell to be put is in a containment 
> structure already; we don't want to change that, so we need to clone. 
> The endOfContainList() is needed because according to Ted's semantics, 
> interpretation of a d..contain-list rank has to stop when a negwards 
> d.contain connection is encountered; so if we want to put a cell at the 
> end of this cell's containment list, we have to insert it before the 
> next negward d.contain connection-- using 
> cursor.s(d_contain).h(d_contain_list, 1) would have wrong semantics in 
> that case.

Ok...

this means that it would actually be really nice to *publish* a method
in Containment that does exactly what you say above. We really really
don't want everybody doing this in whatever module.

        Tuomas