[Aptitude-devel] Experimental package and package_pool implementation

[Piotr Galiszewski]

2010/7/14 Daniel Burrows <dburrows at google.com>:
> On Wed, Jul 14, 2010 at 8:50 AM, Piotr Galiszewski <piotr at galiszewski.pl> wrote:
>> 2010/7/14 Daniel Burrows <dburrows at google.com>:
>>> On Tue, Jul 13, 2010 at 4:46 PM, Piotr Galiszewski <piotr at galiszewski.pl> wrote:
>>>> Both methods are used directly by packages_model. They are the heart
>>>> of package_pool from other Qt classes perspective ;)
>>>
>>>  Huh, could you expand on that?  I was assuming that this was just a
>>> global cache of all the packages that anything used, but it sounds like it's
>>> doing more than that.  Are you storing these integers as indices into the
>>> package list, then?  Why not just store direct pointers to the packages?
>
>  (snip)
>
>> Indexes are not stored. Packages count is used to determine how much
>> rows should be added to view, packages_at_index is used to get
>> information about package that should be shown in given row. It is
>> simple and typical for model in Qt Model Architecture
>
>  Ah, ok, here's my point of confusion: I thought package_pool was supposed
> to contain all the packages in the entire program, acting basically as a
> cache/flyweight holder to ensure we only have one package object per apt
> package.  But actually, from what you said and from the patch you posted,
> it contains just the packages in a single view.
>
>  Is that right?  How does that reconcile with package_pool being a singleton?
>

It is one of the tasks this class will have. Other classes (such as
each package_info_tab, maybe another models, or status_widget,
resolver etc.) will use signals about changing cache state. This
classes will probably use package_ptr objects, so cache's signals have
to be translated somewhere to package objects.

I think now, if it is good place to add other methods e.g.
update_cache or clean_cache. But it is not worth to do this here.
>  Daniel
>

-- 
Regards
Piotr Galiszewski