Re: Objective-C++, class scope constants, name conflicts
Re: Objective-C++, class scope constants, name conflicts
- Subject: Re: Objective-C++, class scope constants, name conflicts
- From: Scott Ribe <email@hidden>
- Date: Fri, 10 Feb 2006 18:34:58 -0700
- Thread-topic: Objective-C++, class scope constants, name conflicts
> The specific number of instances referenced by an object is IMHO an
> implementation detail. Mr. Ribe states that the referenced objects
> are in fact Cocoa controls in a user interface. This is certainly an
> implementation detail that should never be exposed in a class
> interface. Mr. Ribe seems to want maximum coupling between several
> "things" that should be separately encapsulated: A nib file, a custom
> class, and all the code that uses the class...
No, as stated I want it to be a class-scope constant with no visibility
outside the class. Yes, I asked for class-scope, and if Objective-C had the
feature it would obviously offer the choice private vs public, but elsewhere
in the messages I believe I made it clear that no code outside the class
needs access to the constant. The code that uses the class has no coupling
to this constant (except of course for the header dependency based on the
class ivar layout, but there's no way to add an IBOutlet or any other ivar
without triggering recompilation of client classes).
> If there is any reasonable
> possibility that the user interface could change, I would argue that
> he automatically has a flawed design...but let's assume he is right.
Of course the coupling is undesirable, but as far as I know, Cocoa offers me
NO WAY to change that number of controls in a nib without changing code in
my controller. (And it certainly doesn't offer me a path to add controls
without remembering to connect them all properly.) If I am wrong, please
enlighten me. If not, then realize that I am merely trying to reduce the
code that must be changed to a minimum: changing the value of one constant,
adding or subtracting IBOutlet ivar declarations, and adding or subtracting
single-line initializations of the form controllerArray[7] =
controllerGroup7.
> I question
> the wisdom of using a C array for this purpose at all. By using a C
> array, Mr. Ribe is creating extra work for himself and potentially
> introducing memory errors. Cocoa collections retain the objects they
> contain. C arrays do not. By not using an Cocoa collection (with
> exactly six elements or not), Mr. Ribe takes on the _extra_ burden to
> correctly manage the reference count of objects referenced by the
> array. The _extra_ (but required) messages to retain will most
> likely seem very odd to the poor programmer who has to maintain this
> Cocoa convention flouting code that Mr. Ribe is writing.
Not at all. As I pointed out in a previous message, the objects are already
retained and released as needed by the very same controller of which the C
array is a member. No need at all to do *any* additional Cocoa memory
management just because I happen to want to collect pointers to certain ivar
members in a form that is convenient to iterate over.
> The obvious other reason to declare the constant number of array
> elements in the class interface is so that the following code can be
> written (using C++ syntax):
>
> SomeControlClass **arrayOfSomeClass =
> someObjectThatHasArray.GetCArrayOfSomeClass();
> for(i = 0; i < SomeClass::someConstant; i++)
> {
> SomeControlClass *currentControl = arrayOfSomeClass[i];
> // Call some member functions of currentControl
> }
Absolutely not. As I stated in an earlier message, the count is private to
the class, as is the array.
> If he at least used std::vector, he could have used an STL
> iterator and avoided the fragile non-polymorphic use of a magic
> constant. However, unless he also uses an IMHO excessive amount of
> wrapping of Objective-C instance pointers in "smart" C++ pointers and/
> or other _extra_ code he will still have convention flouting
> reference count issues.
As pointed out: there is no way to avoid changing code if the number of
controls changes. (And at some point there will be fragile code appending
the existing ids onto the STL vector, or the NSArray, or whatever, IOW if I
add controlGroup7, then I've got to get it into the array after all.) And as
pointed out, there is no need for smart pointers or any other technique to
retain and release these Cocoa objects. As for inheritance, this is a window
controller for a specific window; it is a leaf class and will never have
classes inheriting from it; if a future design requires several similar
classes, common functionality would be factored into a base class.
I welcome Cocoa design critiques, but I really don't think you understood my
prior messages before going off on this "philosophy of OO" tangent.
--
Scott Ribe
email@hidden
http://www.killerbytes.com/
(303) 722-0567 voice
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden