[Devel] avpops updates
Daniel-Constantin Mierla
daniel at voice-system.ro
Sat Feb 11 14:27:03 CET 2006
On 02/11/06 00:09, Dan Pascu wrote:
> On Friday 10 February 2006 21:44, Daniel-Constantin Mierla wrote:
>
>> - $avp($aliasid) - refers to the avp defined by avp alias 'aliasid'
>> -$avp($pvar) refers to the avp having the name the value of $pvar
>>
>
> These 2 seem to conflict with each other. They look exactly the same but
> claim to yield different results. The first is a direct access of the
> value of the alias, while the second is an indirect access of the value
> of the avp which's name is taken from $pvar. This is _very_ confusing.
>
> The problem comes from the fact that avp aliases and pseudo variables use
> the same notation but are handled so differently by $avp().
>
> I think the best way to address this is to solve the issue at its source.
>
> What I have in mind is to use $something for pseudo variables like before
> but unify the avp and avp alias notation, since an avp alias is just
> another name for an existing avp. Thus we can have these:
>
> $avp(i:nnn) - integer avp
> $avp(s:some_name) - string avp with name 'some_name'
> $avp(some_name) - if some_name is defined as an avp alias, use the avp
> pointed by that alias, else lookup the string avp
> with the name 'some_name'
>
> In short, anything not having a i: or s: in front of it should be first
> looked up as an avp alias, but if that alias is not defined it should be
> considered as the name of the string avp.
>
> This will make avp aliases have priority over string aliases, but I think
> that's fine. And this is much more clear (both by eliminating the
> confusion with pseudo variables and by unifying aliases with avps
> notation wise). Backward compatibility is preserved, in the sense that if
> some_name is not defined as an alias it's still looked up as an string
> avp as it was before.
>
I would like to have a clear notation for avp aliases as well and your
solution seems good. I was considering the notation from existing
pseudo-variables. Maybe it would be better to force "i:number" and
"s:string" also for values, to avoid other confusions.
Is there any other opinion for this issue?
Cheers,
Daniel
More information about the Devel
mailing list