Forum OpenACS Development: thoughts on [extends ...], inheritance and converting down

so I was thinking on what it would take to convert a derived subsite to plain subsite... and one of those things would be removing rows from all packages inheriting subsite between but not including acs-subsite and the class(es) listed in the extends

(and including that/those classes)

and parameters too I guess

example... so if you have A-subsite deriving from acs-subsite, B-subsite derivng from A-subsite and C-subsite deriving from B-subsite...

(note degenerate case of single inheritance chain)

and you make a C-subsite and later want to convert it to an acs-subsite,
you'd first convert (i.e., just set package type), then

remove C-subsite's rows and parameter values

remove B-subsite's rows and parameter values

remove A-subsite's rows and parameter values

and permissions

I noticed that also allowed, is the possibility to have a package implement subsite semantics without inheriting... and if you have this case, the UI should fail to allow that conversion, since figuring out what to remove and then what to add would be less trivial

so the UI would only allow conversions to inherited classes
<jim> and if someone wants to figure out how to convert for that case, cool... and good luck :)

Thoughts?

-Jim

Some time ago, before openacs, acs_object was created, and so we have an object system... might be useful to have some CASE tools to show class hierarchy, and show and maybe even edit methods and instance vars.

But then, xotcl came along (not in core atm, so not so relevent as acs_object) with the effect being, now there's two object systems, and the CASE tools from above could be factored such that they can work with both...

BUT

now we have a third object system implemented by [extends ...] and so things are starting to get tense with all these different systems. While all three systems offer your basic OOP functionality (give or take), the extends system probably offers the most potential wrt package-based app construction, and the idea of inheriting from subsite to get different-looking or different-acting subsites is a great first application of that idea.

I'd like to see a very simple system using extends that allows the construction of very simple composite apps, maybe have 5 packages max that can be used there.

The CMS in the original acs had a feature that I sortof understood but never saw used: the idea of storing a template for a content_type. I think this combined with [extends ...] offers a way to create packages that serve to define single acs_object_types and/or content_types and has all the UI and functionality to deal with their object inside.

One idea that comes to mind is to have package methods which add (1) form elements and (2) form actions to existing forms whose names are passed into the methods. The form actions would be the typical new_data and edit_data that a form would normally have.

So I'm realizing however that objects in the [extends ...] system are actually package instances, and so the combination would have them be acs_object factories and managers.

Anyway, I think the [extends ...] idea is cool, and I wanted to fire up some discussion around it.

I'm not arguing that it would be nice if everything were wrapped up cleanly into a single mechanism.

But if you believe apm packages are objects now, then you need to understand they were just as much objects before. so your "three mechanisms" complaint isn't pointing out a change.

"extends" is a slightly stronger form of inheritance as you get parameters and (optionally!) immediate access to templates, and all the packages you extend and your own package share a single package_id.

But the "weak inheritance" from before - datamodels, tcl scripts, oh and resources and the include librarys, too - are unchanged, while the last - access to templates - isn't new, just strengthened/different.