Re: question

> It seemms that getTypeName is called twice for one
> variable. Even if it has no dot.
> It might be usefull to know this.
Yes, it was more convenient to write the parser this way (first call to 
check if the variable exists, second to actually generate the code to 
retrieve the specified type). The getTypeName call is assumed to be cheap.

But even if this double call is removed (e.g. by reusing the result of the 
first call), still there will be a necessity to remove the duplicates (or 
simply store the accumulated names in a Set) because a variable may appear 
in an expression several times.

That is, irrespectively of whether the parser is restructured to save a 
getTypeName call, using this interface to collect the names will still 
involve accumulating names in a set (not list).

With the best regards,
                           Konstantin.


>
> --- "Konstantin L. Metlov" <[email protected]> wrote:
>> Dear Damien,
>>
>>> Is there a way to get the list of variables
>>> referenced/used in an expression?
>>>
>>> Using the resolver it could be possible:
>>> - create an empty list before compiling
>>> - compiling
>>>  - in getTypeName calls, add the var to the list
>>>
>>> Is it right? Is there a better way?
>> Yes, this is the right way. I'm not sure if there
>> can be anything really
>> better for this task. The method "getTypeName(String
>> name)" of the
>> resolver is called for each of recognized
>> identifiers as soon as they are
>> recognized by the parser. It is really the best
>> place to collect variable
>> names.
>>
>> One thing to note is that if the variable name
>> contains dots (e.g. looks
>> like "name1.name2.name3") the getTypeName() will be
>> called three times
>> (with arguments "name1", "name1.name2" and
>> "name1.name2.name3"), which
>> reflects the hierarchical (tree-like) structure of
>> DV namespace. In this
>> case, the longest sequence for which getTypeName()
>> still returns a
>> non-null value is considered to be the DV name, but
>> the variables on the
>> preceding level of the hierarchy (e.g. "name1" and
>> "name1.name2" in the
>> above example) must also be defined (e.g.
>> (getTypeName("name1") != null)
>> and (getTypeName("name1.name2")!=null)).
>>
>> With the best regards,
>>                            Konstantin.
>>
>
>
>
> __________________________________
> Yahoo! Mail Mobile
> Take Yahoo! Mail with you! Check email on your mobile phone.
> http://mobile.yahoo.com/learn/mail
>
>
> _______________________________________________
> Help-jel mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/help-jel
>