Hmm, I see why this is confusing.

 

The type of a Something card is "Something", not "Pointer". *default rules applied to type sets can change the default content of all cards in that set, but they can't change the type, because that's what defines the Set.

 

It seems like what you're wanting is for *default setting to make the Something setting inherit a bunch of the Pointer behavior, no?

---

You can do that, but you have to do a little developer stuff. All user-created cardtypes 'inherit' from Basic. If you have a *structure rule (Something+*type+*structure), then the type of the rule can determine the behavior of the type.

 

On the other hand, you can create a module for the Something type, which includes the module from another type (say Pointer). A module like this would only be about three lines of code, but it does require additional code.

 

You might wonder then, why have a type for *default rules at all, but for all other rules, it does set the initial type for a new card that matches the set pattern. It just doesn't make any sense for type sets.

---

(unless you want default content)

---

Wrote a full page to reply to the first post and then decided it was too long and messy, but here is the first part, as I think it confirms lots of issues that have already been raised:

(second part needs more time in the oven)

Wrapped my head around the concept. I can understand why the Type of the card can’t be changed since it’s already set at “Something”. However if you go to the default rule and select from the list, not the Basic card, but the newly created Something card (essentially a futile attempt at forcing the type of “Something” to that exact “Something”) one can clearly see that this “Something” card actually looks and behaves just like a Basic card.

 

Apparently when you create a new card you can only “inherit” from Basic, rather it’s a basic card with a new name “Something”.

 

If I want to store an HTML(based) “Invoice Template” I can’t get around the fact that the Browser parses it as a Basic card and interprets the html. I don’t want this, I would like to “inherit” the HTML card type "form" and use that, as the basis for my new type.

 

As it stands right now, new CardTypes are just groups of Basic cards under a new Name.

 

Is there a reason to want for example a new CardType called “Useful files” to “inherit” from File?

One might contemplate that really why don’t I create just a new “Useful files” Card with it’s plus counterparts (instead of a new CardType) and just define a default rule for all “+Useful files” and set that to File and away we go. You could even set this default back to Basic with “Some customized text” and add {{+actual file | type: File}} in there and now we have both the adding of a file and some customization.

 

The conclusion, right now, creating a new CardType brings nothing new to the “table” and is actually less useful, in it’s current form, than actual cards and their plus counterparts. In the current implementation a new CardType is just a Set or a Deck of Basic cards, bringing the same capabilities that are available for manipulating Cards and +Cards to the level of Sets, or Decks of Cards. Extending this to other types would mean we've just invented the concept of a "Deck"

(second part is more interesting but unfinished)

---

Cardtypes are highly useful precisely because they are the easiest way to create new Sets - or configurable groups of cards. This means you can apply permissions to them, give them different layouts, apply different styles to them, or extend them in code. But the most commonly used set configuration (rule) for cardtypes is the structure rule. Without types, the structure rules would fall flat. I know they don't fulfill all the cool patterns you envision, but structure rules are pretty powerful even as is, and unless you can group simple cards into sets (as is currently only really possible to do with types), they're of very limited use.

 

It's true there is no concept of inheritance (we don't conceive of the Basic patterns as inheritance), but that doesn't obviate all the other uses of types.

 

re Decks, I don't think you're using that word the way we are. We have many words for groups of cards:

 

1. A Set is a group of cards to which rules may be applied

2. A Hand (future) is a group of cards that can be exchanged between wagns

3. A Deck is essentially a namespace. It's the complete set of cards in a given namespace. Since a Wagn is currently a single namespace, we conceive of each installation as a single deck. In the future we expect that conception to remain, but there will also be the notion that there can be decks within decks. (See DeckoSystems). It seems like you're describing a different concept, no?

---

I actually agree with you entirely, I never thought they could also be a namespace too. Hmmm... this is very interesting.