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

[Benja Fallenstein]

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.

> > 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.

> 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()

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.

- Benja

- Benja