There is more to type inheritance than just the content, and I think even in the case of *content we're not inheriting in all the ways we'd like.  flags like collection? and clean_html? for example.  It really gets tricky when we start thinking of not just code inheritance but setting inheritance :)

---

Hmm, I definitely see your point. But should we do this now anyway whether or not we can handle the more tricky cases?

 

I think that when we fully implement features like collection? and clean_html?, this ruby level inheritance should pick up all the necessary hooks to inherit these features as well. You are right that settings are tricky, but if we really want that, the general solution that has setting lookup integrated with Card::* method inheritance. That is beyond the scope of this card.

  --Gerry Gleason.....Thu Feb 17 14:31:45 -0800 2011

---

gerry, yes I'd say let's do the ruby inheritance and not worry about set ramifications for now.

  --Ethan McCutchen.....Fri Feb 18 10:45:38 -0800 2011

---

I'm thinking that was we want is a type module that is empty except for including the module to inherit from. I was a little curious whether we had any type modules that only include from a second type. So, if I create a type MyType with the rule MyType+*type+*default being a PlainText card it is as if we had the !file: contents of:

mod/NN_module/set/type/my_type.rb: include Card::Set::Type::PlainText

Of course, the codename :my_type won't exist, so the the internals can't quite work like that.

 

I note that the url matcher is really aggressive now.  I don't think file: should be a url, but it is.

---

conceptually that makes sense. would be interested to hear what is proposed for the internals; the currently implementation is deeply codename dependent. I would certainly be wary of anything that involves cardnames.

---

Right, ideally it would not involve cardnames, but I could see implementations that used them carefully. I'm thinking the main case we are interested in is when the type does not have a codename and therefore it doesn't have a module for type already and we can just put the module it inherits in the set_mods attributes that caches the looked up modules. We'll have to be sure to reset this when *default rules are created or deleted (renamed). If there already is a module for a given type, then we can skip this lookup and require the developer add any inherited modules in the code.

---

even in this case I wouldn't want to use the cardname; I would lean towards the id if possible.

---

Added as a PR, and as I suspected, I don't need to store any name related stuff. When it is creating the pattern instance for a type pattern, it looks for an existing +*type+*default rule and remembers module_key for the type rule in the pattern instance. It looks for the modules in the regular lookup. I guess it could make sure there is at least one module for the type before remembering it, but that's a small performance mod.

---

I just realized a very important use case: As an Editor, I want to categorize a large number of links using card types.

 

Solution: MyLinks is a Cardtype, create the rule: MyLinks+*type+*default, :type => URI

Create as many of these as you want, and use these types as categories for links.

 

Debbie has been liking the URI type, and is creating lots of links. I know she will like being able to create categories this way.

---

nice case. by the way, the name of this ticket suggests that we should also inherit from structure rules. Your implementation only handles default rules, which I think is actually correct. I can't really think of a use case where we'd really want cards to inherit code based on their type's structure rule's type, since for those cards all the action is in their included cards. You?

---

With a *structure rule, I think the views at least are on the structure card itself, which actually has the right type and it does what you would expect. With *default, the card would become that type for most patterns, but for type it has to get the real (often user created) type, not the one from the rule and we were just losing that information.

 

Back when we still used subclasses of the base card class for type inheritance, we may have had it so when we automatically created the constants for user classes, it would inherit from the one in the *default rule. I suppose if we had had some test cases for that we may have found a way to keep it working all along. That is now a long way back in code history.