Hey John,
I may be stretching it a bit, but so are you. Yes, if an object holds multiple collections, Count is ambiguous. But a PageFrames sole responsibility is to manage a collection of pages--likewise an OptionGroup for buttons. The Count could be called PrimaryItemCount, I would simply argue for a specific name for a specific abstract concept, in this case, the number of items contained.
I have read your other posts and you have good company in your argument for naming conventions. In my Fox Talk article, "A cRose by any other oName", Steven Black wrote in the succeeding issue that naming conventions were still a good thing. He said something to the effect that it no prefixes looked unprofessional. To my mind this shows the weakness of the position, but others find youall's points conpelling. Steven Black did make note that the convention for an array, a starting 'a', was good in that
myvar = '' when it's an array really means

FOR m.x TO ALEN(myvar,1)
   myvar = ''
ENDFOR

and I agreed that an arrays need some help to be clear as to what is happening.



>Hi Charlie ----
>
>>I like polymorphistic names, so I think MS erred by naming things like PageCount, FormCount, ButtonCount. It's a PageFrame! It has a count! The property should be Count. If something has a Name, I call it Name, not CustName. It's in the Customer table, so that's the context.
>
>I personally agree with the customer table argument, but several server database design tools would disagree.
>
>OTOH, it's PageCount, FormCount, etc. because it's a reference to a collection of the root object, NOT the root object itself. Therefore, PageFrame.Count would be non-sensical. Is this a count of PageFrames? Is this the Count number for this PageFrame? And what about objects that hold multiple collections...they can't all be Count, can they?