[curl-email-news] more followup on foundation class

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

Will try here to pick up any loose end I did not get to last night.

I would feel better if whatever we use for our own naming 
conventions follows the Curl naming guidelines.  You can bet that 
anyone that goes to the official Curl training will be taught to use 
them and all the official Curl docs and examples will follow the Curl 
guidelines.  As early adopters people will look to us to set 
standards in this and other areas.  The naming guidelines seemed 
rather odd to me at first but they are starting to feel more normal 
and I have to believe that whoever came up with them has a better 
overview of things than I do.

Initial versioin of 0.1 sounds great to me.

If you have a strong preference for ORG.CURLMAIL.XXX for 
package names I will go along but ORG.CURL-MAIL.XXX allows us 
to stick with the naming guidelines.  Dan suggested ORG.CURL-
EMAIL.XXX which would also be good.

I'm good with spaces around assignments and most other 
operators so let's plan on that.

In PB we used inheritance extensively with transaction objects that 
handled database details and custom objects which implemented 
various specialized processing that could not be done with 
standard objects.  An example might be inplementing a spell 
check feature that picks up errors as you type.  I don't know 
enough about Curl at this point to suggest anything more specific 
but inheritance can definitely be useful with non-visual objects.

I don't know of any compelling reason to use a function call to 
instantiate objects.  One reason I put those in my example 
package was that I was extremely pleased that I got them to work.  
Before I figured out that I had to give the constructor public access, 
the only way I could create the objects defined in the package was 
to use the function call method.  If you build the constructor (of a 
class defined in a package) with package visibility you can force 
any creation of the object outside of the package to go through a 
public access function which I thought was rather cool.

As per Dan's suggestion I was able to remove the path from the 
location spec in the import statement I used and all still works.  
Just keep the package in the same place as the code that imports 
it or use a relataive path and we should be ok.

I like the ideas of using our own names in the internal documention 
of files.  Since we're not getting paid at least we can get a little 
glory.

I agree with Chris on having good internal docs at the top of each 
file.  I don't especially enjoy doing it but it really helps and, again, 
we will be setting an example that others will be looking at.  I say 
let's take what Chris sent and use that everywhere.

I think we're very close to having a consensus on how to move 
forward.  If I can get some further feedback on package names, 
where/when/what to use to prefix class names and thoughts about 
sticking to naming guidelines that should about tidy things up.  I 
will then write up what I think is our consensus is and send that out 
for final comments.

I'm anxious to get a design and start coding, but at the same time 
the more we learn about working with Curl before we start coding, 
the better the final product is likely to be.  I think it is pretty much a 
given that we will change the design and/or implementation a lot as 
we learn more about working with Curl.  

I see the Curl email project as a chance to create a really 
compelling app that will be the first exposure to this technology for 
many people and a significant step towards being able to go to 
monster.com and finding big lists of  jobs available after doing a 
search on "curl".  I've got cable modem at home and when I use 
hotmail.com it is still frustratingly slow and clunky to do anything 
there.  The potential impact of this project is huge.

I'm open to writing an article for curlbreaker but feel I need to learn 
a good bit more before I start telling other people how to do it.

Gene