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

[Tuomas Lukka]

On Tue, Oct 29, 2002 at 11:28:48AM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >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.
> >
> 
> Ok. foo.getRootclone() is easier to understand than foo.h(d_clone), I'll 
> admit that ;-)

Excellent example.

> >>>>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.
> >
> 
> Ok, but what exactly should they look like? I could imagine
> 
> addContainedCell(Cell into, Cell c);
> 
> which would put 'c' at the end of 'into''s list of contained cells, but 
> of course this doesn't do *everything* we might want. OTOH it would be 
> enough for the case above...
> 
> It should IMHO not clone, but throw an exception if 'c' is already 
> connected in a containment structure.

Sounds reasonable.

> >Ouch. That sounds much too complicated and context-dependent. 
> >Making a clone *sometimes* but not always is bad :(
> >
> 
> I naturally *don't* agree at all ;-)
> 
> The very *point* of clones is that you can connect things on a dimension 
> they are already connected on. It's preferred to connect the original, 
> because it has most connections anyway, so only if you can't connect to 
> the original, you create a clone.
> 
> This is also AFAIK the philosophy in Ted's mechanism for joining remote 
> clones: unify them into a single cell if there are no conflicting 
> connections, make them clones if there are conflicting connections.
> 
> To me, this way of operation seems absolutely natural. Can you explain 
> why you think it's bad?

Ok, maybe it's more an issue of visualization; if our visualizations always 
showed
the clones of a cell in a reasonable way, it'd be not so confusing.

        Tuomas