Idea

What does the s in *stype and *sname stand for?

---

well, the idea was "self". not great, huh. I guess an alternative could be *_type, *_name, *_rname, etc. one nice thing there is that it would be easy to see which set classes are "anchorless". What I'm hoping we can achieve is (a) clear, scalable naming patterns, (b) leaving open key star names like *type and *name.

---

*all plus ..... *all child ?

 

yeah i think i like the _ better.

 

What do you mean by anchorless? (trunkless?)

---

basically, yes, trunkless. (though, not technically. see below). It ended up being handy to have a separate term for the left part of a plus card set. most of it was about keeping code from getting too tangly, but it also means you can talk about anchorless rules (rules on an anchorless set), cards that anchor multiple sets, etc. So on Phrase+*type, Phrase is the anchor.

 

At some point Gerry and I came to clarity around the following:

1. all cards have a trunk and a tag. A simple card is its own trunk and its own tag.

2. only plus cards have a left and a right.

 

So, while left and trunk are very close, and right and tag are too, they are not quite identical. And no set is technically trunkless :)

---

yeah, perhaps *all child or *all children would work. why did you go with child and not children? just because it's shorter?

 

I think when I pondered this before I considered *children but realized it already had a meaning. *_children, on the other hand, is free...

---

wait, but that breaks the anchorless pattern. doh.

---

this is the very reason we had "*all plus" before (plus was taken), but it's awkward to me. if you go there, why not "*all star" and "*all rstar"?

---

child/children - I wasn't thinking very deeply, that's just what came.

 

I think I'd actually prefer using *all to distinguish anchorless sets. It solves the children problem (*all children ≠ *children) and it's nicely explicit, and as a bonus allows for dropping the underscore - "rname" is bad enough but _rname is even worse as far as arcane naming goes. I know you're probably thinking that makes the anchorless set names longer than you want, but there's only a handful of those, where as there are tons of the anchored ones.

 

Thx for the download on terminology - why is it important to think of simple cards being their own trunk/tag?

---

I really don't like the leading underscores, or the r/l initials. What's wrong with 'right'?

---

child/children could confuse with the use of "children of a particular card". It is the opposite of 'simple' cards, but not_simple seems somewhat odd.

---

*type_and_right, or just *type_right works better for me. Doesn't use plus and if I needed a specifier on the type part ... Well maybe left is ok there, but I think this is more of a 'best default' pattern and you don't need that.  In Basic+*tag+*type_right, I think it isn't really confusing that 'Basic' applies to the card that has that tag.

---

I'm not fond of rname either, but I see how "name" is more explanatory than just "right", and more consistent with "type" - and the l and r language is at least consistent with the existing syntax for relative inclusions which let you string together Ls and Rs. Hm, would Ltype and Rname help at all? Or another way to go would be to use the language Ethan explained above - *type+*tag - although I don't think we're using "tag" anywhere else in Wagn itself for the right-most part, and frankly I find that term a bit opaque.

 

"*all children" avoids any confusion that it was the child of a particular card. Or... what do we call plus cards in a post-plus world? Compound? Accurate, but introduces a new term where we're already using children elsewhere.

 

*type_right sounds like it might refer to the type of the right part (like maybe your example matches cards where the tag is a Basic card).

 

We're trying to convey a lot of information in as few words as possible, so of course this is not easy...

---

Thank goodness Wagn has a benevolent dictator to make the final decisions. :-)

---

:) I think trunk/tag should remain developer terminology. I don't think there's a ton of conversational need for it, but it's handy in code, for example, to say that a set's set class is its tag (regardless of whether it has an anchor). That was mostly an academic digression, I guess, but one I thought you might enjoy.

 

To illustrate what I mean when I say we want a scalable naming pattern, consider that there are lots of possible set classes that a given wagn site might want to make useful via the API. The following could represent three different classes: _ltype _rname, _rtype _rname, _type _rname. And you could have three more with _lname. I can define them if you want, but I'm guessing the names are clear enough that you could piece them apart. "type plus right" or "type and right" provide no such path.

 

---

I'm not sure adding "*all" lets us drop the underscores. Then we're left with "*type", which I would really like to leave open for the virtual trait.

 

a variant of John's suggestion might be lType rName. That doesn't solve the *type issue either.

 

I don't know if I've expressed that clearly, but basically I'd like Company+*type to be a virtual pointer to Company's cardtype (probably Cardtype), not a Set of all the cards of type company.

 

This won't make much sense to John, but Gerry you might also consider the value of having the set class's codename map directly to the set class's method keys. (see patterns.rb)

---

I do get that you're trying to free up *type. Will ponder further if there's a way to do that without the underscores...

---

I just realized that the existing meaning of *children won't conflict. *children can mean the set of all children, while Homer+*children can mean all Homer's children. To me that leaves little need for "all".

 

Gerry, do you understand the rationale for "l" and "r" now? (See three comments back). I'd like to get buy-in on the need for a scalable naming pattern, if not this particular solution. It strikes me as very important. Any time we have a pattern in Wagn that can't handle depth, we soon wish it did.