Feature Proposal:


See QuerySearch

Using / as the REF operator in queries was a monumentally bad choice. I made the choice, but defend myslef by pointing out that no-one picked up on it.

Without making any assumptions about alternative meanings for the / operator, we should deprecate /-as-ref now.

There has been other discussion and frequent reference to @ being an appropriate alternative. I'm not aware of any other semantic for this operator (outside of the perl world) so it is a good choice.

Description and Documentation

Deprecate (discourage but do not remove) the /-as-ref operator and add the @-as-ref operator.


  • "'Sandbox.BadChoice'/slash" -> "'Sandbox.BadChoice'@slash"
  • "FieldName/OtherFieldName.value" -> "FieldName@OtherFieldName.value"


There is an impact on existing sites that use the / operator, insofar as any topic using that operator has to change to using @ before the deprecation takes effect (i.e. in 1 or 2 years, or whenever we feel it is safe).

The code need to warn whenever the deprecated operator is used.


Attached patch.diff

-- Contributors: CrawfordCurrie - 02 Dec 2010


(09:18:00) MTempest: CDot: Is there any particular reason for choosing @ for ref instead of something like -> ?
(09:19:08) ***MTempest isn't trolling, and wasn't trying to be controversial in the the discussion of the divide-symbol, either
(09:20:00) MichaelDaum: -> is cool
(09:20:22) CDot: MTempest: @ is used in DBCacheContrib IIRC
(09:20:30) MichaelDaum: however I'd prefer to resever -> it for method calls
(09:21:07) CDot: it also has quite a nice feel to it "value AT topic" - albeit in reverse infix notation
(09:21:46) CDot: @ is also advantageous because it's not used in TML
(09:22:11) MTempest: Thanks - that all makes sense (prior use to mean the same thing, method calls, feel, not-in-TML)

I have no problem adding @ as such.

Though we need to ensure that it does not prevent having values that are email addressed in query search expressions.

We have email field in userforms and it is actually quite heavily used. I would hate if the parser suddenly gets into trouble.

However the deprecation / is what created all the trouble in AddOperatorsToQueries.

No need to repeat the same debate here. It is the deprecation of the / as ref that is THE debate in AddOperatorsToQueries so it applies here as well.

Are you pulling this proposal now that you gave up on deprecation yourself in AddOperatorsToQueries?

The solution of handling the deprecation by showing errors message only creates an even bigger problem for the admins and users. No thank you!!

-- KennethLavrsen - 03 Dec 2010

Let's please keep discussions in one place at AddOperatorsToQueries. See my comments on deprecation there.

-- MichaelDaum - 03 Dec 2010

No, I am not pulling this proposal. Irrespective of the outcome of the other discussions, I think we need to change the ref operator.

Why would the parser get in trouble with @? To the best of my knowledge @ is not a legal character in field names.

-- CrawfordCurrie - 03 Dec 2010

I think Kenneth thought there would be no need to deprecate /-as-ref operator if another operator does the division, right?

Let's do not make this a religious war, its Christmas soon! wink

-- FranzJosefGigler - 03 Dec 2010

Crawford, you get me wrong.

While I am supporting this proposal, the discussion about it and any alternatives has already been started and is further covered on AddOperatorsToQueries. That's why I said: let's please keep the discussion in one place.

Repeating the same arguments twice doesn't make sense.

-- MichaelDaum - 03 Dec 2010

Eh? I wasn't replying to you, I was replying to Kenneth.

-- CrawfordCurrie - 03 Dec 2010

Michael understood correctly that I did not want to repeat the sane debate here

Franz understood correctly what I meant. Crawford you argued on AddOperatorsToQueries that deprecating / for reference would harm the users too much. So the conclusion must be that this proposal is withdrawn. Now you say you will keep it.

I do not understand the logic in this. The issue with deprecating / is the trouble it gives eventually removing the code that makes it work as reference

If what you suggest is to ADD the @ as additional way to write the reference and deprecate the / by changing the documentation but keeping the code so it will always work then I think it is religious and pointless but I can live with it.

If you want to remove the / as reference in the code then the arguments are the same as in AddOperatorsToQueries and I have nothing further to add

-- KennethLavrsen - 03 Dec 2010

The description of this feature request says Deprecate (discourage but do not remove) the /-as-ref operator and add the @-as-ref operator is, as Kenneth says, a tad religious - and personally, I think wasting two special characters on ref, just because you wish you'd used another (so you could re-use the first...) is worse than just accepting / means ref.

At this point, I would keep @ as an unused reserved character - available for when we really need it - for eg, for the QueryRev proposal - please don't waste ....

-- SvenDowideit - 03 Dec 2010

In the light of other discussions, and other work, i agree.


-- CrawfordCurrie - 04 Dec 2010
Topic revision: r10 - 04 Dec 2010, CrawfordCurrie
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy