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

[Dan B. <dbr...@wo...>]

Gene wrote:

> I'm happy to report that I am now in a position to put together a 
> working foundation class library fairly quickly.  

[...]

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

Actually, most of that was between you and me (or
that was my intent, anyway :-)

I should start by saying emphatically that I don't
want this to devolve into a style debate; *any* 
progress is better than no progress (which is all
I offer right now.)  Besides which, my own GUI 
skills are in the public view for you all to see :-) 

That said, I do think there could be reasons why this
approach isn't necessary in Curl.  Curl offers many
ways to change an object's behavior other than 
inheritance; options and event handlers, to name
two.  You can do a lot without having to create 
subclasses at all.

[...]

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

FWIW, if the package load.curl is in the same 
directory as the file that imports it, you don't
need a location hint at all (relative paths also
work.)  We have used a convention here that test 
files can be placed in the same directory as the
things that they test; the name is prefixed with
"t-".  So your test file could be "t-Foundation.curl",
for instance.


Thanks!

-- Dan