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

[F M. <mu...@co...>]

Hi,

> 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).

I'm not well enough qualified to say anything about the practical aspects of
OO. However, I think it can't be too wrong. The only concern would be
performance. Does it make any difference to subclass everything (at least the
GUI-elements)?


> > 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.

Sounds reasonable, although Dan questions if it is necessary.

I remember to have heard something about general layouts for GUI-elements that
can be defined and changed globally. Something like the ControlUIs. Is that
right?


>     CMailVBox
>        or
>     CM-VBox

I would go for CMVBox or VBoxCM.


> I would be happy with ORG.CURLMAIL.xxx

Me too.


> 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 :)
>

I'll provide t-files for the three basic protocols.


> > 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?

Do you mean the file names? That's too much I guess. I'd suggest capital letter
in the filenames, subdirectories in lowercases.


>
> 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

Hopefully, there will be an add-on for the IDE that will do the layout for me,
more than only indenting.

> > 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.

What kind of non-visual object were you think of? String, Timer, Socket.....?
The AsyncClientConnection would be our foundation class for the socket. Or
should I say CMAsyncClientConnnection. I'm confused!  >:- |       When shall we
use the prefix? Only if it is a subclass with the same name?  Should I
introduce CMSocket to the connection class?


> Don't let us slow you down Gene!

Go ahead! I'm looking forward to seeing a first layout of the user interface.

Friedger

--
Friedger Mueffke - University of Bristol
http://www.cs.bris.ac.uk/~muffke - mu...@cs...