Re: Initialize a subclass object with a base class object
Re: Initialize a subclass object with a base class object
- Subject: Re: Initialize a subclass object with a base class object
- From: "Liviu Andron" <email@hidden>
- Date: Tue, 20 May 2008 13:17:25 +0300
On Tue, May 20, 2008 at 10:57 AM, stephen joseph butler <
email@hidden> wrote:
> On Tue, May 20, 2008 at 1:50 AM, Liviu Andron
> <email@hidden> wrote:
> > setRepresentedObject: is a hint, thanks, but it doesn't resolve the
> problem
> > either: he MUST copy every property from the original NSButtonCell (font,
> > attributedTitle, imageDimsWhenDisabled, etc).
>
> This is how you will have to do it.
[buttonCellInstance setAlignment:[nsButtonCellInstance alignment]];
With some comments the code has 40 lines, and I copied only what I thought
it will be useful.
This is the solution for the moment. Solution A (see below).
> Or you could write a wrapper,
> although NSButtonCell has a lot of methods. You'll probably want to
> intimately understand NSProxy and how messages work in Obj-C.
NSProxy
"A concrete subclass must therefore provide an initialization or creation
method and override the forwardInvocation: and methodSignatureForSelector:
methods to handle messages that it doesn't implement itself."
methodSignatureForSelector:
Does this mean that I have to write some 100 functions ? Or declare a big
array of function (selector :)) names and wrap it (somehow) in a dictionary
?
This sounds like madness.
>
>
> Cocoa doesn't have a copy constructor design pattern, because one is
> not generally required. This isn't that usual. Java doesn't mandate
> one either.
>
> > He could use copyWithZone (or,
> > better, memcpy) , but maybe there's a pointer there, that will be used
> after
> > some copy is destroyed :((
>
> No, you can't use copyWithZone:. It will never do what you want.
> Looking back at your code, I think you misunderstand how zones work. A
> zone is not a block of memory, but a collection of regions of memory
> that blocks are/can be allocated from. They're heaps.
Thanks for copyWithZone: observation, what I did was a gross mistake.
>
>
> Besides, shallow copying is only a concern if you are subclassing. If
> you're using representedObject plus a bunch of category methods, then
> you will never have to worry about copyWithZone. Remember,
> representedObject is an ivar that NSCell is aware of. If it *didn't*
> properly handle representedObject in its implementation of
> copyWithZone:, then that's a serious bug of NSCell, not your code.
>
> Still, it would probably be a good idea to make sure your
> representedObject itself conforms to copyWithZone in a sane way. Also,
> supporting NSCoding would be a good idea.
"Note that if you copy an NSCell instance, the represented object in the
copy is set to nil."
Ok, let's say I write my own version of 'copyWithZone', but what code should
be there ? The one from the solution A ?
Supporting and using NSCoding make sense only if NSButtonCell supports it.
It seems NSButtonCell doesn't help me at all.
>
>
> > My high-level goal:
> > "he wants an Objective-C equivalent to a C++ copy constructor"
>
> You need to go a little higher. WHY do you need a C++ copy
> constructor? You talk about someone modifying your nib in IB. Why is
> someone doing this w/o understanding the class hierarchy of your
> application?
>
That's another story, but shortly
I have a dream ... to separate the interface from implementation.
Visual Studio story: move the button a pixel to left, align some statics to
the right. It's not easy to have the interface clear from the start, so it's
frustrating for both the designer and the programmer.
In my opinion this is one of the reasons for which the Interface Builder
isn't part of XCode. IB 3 can even lock some parts of the interface.
That's why 1) I want to export as little as possible in IB 2) I want the
prototypes: you don't have to simulate the application to see how the
buttons will look.
Now, after the Cocoa experience, I have to consider two other solutions: 1)
HTML (WebKit) 2) wxLua.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden