Re: [Gzz] PEG vobcoorder_culling--humppake

[Asko Soukka]

Mon, 11 Nov 2002, Tuomas Lukka kirjoitti:
> > Into ``gzz.vob.VobCoorder`` add::
> >     /** Creates a CullingCoordSys with distinct parent and test
> >      * coordinate systems. The CullingCoordSys works mainly as its
> >      * parent CoordSys.
> This needs to be made more exact: does it duplicate the box? (it probably
> should). In what ways does it NOT work like its parent

What do you mean by duplicating the box? And how that's relevant in PEG?
Currently the box is readed from coordsys using getSqSize()
(in the beginning of method, which needs the box) into temporary
Pt variable. Do you mean that boxes of coordinate systems should be
duplicated into CullingCoordSys' own attributes when constructing it?

The only difference in how CullingCoordSys and it's parent coordsys works
is the shouldBeDrawn-method. Ok, this should be told more exact:

"Exluding the shouldBeDrawn test, CullingCoordSys works like its parent
coordinate system"?

>       This coordsys will not necessarily be drawn if the boxes of the test
>       and clip coordinate systems do not intersect. However, this is not
>       guaranteed; the only thing guaranteed is that if the boxes of the test
>       and clip coordinate systems *do* intersect, the CullingCoordsys will
>       be drawn.

Sounds more exact :)

>
> > * @param parent ID of the coordinate system which points which > *
> points will be transformed, if CullingCoordSys is > * shown
> "which points which points"?

Oh, that's (repeating words) common for me :/

> >     /** Creates a CullingCoordSys using the parent also as the test
> >      * coordinate system. In practise, this could be only a shorthand,
> In practice...  need not be mentioned; that's an implementation detail.
...
> You can also put into the PEG the trivial default implementation (it should
> be in VobCoorder, methinks)

Ok. I don't mention about the implemention, although I put the
default implemention into the PEG :)

> > After changing ``gzz.vob.VobCoorder`` these methods should also
> > be implemented in all implementing classes, which inherit
> > ``gzz.vob.VobCoorder``. Because culling is already implemented in
...
> These are all implementation details and do not really belong in this PEG.

Well, that keep PEGs clean. But still, if anyone else than PEG's writer
will implement the PEG, there could be need for also some impemention
details...

> HMMM... maybe we should have four separate PEG tracks:
>       META
>       ARCHITECTURE
>       INTERFACES
>       IMPLEMENTATION
> with separate tables on the pegboard?

IMHO separate tables make the pegboard less comfortable to read (as
after that there might be PEGs with same status all over the board.
Since the implementation PEGS are always assosiated into some earlier
PEGs, maybe they can somehow merged with those in the current PEG table?

Eg. a file "impl.rst" in PEG's directory. The status of that file can
be shown as background color of the filename in PEG's file list.

-- 
Asko Soukka     | Taitoniekantie 9 A 603 | address@hidden
+358-40-8235947 | FIN-40740 JYVÄSKYLÄ    | http://www.iki.fi/asko.soukka/