Message3795
Proposal
~~~~~~~~
Here is my proposal; hopefully Ralf can live with it, too:
- the semicolon ";" (or 'to') is the range operator, like in
date1;date2
- ranges can have inclusive or exclusive limits:
[a; b] --> a <= x <= b
[a; b) --> a <= x < b
(a; b) --> a < x < b
(a; b] --> a < x <= b
(to continue support for existing date searches,
and important for floats)
- a simple, single range can be specified without brackets:
a; b
- ranges without brackets are by default /inclusive/ ("[a;b]")
except (for compatibility) for date ranges before the magic
lever is thrown
- the comma "," (or 'or') is the -- optional! -- set operator:
a, b --> x in (a, b,)
a or b --> x in (a, b,) (same as "x==a or x==b")
a b --> x in (a, b,)
- when sets and ranges are combined, ranges *must* be put in braces.
* Preferred syntax:
{a, b} or [c; d] --> x in (a, b) or c <= x <= d
* Accepted syntax (examples):
a or b or [c;d]
a, b, [c;d]
{a b} [c;d] # (not for dates)
a b [c;d] # (not for dates)
or, queer but possible:
{a} {b} [c;d]
* search support for dates, integers, ids and floats works
as similar as possible:
- when it comes to search expressions,
ids are treated exactly like integers
- for dates, separation of alternatives by blanks can't be
supported; but for all data types -- which /can't/ contain
blanks -- it is.
- comparison of floats for equality is /unreliable/ by nature;
thus, sets and /inclusive/ ranges are disallowed for float fields.
After a short while, floats might be the only case where
/exclusive/ ranges are actually used:
(0;) --> 0 < x
(Ralf's initial need, probably concerning floats)
* for convenience, float values can be specified using decimal commas
as well as decimal points:
(0.0;) --> 0.0 < x
(0,0;) --> 0.0 < x
(0.;) --> 0.0 < x # just to please geeks
(0,;) --> 0.0 < x # (perhaps; not recommended)
0,0 --> ERROR: sets or single values not supported
Philosophy (the "Zen of Searching" ;-):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Support what works already.
- But don't stick with unappropriate defaults.
- As far as possible, do similar things similarly.
- But when necessary, threat different things differently.
- Predictibility is more important than simplicity.
- Better raise an error than perform an unintended search.
- Explicit is better than implicit. |
|
Date |
User |
Action |
Args |
2009-07-15 10:22:15 | tobias-herp | set | messageid: <1247653335.39.0.737242921931.issue1182919@psf.upfronthosting.co.za> |
2009-07-15 10:22:15 | tobias-herp | set | recipients:
+ tobias-herp, richard, schlatterbeck, ber, ajaksu2 |
2009-07-15 10:22:15 | tobias-herp | link | issue1182919 messages |
2009-07-15 10:22:15 | tobias-herp | create | |
|