VStudio generating classes

[Thorsten Hohage]

Sorry, I'm a bit behind. Some days ago I think Ruslan wrote about  
generating "classes" from VStudio for usage in the "VForms" (working  
title ;-)), I'm not sure if this dream also included generation of  
e.g. RBclasses (of course for any other development plattform, too).

Regarding this topic I want to strongly recommend to check  
EOGenerator (http://www.rubicode.com/Software/EOGenerator/) and there  
philosophy of how a generation concept should work.

In short (and yes it's again inspired by WebOjects / EOF work):

When generating mapping classes for simple (read flat or not  
inherited) design there is no big deal behind (except the translation  
of a table design in the language, but I don't want to discuss this  
here). You get your class, you use it and go.

When "good" OO-design come in the game you'll going to use  
inheritance real soon and for sure you start to modify the generated  
classes. Then there a two options

a) forbidden areas, in worst case done by comment "don't edit here -  
start here your own code" - one simple word CRAP!

b) one way generation. The tools generates the classes, but if you  
change design then you have two options, change the generated class  
manually or become a new class, then use diff, ... not such a big  
piece of crap, but again crappy.

When now start thinking the answer to b) is inheritance on the first  
glance. So I get a generated class e.g. "DBCustomer" and I code in  
"MyCustomer" - sounds good, I can re-generate as often as  I want and  
feel free to change my code. So everything ok, right now???

Shocking but true: NO!

And it's a shame, most tools (even EOModeler works this way)! So what  
is the problem here?

When you start thinking the right way, the OO-way (oh no, this was  
joking no flame war - please), then you will need to use table  
inheritance real soon. You'll use abstract table definitions, tables,  
inherited tables (in all variations) ...

--
You never hear about it? There is a chance to get nice material for  
free, but I'm afraid not for a long time, because the EOModeler has  
been deprciated (but that's another story)

<http://developer.apple.com/documentation/WebObjects/UsingEOModeler/ 
7ModelingInheritance/chapter_7_section_1.html#//apple_ref/doc/uid/ 
TP30001018-CH207-TP1 >

check the side, there is a link to all this as a pdf file
--

OK, now everyone should be in the boat ;-) - table inheritance.

We have e.g. tables

	Person

	Customer

	Subscriber

Subscriber inherits from Customer, Customer inherits from Person.  
When we now use the generation scheme described above, we'll get

	DBPerson

	DBCustomer inherits from DBPerson

	DBSubscriber inherits from DBCustomer


you see it? There is no space left for "our" MyCustomer - class, of  
course we can change it manually and get

	DBPerson

	DBCustomer inherits from DBPerson

	MyCustomer inherits from DBCustomer

	DBSubscriber inherits from MyCustomer

but what if we need a MyPerson, too and what if we're talking about  
the 60+ tables from the other thread? Or "real world" applications  
with 120+ tables, 5 inheritance levels, ...????

At least after a year and two projects later we come to a conclusion,  
the answer to b) is ... you'll guess it - crap, too.

The solution is so simple, but obviously so hidden for most  
developers of generators, the generator always produce a pair of  
classes, one for internal (= mapping) usage and one for the  
developer. The internal is allways generated to fit the model  
changes, the second is only changed in the header if the inheritance  
schema is changed.

So we get ("_" is internal)

	Person inherits from _Person

	Customer inherits from _Customer inherits from Person

	Subscriber inherits from _Subscriber inherits form Customer

and everything is fine. Generate you 120+ classes, do your 10 changes  
a day during development, maintain them and extend them over the  
years, as smart as your shadow on the wall.


So enough theoretical work done for today, back to the IDE. Thanks  
for the audience ;-) - I hope this longish email will produce enough  
requests for implementing that style of class generation in Valentina.


Btw. someone mentioned the "internal" logic of "VForms" should be  
JavaScript. THAT's a great idea, because JavaScript is one of the  
modern OO-developing languages supporting multi-inheritance, dynamic  
class definition during execution, ... - GREAT things could be done -  
ok, we're going met all in the Smalltalk-Therapy-Group every friday  
*lol* - Nice weekend!


regards

Thorsten Hohage
--
objectmanufactur.com - Hamburg,Germany