On Monday 23 June 2008, Daniel-Constantin Mierla wrote:
> Hello Dan,
>
> On 06/19/08 16:02, Dan Pascu wrote:
> > [...]
> > Should I remind you that
> > even after about 3 incarnations, the pseudovariable system still has
> > issues dealing with NULL values correctly (by design) and that
> > certain operators do not work in all cases?
>
Daniel,
the purpose of my message was to highlight that no functionality in
openser was ever pushed in its final, complete form. Everything started
with something smaller and later evolved into something more complex.
If this new functionality doesn't break backward compatibility by
interfering and altering the current way things are processed by openser,
I see no reason to remove it just to wait for a more complete version to
appear. As far as I see, nothing old is broken, and those who'll start to
use it, will face the same problems as they did when they tried any new
feature that was just added to openser: they will discover some things
that don't work as expected and will file bug reports to get them fixed.
So my message was not intended to start a new thread discussion PV issues.
> can you summarize the operators and the issues? The redesign for PVs
> were to allow indexes and names, then dynamic indexes and names, there
> was no redesign of the functionality, just that the functions behind
> were moved from xlog to core and renamed.
I will, but we should pick this up after the release, because it's more
than a bug fix process.
>
> The NULL behaves differently for specific classes of PV, some delete
> and some reset. I do not recall right now if it is an item opened on
> the tracker, but if not, let;s open one and gather all these there.
The problem was raised by both Juha and me and in the end you discarded it
because it was not possible to fix it with the existing design.
>
> AVPs and VARs do not have null values, also $r[uUd] - null gets a
> different meaning, like delete or reset. I don't see how to make it
> behave same for all PV, unless we remove the null, and stick to
> functions like delete or reset.
I do not recall all the details, but I can try to highlight what I
remember, at least about the issues with null.
- null is not a real value, so it doesn't behave like one most of the
time. if you try to write a simple test like if ($avp(s:xyz)) will not be
false if $avp(s:xyz) is not set, i.e. is null, so one has to write it
like if (!is_avp_set("$avp(s:xyz)") || $avp(s:xyz)) which is unnatural.
- $var(x) however doesn't have this issue, as an unassigned var is the
same as the integer 0, unlike an unassigned avp which is null. so
sometimes when you copy an avp to a var, or when you compare an avp and a
var, if the avp is not set you get an error mesage, so again you have to
check before you do the operation, which increases the number of checks
too much in the script and forces one to write heavy code.
IMO, an unset avp, an empty string or the integer 0 should all act as a
false value to simplify how the script is written and to make it more
consistent.
As I said, I do not want to enter into a discussion right now how to do
this, let's leave it for after the release, when I'll try to remember all
the issues I had with it and we can see how it can be fixed.
--
Dan
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
