Re: [Gzz] PEG vobcoorder_culling--humppake

[Tuomas Lukka]

On Tue, Nov 12, 2002 at 08:36:06AM +0200, Asko Soukka wrote:
> 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? 

I mean that if you do getSqSize on the coordsys returned by cull(), 
it should return the same as it did for parent.

> And how that's relevant in PEG?

Well, it's a part of the definition of cull().

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

No, absolutely not.

> 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"?

As the box?

> > >   /** 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 :)

The implementation, if it's trivial, and part of the frozen classes, should
be in the PEG.

Non-trivial implementation outside the frozen classes should not.

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

Well, for some things, yes. Here, OTOH, the system will not compile
after putting in the methods 8)

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

Yes, but OTOH these really *are* different issues. Of course, pegboard.py
could generate differently sorted versions?

> Since the implementation PEGS are always assosiated into some earlier
> PEGs, maybe they can somehow merged with those in the current PEG table?

That's not necessarily so: e.g.

        "PEG: speed up AWT vobscenes by factor of 2 by doing XXX"

An implementation PEG for cull() should not be necessary, it would be more
for things that

        1) make things more complicated but achieve something by it
        2) change an undefined behaviour ("is it ok if we make this do that") 
        ...

        Tuomas