[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] New PEG: containment--benja
From: |
Tuomas Lukka |
Subject: |
Re: [Gzz] New PEG: containment--benja |
Date: |
Tue, 29 Oct 2002 08:45:10 +0200 |
User-agent: |
Mutt/1.4i |
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
- [Gzz] New PEG: containment--benja, Benja Fallenstein, 2002/10/28
- Re: [Gzz] New PEG: containment--benja, Tuomas Lukka, 2002/10/28
- Re: [Gzz] New PEG: containment--benja, Benja Fallenstein, 2002/10/28
- Re: [Gzz] New PEG: containment--benja,
Tuomas Lukka <=
- Re: [Gzz] New PEG: containment--benja, Benja Fallenstein, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Tuomas Lukka, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Benja Fallenstein, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Tuomas Lukka, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Benja Fallenstein, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Tuomas Lukka, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Benja Fallenstein, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Tuomas Lukka, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Benja Fallenstein, 2002/10/29
- Re: [Gzz] New PEG: containment--benja, Tuomas Lukka, 2002/10/29