• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Questions about class hiearchy and PB targets.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Questions about class hiearchy and PB targets.


  • Subject: Questions about class hiearchy and PB targets.
  • From: James Quick <email@hidden>
  • Date: Thu, 10 Jul 2003 09:19:01 -0400

I am implementing a framework to automate access to MachO information.
The framework contains classes for reading and parsing the struct mach_header
information, which subsequently parses all the MachO Load commands.

My class hiearchy is
MachHeader : NSObject
LoadCommand: NSObject
SegmentCommand: LoadCommand
SymTabCommand: LoadCommand
......
A subclass for each load command.
Section: SegmentCommand

Each instance holds a const struct .... * pointer to it's underlying data.
Each also defines accessor methods to return the field values from its struct.

Since there are 18 subclasses, some of which have the same underlying data
The C side of me thinks I should perhaps refactor my classes into fewer objects
and implement consistency logic in the accessor methods. I could thus
check the current load command type from the structure to determine
what to return or whether to raise an error. The benefits here would be
smaller code size, and moving from about 22 classes to 3 or 4.

The (less experienced) Objective-C side of me, says to retain the large number of
classes, since each of them independently implements all the required state
without further introspection or calculation. The benefit here is simplicity
of the code generator and transparency of the interface. Each class represents
a specific thing which maps to the outer world. (I'm currently leaning towards this.)

Since, I was concerned first with correctness, and with the impending changes
I suspect in Panther, I did not write the classes myself. I instead wrote a perl
framework to parse the mach-o/loader.h file, and generate all the parsing logic,
instance variables, and methods for the collection of classes.

I have a second question about the organization of projects. I'm designing
a fairly complex toolset with a number of well demarcated sets of functionality.
Thus, I have chosen to implement each zone of responsibility as a separate framework.
When implementing a framework I want to maintain a test harness to excercise
the framework as I go along, but do not want it to be included in the deployed
products.

In this Framework project, I added a second target, which links against the
locally built copy of the framework. What I don't like, is that this secondary
target cannot force a rebuild of the framework when I change a framework
method during debugging. I do like having it listed in a seperate target,
because that is what it is. If I were doing this with Make I would simply
add a dependency to rebuild the Framework. Is there a way to natively
express inter-target build dependencies, or must I implement a Makefile
or Script phase in the dependent target? Would this be as simple as
as "sh -c pbxbuild -target ParentTarget".

Thanks in advance.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Prev by Date: Creating Really Big TIFF's
  • Next by Date: same NSPipes for multiple NSTasks
  • Previous by thread: Re: Creating Really Big TIFF's
  • Next by thread: same NSPipes for multiple NSTasks
  • Index(es):
    • Date
    • Thread