06s524week1.htm

Message 1/32 From Bob Lech= ner = Jan 24, 06 01:38= :55 PM -0500

Subject: Re: [Msgs] 91.524.291 - yes - just for tonight - at MCC. N= ext wk. OS209.

To: sfrye@cs.uml.edu = (Scott Frye)

Date: Tue, 24 Jan 2006 13:38:55 -0500 (EST)

Cc: lechner@cs.uml.ed= u (Bob Lechner)

= RJLRef: $PH/06s524/scheduleNotes060124.txt [extract be= low in 06s524week1.htm]

1. 91.524 Class:=

Tonight we can meet in MCC/LF214 just in case someone else

shows up, although I = don't expect it. After tonite, use OS209.<= /span>

Jim Magarian says your class can keep its 91.524 SEII number on your transcript. The course style necessarily morph= s into the equivalent of 91.592 Directed Study (as does my pay:-(. You don't have to add 592 an= d drop 524.

I view this course as= a chance for us to motivate each other to read the SWF book quite thoroughly.= I myself hope to apply its lessons learned to COOL -GEN/LCP/BDE. Bde refactoring will cont= inue to consume any time I spend programming. You are welcome to join me, but that's not mandatory.

Understanding SWF is = more important. My limitation is lack of experience with uSoft's VisStudio.NET, w= hich is evolving (long-erm) toward SWF ideas. SWF's bias seems to be toward a single [.NET] platform solution.

[Why not, from their standpoint? uSoft IS big enough, just as IBM USED TO be.]=

As far as schedule go= es, I suggest we inform each other when a new chapter is read, then schedule a meeting. That will motivate the one that's behind to catch up by that time.=

I am currently into <= span class=3DSpellE>Chaper 4 - CH 1-5 are in Part 1 of the book. Do you h= ave the text? I did not order it for the bookstore since enrollment was so smal= l. Amazon and bookpool probably have it. For tonight I ha= ve enough notes so you can use my copy if needed.

I also went to MSDN a= nd SWF websites and copied some of authors' position papers into $PH/06s524/SoftwareFactoriesText, and URL favorites into $PH/06s524/microsoftSites. Only a = few are helpful, with figures recognizable from the text, but none are technical enough to support Part 2 (Ch. 6-15 in pairs).

Part 3 'puts it all t= ogether' with 2 chapters on an example.

2. GEN/BDE/LCP:<= /o:p>

In bde, I am still fixing self-introduced bugs that mask menu text until clicked up= on and delay text entry (one char per click) and corrupt display list content prevents debug output. The bde tree is up to da= te at $BDEROOT, but chgen13 is out of date at $GENROOT. I continue to update bde/pr_util_[no]log pr_*.c as I find bugs or need to annotate.

R Almonte made a good beginning on wrapping current bde i= nside elegant platform- and [even fox-]GUI-independent patterns, but compilability on Mercury/RedHat Linux is fragile after migrat= ing from PC-based Eclipse/CDT.

All the refactoring and X11-wrapping work needs to be done.

[Don't think that the= single iconoclastic rant at the link $PH/06s624/DesignPatterns/DesignPatternsConsi= deredHarmful.url

indicates my sympathi= es. It is merely an opposing view.

I like DP's; and SWF = clearly emphasizes their place:

its goal is encapsula= tion at a higher level than single classes, to achieve more decoupling and reuse, so packaging and deployment can get away from laborious manual customization. = That's exactly what Almonte had in mind for bde.

(Now if only Eclipse/= CDT *.mk a= nd xmkmf/gmake files were transparently mappable in each direction.)

Migration from pr_set_type to XXset_field (in pr_accessors.c) is a needed bde<= /span> sub-refactoring. Gencpp enhancements such as c'tors of abstract superclasses<= /span> are another need. Runtime classes can also be auto-generated from schemas a= nd linked trogether automatically. Views can limit persistence to SAVE that subset of classes which are not redundant, and from which the run-time graphobject subclasses can be reconstructed by updatedisplaylist.<= /span>

= Chgen-to-gencpp migration is highly correlated with bde to fox migration in my view, to avoid losing of t= he code generation opportunities of GEN and LCP.