Mark,

I have no trouble with anything you have written here.

I had stayed out of this discussion (something I generally find hard to do) for the reason that, without knowledge of the criteria used in the evaluation, I found the "result" rather crude and elementary.

But as others weighed in I could at least concede that the originator had some points worth further discussion (rather than just focus on, more or less, 'who does HE think HE is compared to world renowned EXPERTS).

A recent posting here by Mike Feltman stated along the lines of ..."and just wait till you see our Tahoe version WOW!!!!"

I think that backs up my argument about an evolving product (where better is yet to come). Yes, it also says the vendors care and do improve their products, but who can say what they may have to trade off in order to continue to support facilities which may be obsoleted by (etter) Tahoe features. This gets expensive too.

But I am happy that they jumped in when they did and that they continue to improve their products. That's how things grow and get better. But it remains reasonable that they got in at the early end of the curve and that now they have a few albatross to carry which they would be better off without. This could be from a view of over-simplification or over complexity.

In the end, *any* of the commercial frameworks are a whole lot better than anything I have written. But that doesn't necessarily make the great.

regards,
Jim N


>Jim,
>
>Your comment about experts is very true & I think you'll find that all of the frameworks avaiable today for VFP are consantly undergoing revision, & update as lessons are learned and new techniques worked out. Experts indeed.
>
>However, this reinforces my point that to write a new one from scratch is contrary to OOP principles, that it isn't a trivial exercise and you can't do it in a short space of time.
>
>The qualifier to this is that it is perfectly acceptable to write your own accoring to OOP principles if these ones available don't do what you need and you can't modify one of the existing ones. Of course, there are other reasons such as learning how, but we are talking about a commercial situation here and I would have serious doubts about a developer that wrote a framework in such a situation just to learn about it unless she/he was going to lecture about it or sell it. Otherwise it would sound like learning at the clients time & expense.
>
>Opinions are fine are great especially as everyone has their own. However, that doesn't make them right or wrong. However, if one is going to express a negative and possible derogatory opinion it is usually a good idea to explain why.
>
>Saying that you look at something and discarded it as no good is a very easy thing to say, but gives no indication of the criteria or effort involved in the process. If I took a look at a shrink wrapped VFP product, that is I picked it up, shook the box, decided that it wasn't heavy enough or I didn't like the presentation I would still be able to say that I'd look at the product but discarded it. This is a very diferent proposition to buying the product, learning about it, trying it in a number of different ways and determining to the best of my ability it suitablilty to do the job I needed it for.
>
>Now you may say that the first example is trivial and nobody would do such a thing, but my saying that I'd look at a product doesn't by itself, give you or anyone else enough information to tell whether my opinion is worth anything.
>
>By the way, I had a client once with a manager who did pick & choose software products by the weight, ie how much documentation there was and by the presentation of the box!
>
>Similarly, the comment about why those particular three products. There are more than ten frameworks avaiable that I know of & I live out in the sticks (Malta), so there are probably many more. Given such a choice there must be some criteria for shortlisting three. Weight & presentation, perhaps?
>
>We're not told and to my mind (yes, an opinion but with details), this throws doubt on the validity of the opinion.
>
>Nothing new about my comment regarding OOP, no, absolutely correct, but the point was that developers do tend to forget it. If a component exists that does what you want, evaluate it first before writing your own. This is something I have to drum into students on the courses I've taught time & time again. It may be nice to be able to say that you've written a component, but that doesn't mean that it's good practice to do so.
>
>Wow, that's a long message for this time of the morning, I hope it's explained my previous message a little more explicitly.
>
>Regards,
>
>Mark Austen
>[Schooner Software Limited]