I agree.
As to Raju's usage, that's an inefficient mechanism for getting around a known
deficiency in LZX. We have (somewhere than I can't find) a proposal that LZX
should use a lexical rather than a dynamic model for variable lookup. That is,
it would be nice if you could write:
<class ...
<view name="bar" ...
<view ...
<view ...
<method ...
bar.doSomething();
and have the inner `bar` resolve to the lexically apparent `bar` binding,
rather than having to say `parent.parent.parent.bar`. I think many people
would be happy if this worked. With Don's work on LPP-8751, we should be able
to tell at compile time when a reference is not an instance reference, and look
for a lexical binding that matches before defaulting to a dynamic lookup.
On 2011-03-07, at 08:21, André Bargull wrote:
> Actually it was already marked private in r7878 by Don as part of the
> harmonisation of the 3.x and 4.0 docs. Don made it private in <node>, because
> searchParents() wasn't referenced as a public method for <node> in the 3.x
> docs, instead it was erroneously documented on the <view> reference page. So
> you could say it was solely an accident that the method got private.
> Although it was an accident, I'd still say we should not make it public
> again, because searchParents() doesn't perform what it sounds like: I'd
> expect it walks up the parent-chain to find a matching attribute, but instead
> it uses the immediateparent-chain.
>
>> Not clear. Looks like I marked it private in r9179 as general doc cleanup.
>> Probably I was being over-zealous.
>>
>> Can you give an example of how you used this? Internally, this is used
>> mostly to inherit attribute values. The modern way to do that is to use CSS:
>>
>> <attribute name="foo" style="foo" inherit="true" />
>>
>> Will cause a node to inherit the CSS foo value from it's parent if it does
>> not have one of its own. Are there other applications? If not, I am in
>> favor of leaving this interface private.
>>
>> On 2011-03-06, at 07:36, Raju Bitter wrote:
>>
>>> > The LzNode#searchParents() method doesn't show up in the
>>> > documentation, it's private now. What was the reason to make that
>>> > method private? I used it a lot in my apps.
