Re: [curl-email-news] foundation class update and request for comments

[Chris B. <ch...@bs...>]

Hi Gene,

Great mail! Very motivating to see one of our fledgling group grabbing the
bull by the horns.

What you have written below is very informative, and extremely well written
-- great explanations of WHY you propose doing things a certain way.

I've plonked my feedback throughout...

----------
>From: gh...@nc...
>
> I suppose it is obvious that these rasise a
> swarm of questions/issues.

Not that many from my standpoint, actually...

> I have worked with vendor supplied class
> libraries prior to curl and one of the golden
> rules that I have accepted is that you never
> create an object in code that inherits directly
> from a vendor library object.  Instead all
> objects inherit from your own objects in your
> own libraries.  Hence the idea of a foundation
> class library that holds all your lowest level
> objects that inherit directly from vendor
> library objects.  The result is that you can
> make global changes in any of your objects by
> changing the corresponding ancestor object in
> your foundation class.

I agree with you on this. Indirection is one of the fundementals of OOP, and
every time I 'skip' doing this type of layering, it comes back to haunt me
(sooner or later).

> So with the sample code above, instead of having
> VBox objects throughout your code you would have
> MyVBox objects.  I've seen the advantages of
> doing this on some fairly large projects and it
> is hard to contemplate the alternative.
> Ultimately you would probably have several other
> objects in a UI package that inherit from MyVBox.
>
> You have probably read Dan Breslau's post where
> he suggests that the golden rule cited above may
> not be warranted and for sure suggests that
> objects should be named according to their
> function.  My intent here is to get a feel how
> the rest of the team thinks on these issues and
> not to suggest that mine is the only way to go.
>
> I am new to programming in curl and suspect most
> of the team are relatively new to it too.

I'm afraid the only Curl gurus on our team are those that work at Curl corp.
I'm looking forward to changing this fact though :)

> My experience with this type of situation is that
> about the time we get the project finished is
> when we'll know how we wish we had done it from
> the beginning.

:)

> Having a foundation class object
> underneath all our objects will give us the
> chance to go in and do some of the things we
> wished we had done in the beginning with the
> least amount of effort.
>
> The base class objects are the most generic
> objects of a given type that we will have.  In
> the spirit of giving them descriptive names we
> could use GenericVBox instead of MyVBox or maybe
> GenVBox.  I am personally not fussy about the
> exact name buy do prefer something rather short
> and consistent.

I don't think any of us will to set on any naming rule. I'll suggest using a
short prefix that pertains to curlMail:

    CMailVBox
       or
    CM-VBox

I know that the second breaks the 'official' Curl naming conventions, by
using a '-', but it is short, and will make our project's classes quick and
easy to spot.

> Note in the package code above
> I have written a function for each class that
> returns an object of the given class.  This
> would add a layer of indirection that may prove
> valuable and I like it because the curl naming
> conventions mean that function names are all
> lower case.  So whether to create all objects
> through a function, directly from the class
> name, or a mix of the two is a related question.

You've got me there! Do you have a concrete reason for the extra
indirection, or is it just a 'gut' feeling from previous experience?

> Finally a few smaller questions to think about.
> The location specifier in the package
> declaration above is specific to my computer so
> we need to find a way to deal with that.

I would be happy with ORG.CURLMAIL.xxx

That should keep us from colliding with other package names, and it's not
too long.

> And how about author and version in the package
> declaration.  Are we going to use our own names
> or a team name and what version to use for now?

I like the idea of having the creator of the file adding their name as the
"author". This will make it easier to ask questions in the future.

I would like to see us use a standard set of comments at the top of each
curlMail file, where other member who have worked on a file can add their
names. Notes about the change/bug fix history might also be called for. At
some point Curl corp. will be releasing the hooks for the CurlDoc generator
(like the API docs), and it would be nice to have the infos already in
comments, so we can migrate easily to this inthe future.

Here are some ideas off the top of my (sleepy -- still feels early to me)
head for this file 'comments' header:

Creation Date:
Modification Date:
Project Name:
Workers:  (those who have actually worked on this file)
Explanation:
Notes:
Version History:
Known Bugs:
ToDo:

For the versioning numbers, I propose to use the Unix system that Open
Source projects seem to prefer. So "0.1" would be a good place to start. We
just need to figure out what we want to achieve for the "0.1" release :)

> And what about the file name Foundation.curl?
> Do we want to think about standards for file
> names and indentifier names?  Also points of
> style such as spaces around assignment
> operators, etc.

How about prefixing our project Classes and Procs with 'CM-' and 'cm-'
respectively?

I Very much vote for using spaces around the '=' -- I personally find it
quite tough to wade through long assignments where everything is squished
together

    Use this:  set a-box.width = 200px
    not this:  set a-box.width=200px

> I'm ready to move quickly on building a
> foundation class which for starters would hold
> all the visual GUI classes that I can come up
> with.  Foundation classes can also be valuable
> for non-visual objects but it depends a lot on
> what you're doing with them.
>
> Your comments are requested and appreciated.
>
> Gene H.
>

Don't let us slow you down Gene!

Also be forewarned that I'm going to be hounding you to write an article for
curlBreaker.com -- especially after seeing how well you write :)

Regards,

-Chris

------------------
Chris Banford
ch...@bs...
bSoftware
Zermatt Switzerland
------------------