On 07/03/2009 07:02 PM, Andrei Pelinescu-Onciul wrote:
On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
On 07/03/2009 06:36 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
whose confusion?
like the discussion on lookup_domain function revealed, it is confusing
that the same prefix ($ char) is used for two different things.
from my point of view, all are script variables: avps, references to sip
message parts, etc ... therefore the have to start with same char, and
most of the programming languages use $ for that. It is what was decided
long time ago in openser when pseudo-variables were introduced in core.
From my point of view the only things that are
close to variables are
the avps
avps are not at all, if you put it this way. it is a linked list,
actually more like a stack, but via some options, elements that are not
in top, can be accessed.
and the script vars. All the others are in fact
hidden function
calls and should be syntactically different.
All are function calls as long as the value can be int or string.
Basically,
there are classes of script variables, some accepting dynamic
names (like avps $avp(...), headers $hdr(...), private $var(...) and
shared variables $sht(...) a.s.o.).
I do not see reason for a special character for certain classes, like
avp or select. It is much much clearer to have:
$avp(name)
$sel(name)
We should use $ only for variables (like any other script language out
there). This doesn't mean avps though. The avps should be accessed in
some other distinct way. avps are both slow and they consume memory, so
their use as script vars should be discouraged.
rather than:
$name for avps
@name for selects
&name, %name etc. for what so ever variable class
I would use '$' only for fast script vars (that should be declared at
the beginning of the script and would be typed), and some function like
construct for the other (e.g. $var=sel("from.uri")).
in shell you can have ${VAR:0:5}. Introducing of PV in openser core
started from %name used in xlog, but trying to follow shell var syntax.
Besides just nice to discuss, such changes makes no point now. Remember
the goal is to have a first version for each project that is easy to
migrate to from older ones. Therefore we committed to go for a best
compatibility approach. I hope we do not divert from here, otherwise
will be come a nightmare to get people on board with migration.
If someone has free time, no problem, he can start coding a new
framework that could obsolete PVs (and selects, a.s.o.) via better
design and functionality, keep both for a while, let other developers
update their code to the one that is more appealing and the users become
comfortable with syntax, etc...
PV framework impact to core is very minimalistic, I hoped same would
happen with selects, but not yet. Where two fit, it is place for the
third...
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/