[curl-email-news] followup on foundatin class

[Gene H. <gh...@nc...>]

Thanks everyone for the encouraging words on my last post.  Sorry 
it took a while to respond but I figure this will at least be waiting 1st 
thing Sunday where most of y'all are.  This will be a mix of 
responses to the feedback from Chris and Friedger.

By the way is everyone else getting two copies of every post or is 
there something weird in my setup that's causing it?

Based on your feedback I conclude that we do want to have at 
least one of our own classes underneath all the objects in the 
curlmail applet.

I hope you'll excuse me for referring back to PowerBuilder (PB) 
from time to time.  It really has many parallels to Curl.  Of course it 
is very different too.  Both are used to produce programs that run in 
Windows.  PB runs on the desktop and is used to produce 
client/server apps.  Curl runs in the browser and produces a rather 
different breed of client/server apps.  Both have a complete OO 
programming language.  PB has a whole set of UI and other 
objects that you use to build apps.  PB has objects that handle 
events.  PB supports private, protected, public and class variables.

You may not know it, but there are a huge amount of PB apps out 
there that are getting rather dated but have not been replaced 
because of all the things that (until Curl) you can't do in the 
browser.  Once Curl gets critical mass I think the demand to 
replace these PB apps will be enormous.

After many years, tens (if not hundreds) of thousands of projects 
and millions of man hours with PB the proven best practice was to 
always use a foundation class.  It was typical for most objects to 
have 1-4 layers of inheritance in them.  I would start getting antsy 
about performance with 5 or more layers but the advantages of OO 
design were considered to far outweigh any performance penalties 
unless you had a really excessive number of levels of inheritance.  

It was generally the stuff your objects were doing (like hitting the 
database) that had the big performance penalties.  The PB runtime 
system was very good at dynamically assembling objects and I 
suspect Curl is too.  I can tell you that changing a few ancestor 
objects and seeing the result propagated throughout you app is 
extremely awesome.

When I was talking about a naming convention for objects I was 
mostly thinking in terms of foundation class objects (I tend to refer 
to these as base class objects too) which are the first level of 
inheritance off the Curl library objects.  By definition these are the 
most generic objects that you have.  Once you start creating 
objects off of these, you are usually thinking in terms of creating 
some very specific functionality.  

What I'm working up to is that it is more natural to name 2nd level 
and above objects based on functionality.  I don't know of any big 
advantages to having the same prefix stuck on every object in the 
system.  With PB I don't recall any reason to find every object in 
the app.  Usually you are interested in one or a few specific objects 
at a time.  As long as you are reasonably aware of Curl object 
names, name clashes are unlikely.

I am not strongly opposed to the same prefix on all objects if that 
is what you guys want but would like to toss out a couple 
alternatives before it becomes final.  One option that could be 
useful is to use a different prefix based on what package an object 
is in.  With this the prefix might be "UIBase" for UI foundation class 
objects and "UI" for other UI objects.  This makes it easy for 
someone new to the project to track down the source of any object 
they encounter.  Another option is to drop the prefix altogether 
once you're above the base class and rely soley on a descriptive 
name.  I don't kown of any problems that this would cause.

In PB we put foundation class objects in their own library 
(equivalent to package in Curl) and I'm thinking we would do the 
same.  We would have one such package for visual gui objects and 
gather that we have something that is roughly equivalent for a lot of 
the communications stuff.  If we find a need for more types of base 
classes we can create appropriate packages.

I have more to write but it is getting late here so will take up where I 
left off tomorrow.

Best Regards,
Gene