from initial design: +braindump, +questions

 

Design for multiple values

 

Short property syntax

The translation from single to multiple of our current simple syntax is clear:

PROPERTY => VALUE  (implies operator is :eq)

would look like this in the new system:

PROPERTY =>['in', VALUE1, VALUE2, ...]

eg. :name => [:in, 'Lewis', 'John', 'Bryan']

eg. :type => [:in, 'User', 'Company']

Note there's no need for an "and" operator here, because no property can be equal to more than one value.  For example it wouldn't make sense to say "give me all the cards that have the type User and the type Company".

 

(this much has been implemented)

 

---

 

OPERATOR => VALUE  (implies property is :content)

would look like this:

OPERATOR => [:in, VALUE1, VALUE2, ...]

eg. :eq => [:in, 'open', 'in progress', 'coded']

in this case, there could be conceptual need for multiple operators and hence an "and" operator.  Eg.  > 5 and < 8.  We don't have use cases here yet.  Not sure what the best syntax would be to go with :in.  Perhaps :all?  :is?

 

 

Full property syntax

 

The longer property syntax is a bit more involved.  We're thinking this:

PROPERTY => [OPERATOR, VALUE]

would look like this

PROPERTY => [in/all, [OPERATOR1, VALUE1], [OPERATOR2, VALUE2], ... ]

eg.  :content => [:all, [:match=>'Lewis], [:ne=>'Jerry Lewis']]

 

Relationship syntax

 

As of yet, there have not been a lot of use cases for relationships using multiple card definitions, since the definitions already support and's and or's themselves.  For example, the following would be the obvious syntax:

 

RELATIONSHIP => CARD_DEF

 

RELATIONSHIP => [in/all, CARD_DEF1, CARD_DEF2, ...]

eg. :refer_to => [:in, 'Lewis', {:type=>'Company'}]

 

but you can already accomplish that example at least by doing this:

:refer_to=>{:or=>['Lewis', {:type=>'Company'}]}

 

 

Plus Cards

So the plus cards are different, because arrays already have special significance:

:plus => [A,B]

and because since plus cards are the basis of our representational system, we definitely need to be able to handle multiple plusses.  (For example, open tickets with high priority). so, we figure if there are more than two elements in the array, it necessarily means that the first one is an operator:

:plus => [ :in, [A,B], [A1,B1] ]

In that case,  each element after the operator is treated like a normal plus arg, which may be an array or shortcut.
So you could say, for example:

:plus => [ :all, "dog", "cat"]

which is all cards connected both to dog and to cat.  It's equivalent to:

:plus => [:all, ["dog", {}], ["cat", {}] ]

 

---

IF we solved the multiple key problem, we could express and and or with the existing pieces:
{ :content=>[:match, "Ethan"], :content=>[:match,"Scrabble"] }        --parts of cards defs are joined with 'AND' by default
{ :or=>{ :content=>[:match,"Ethan"], :content=>[:match,"Scrabble"]}

 

 

it would be easy to provide
{ :and=>{ ... }} for symmetry, which would essentially be a no-op

  --Lewis Hoffman.....Wed Feb 20 09:52:38 PST 2008

---

---

note that for the current :or to work, we have to handle multiple key problem internally, which we do by having things like { id:1=>(..), id:2=>(..) }.

  --Lewis Hoffman.....Wed Feb 20 10:02:26 PST 2008

---

---

also want to point out that this could ultimately be taken further to include some cool nesting:
[:and, A, B, [:or, C, D, E] ]

  --Ethan McCutchen.....Wed Sep 17 13:12:22 -0700 2008

---