Search Policy

When trying to fool TreeModel to add an object more than once I came
across this one:
SearchPolicy>>newLookupTable
^ self mapClass new

With the exception of PluggableSearchPolicy and IdentitySearchPolicy,
it always return LookupTable.
Now, LookupTable use a search policy (although it is not reified)
equivalent to EqualitySearchPolicy.
However, if I do   NeverSearchPolicy newLookupTable   I would expect
having a PluggableLookupTable with NeverSearchPolicy as its policy,
and not a LookupTable.
I wonder if is not more sensitive:
SearchPolicy>>newLookupTable
^ PluggableLookupTable searchPolicy: self

And push down to EqualitySearchPolicy
EqualitySearchPolicy>>newLookupTable
^ self mapClass new

Best regards,
Rozzeta

PS:  I did a nasty hack to insert an instance more than once in a
TreeModel.  If anyone knows a polite way of doing it please speak up

Daniel Rozzeta wrote:

> When trying to fool TreeModel to add an object more than once I came
> across this one: [...]

Looks like a bug to me.  Something for OA.


> PS:  I did a nasty hack to insert an instance more than once in a
> TreeModel.  If anyone knows a polite way of doing it please speak up

The tree stuff isn't designed to allow an object to appear more than once (e.g.
what is its parent if it's a child of two nodes).  I don't think you'll have a
lot of luck trying to force it to work that way.

What I do is have nodes that act as proxies for the "real" data (it generally
only takes a handful of lines of code).  Depending on my mood, and the nature
of the application, I might do any of:
    - use only proxies in the tree.
    - use only "real" nodes in the tree (hence no duplicates).
    - use a mixture of real nodes and proxies.
But I use the last option less than the others.

    -- chris

Chris Uppal wrote:

> The tree stuff isn't designed to allow an object to appear more than once
> (e.g. what is its parent if it's a child of two nodes).
> I don't think you'll have a lot of luck trying to force it to work that way.

I believe you are absolutely right for the general case.
In my particular one I only need a static, read-only DAG.  As an
example, imagine that in the category panel on the class brower you
can open further down leaf categories to see its methods "on the tree"
(as opposed to in another panel).  So because methods could belong to
more than one category, they could be more than once on the three.
What I did was to change the search policy to NeverSearchPolicy when
adding nodes, and then back to normal.  From then on, I don't use
parentOf: or anything else than navigating.
It works, though I obviously don't like it.


> What I do is have nodes that act as proxies for the "real" data (it generally
> only takes a handful of lines of code).  Depending on my mood, and the nature
> of the application, I might do any of:
>     - use only proxies in the tree.
>     - use only "real" nodes in the tree (hence no duplicates).
>     - use a mixture of real nodes and proxies.
> But I use the last option less than the others.

If I understand correctly, in the proxies case, I suppose you use an
IdentitySearchPolicy, for using an EqualitySearchPolicy is like not
using proxies (unless you redefine #= in some clever way).
Now, how do you avoid falling down to the parentOf: problem again?


In any case, I still believe what I mentioned in my previuos post is a
bug.
Dear OAs, would you prefer me to send a .st with my change proposal?

Thanks Chris

Regards,
Daniel

Daniel

>
> In any case, I still believe [that the answer to #newLookupTable from
instances of NeverSearchPolicy, AlwaysSearchPolicy, etc, is always a
LookupTable rather than a PluggableLookupTable with the correct search
policy] is a bug.

I suppose it is (#1520), although frankly I'm not sure how useful a
PluggableLookupTable on a NeverSearchPolicy or AlwaysSearchPolicy will be,
since these search policies infringes the invariants expected of the hashing
and comparison behaviour expected by LookupTable.

> Dear OAs, would you prefer me to send a .st with my change proposal?

Thanks for the offer, but it would not help much. I'm beginning to sound
like a scratched record, but the real effort in most patches is writing the
tests. In a case like this the basic change is trivial, and I think I'd want
to do a little bit of refactoring along the way.

Regars

Blair

Blair

[snip]

> I'm beginning to sound like a scratched record,
> but the real effort in most patches is
> writing the tests.

I suspect that most of the "youths" here can't remember what a record
(LP) looks like, let alone know what it sounds like when scratched.
Trouble is that a scratched CD (the contemporary equivalent) has the
opposite effect of missing out key bits rather than repeating them
ad-nauseum.

Best regards
 
Andy Bower
Dolphin Support
www.object-arts.com

Daniel Rozzeta wrote:

> From then on, I don't use
> parentOf: or anything else than navigating.
> It works, though I obviously don't like it.

I don't blame you ;-)


> If I understand correctly, in the proxies case, I suppose you use an
> IdentitySearchPolicy, for using an EqualitySearchPolicy is like not
> using proxies (unless you redefine #= in some clever way).
> Now, how do you avoid falling down to the parentOf: problem again?

Yes, I use an IdentitySearchPolicy (which is usually the default, iirc).

I handle the #parentOf: in one of two ways.

One is to hold an explicit parent link in each proxy, so that (following your
example) one proxy for the CompiledMethod, Object>>at:, would "know" that its
parent was the MethodCategory called 'accessing', the other proxy for the same
method would know that its parent was the 'public' category.

The other way is to use a TreeModel that remembers what the parent of
each node is.  IIRC ExpandingTreeModel is one such that is provided in the base
image (I often define my own tree models -- 14 to date, although that does
include some duplication).

    -- chris