creating classes on the fly ??

  • Hi All,

    I'm trying to look ahead to features of Cocoa I don't know about and
    was hoping I could get pointers on which way to go. My ultimate goal
    is to parse a large linguistic corpus using lexicons so I can analyze
    the vocabulary used. I guess that means being able to load large
    lexicons into memory so the corpus can be checked against the lexicons.

    I've created an interface for loading the lexicons, but need to
    decide how to store the data. Ideally, I could use an interface to
    describe the data structure to my program....but that leads to a key
    question....

    *** Is it possible to define the details of a class dynamically?

    For example, let's say I use the generic parser to parse lexicon flat
    files having different data structures. Is there any way in Cocoa to
    create the class and describe the type and number of instance
    variables dynamically?

    Or should I really be looking into Core Data instead?

    Thanks.

    Daniel
  • On Sep 21, 2007, at 4:23 PM, Daniel Child wrote:

    > *** Is it possible to define the details of a class dynamically?
    >
    > For example, let's say I use the generic parser to parse lexicon
    > flat files having different data structures. Is there any way in
    > Cocoa to create the class and describe the type and number of
    > instance variables dynamically?
    >

    Yes.  That's how tools like RubyCocoa  and PyObjC can interact with
    Objective-C code.

    see

    http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Ref
    erence/reference.html


    There are two things to note, however.  First the mechanism could
    change between releases of the OS.  In particular, there is evidence
    to suggest that it will change somewhat in Leopard (though I suspect
    it will become easier to do in Leopard than it is in Tiger).

    Scott
  • On 21.09.2007, at 23:23, Daniel Child wrote:
    >
    > For example, let's say I use the generic parser to parse lexicon
    > flat files having different data structures. Is there any way in
    > Cocoa to create the class and describe the type and number of
    > instance variables dynamically?
    >
    > Or should I really be looking into Core Data instead?

    Either that or "standard" data containers like NSDictionary, NSSet et
    al.
    For interconnected trees (graphs) you may need to add unique id
    elements for any C pointersand resolve them after loading.
  • As the lexicons and corpus data get large (say up to half a million
    or even a million records), are the "standard" data containers going
    to pose performance problems?

    On Sep 22, 2007, at 3:05 AM, Thomas Engelmeier wrote:

    >
    > On 21.09.2007, at 23:23, Daniel Child wrote:
    >>
    >> For example, let's say I use the generic parser to parse lexicon
    >> flat files having different data structures. Is there any way in
    >> Cocoa to create the class and describe the type and number of
    >> instance variables dynamically?
    >>
    >> Or should I really be looking into Core Data instead?
    >
    > Either that or "standard" data containers like NSDictionary, NSSet
    > et al.
    > For interconnected trees (graphs) you may need to add unique id
    > elements for any C pointersand resolve them after loading.
  • On 9/22/07, Thomas Engelmeier <te-work-list...> wrote:
    >
    > On 21.09.2007, at 23:23, Daniel Child wrote:
    >>
    >> For example, let's say I use the generic parser to parse lexicon
    >> flat files having different data structures. Is there any way in
    >> Cocoa to create the class and describe the type and number of
    >> instance variables dynamically?
    >>
    >> Or should I really be looking into Core Data instead?
    >
    > Either that or "standard" data containers like NSDictionary, NSSet et
    > al.
    > For interconnected trees (graphs) you may need to add unique id
    > elements for any C pointersand resolve them after loading.

    Or, and I know this is kind of controversial on this list but i'll
    write it anyway, use C++ and the STL and Boost for your more complex
    data structures. Cocoa and it's (limited) collection classes are
    certainly not the answer for all problems but since the foundation is
    C or C++ based it gives you the freedom to mix and match many cool
    libraries.

    S.
  • Am 22.09.2007 um 15:52 schrieb Daniel Child:

    > As the lexicons and corpus data get large (say up to half a million
    > or even a million records), are the "standard" data containers going
    > to pose performance problems?

    EVERY container will pose an performance problem with 1 Mega entries
    and an inappropriate algorithm.

    I'd recommend to write an tiny prototype that generates some
    arbitrary, random dataset and profiles your typical data access
    pattern (search 100 entries). Profile should include timing and
    memory, as soon your app starts swapping you have an immense
    performance hit.

    - Cocoa data structures -> easiest to use, might be inefficient
    - C++ std:: data structures -> no serialisation buildt in, beware
    std::string is not Unicode-Savy
    - Core Data -> Even with an far higher abstraction layer it might be
    faster due to under-the-hood paging out of unused entries.

    Regards,
    Tom_E
  • On 9/22/07, Thomas Engelmeier <te-work-list...> wrote:
    >
    > Am 22.09.2007 um 15:52 schrieb Daniel Child:
    >
    >> As the lexicons and corpus data get large (say up to half a million
    >> or even a million records), are the "standard" data containers going
    >> to pose performance problems?
    >
    > EVERY container will pose an performance problem with 1 Mega entries
    > and an inappropriate algorithm.
    >
    > I'd recommend to write an tiny prototype that generates some
    > arbitrary, random dataset and profiles your typical data access
    > pattern (search 100 entries). Profile should include timing and
    > memory, as soon your app starts swapping you have an immense
    > performance hit.

    I would actually recommend to do a prototype in Python just to
    understand the algorithms involved. You will also be 10x more
    productive in Python since text processing is so much easier.

    > - Cocoa data structures -> easiest to use, might be inefficient
    > - C++ std:: data structures -> no serialisation buildt in, beware
    > std::string is not Unicode-Savy

    You forgot to mention: crazy fast. Also, std::wstring will deal with
    unicode just fine and Boost can provide serialization. If required.

    > - Core Data -> Even with an far higher abstraction layer it might be
    > faster due to under-the-hood paging out of unused entries.

    I doubt it. The OPs use case sounds like a bad match for Core Data
    actually. It is absolutely fine for doing structured queries but
    analyzing parsed data that you have in memory in some handy data
    structures is one of those things that maps terrible to that model.

    S.
  • On 22.09.2007, at 17:18, Stefan Arentz wrote:
    > You forgot to mention: crazy fast. Also, std::wstring will deal with
    > unicode just fine and Boost can provide serialization. If required.

      wstring does UTF32 now?? Wow! I didn't know that.

      I thought it still used 2-byte quantities and thus still worked on
    the wrong level, sometimes giving you the middle of a decomposed
    character sequence. Anyway, one would still have to normalize
    strings, because I'm sure wstring's compare routines will consider
    "ä" (lowercase 'A' umlaut) and a¨ (a followed by diaeresis as a
    decomposed sequence) to be different.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • On 9/22/07, Uli Kusterer <witness.of.teachtext...> wrote:
    > On 22.09.2007, at 17:18, Stefan Arentz wrote:
    >> You forgot to mention: crazy fast. Also, std::wstring will deal with
    >> unicode just fine and Boost can provide serialization. If required.
    >
    > wstring does UTF32 now?? Wow! I didn't know that.
    >
    >
    > I thought it still used 2-byte quantities and thus still worked on
    > the wrong level,

    wchar_t has always been 32-bit on MacOSX.

    > sometimes giving you the middle of a decomposed
    > character sequence.

    32-bit vs. 16-bit has nothing to do with this, you can still
    incorrectly break a decomposed character sequence in UTF-32 just as
    easily as in UTF-16. The difference is, of course, in surrogate pairs.

    > Anyway, one would still have to normalize
    > strings, because I'm sure wstring's compare routines will consider
    > "ä" (lowercase 'A' umlaut) and a¨ (a followed by diaeresis as a
    > decomposed sequence) to be different.

    Indeed, but for simple storage of the string, wstring is quite sufficient.

    --
    Clark S. Cox III
    <clarkcox3...>
  • On 22.09.2007, at 20:03, Clark Cox wrote:

    > I thought it still used 2-byte quantities and thus still worked on
    >> the wrong level,
    >
    > wchar_t has always been 32-bit on MacOSX.

    ... bloating the memory requirement probably by 3.8 for 1.000.000
    entities for the OP's problem. Which might make the difference
    between a heavy swapping and a fast application.

    >> Anyway, one would still have to normalize
    >> strings, because I'm sure wstring's compare routines will consider
    >> "ä" (lowercase 'A' umlaut) and a¨ (a followed by diaeresis as a
    >> decomposed sequence) to be different.
    >
    > Indeed, but for simple storage of the string, wstring is quite
    > sufficient.

    Only for storage. But not for comparision and case-insensitive or
    diacritic-aware search.
    YMMV - while I've build quite some (international savy) apps based
    on std::basic_string, I'm not sure it is the best choice here.
  • On 22 Sep 2007, at 16:18, Stefan Arentz wrote:

    > Also, std::wstring will deal with unicode just fine

    If you think that, you probably want to read the recent thread about
    wchar_t
    on the xcode-users list.

    wchar_t and things derived from it (i.e. wstring) are not a good choice
    for Unicode.

    NS/CFString is a good choice on Mac OS X, and CFString is (to an extent)
    portable via CF Lite.  If you need more portability, or a C++ interface,
    ICU is the way to go.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • Wow, interesting suggestion. I have never used Python, but I will
    look into. I have to say that I find working with strings in Obj-C
    very tedious. Even my prototype Lexicon using NSDictionary doesn't
    seem to work, as I fill it with one set of values, and when I search,
    it returns something different than what I was searching for. If
    Python could make things easier, that would be great.

    When you say "OP" you mean "Object-Predicate"? I don't understand
    your meaning when you say Core Data would be a bad match for storing
    lexical data....

    > On 9/22/07, Thomas Engelmeier <te-work-list...> wrote:
    >

    > I would actually recommend to do a prototype in Python just to
    > understand the algorithms involved. You will also be 10x more
    > productive in Python since text processing is so much easier.
    >
    >> - Cocoa data structures -> easiest to use, might be inefficient
    >> - C++ std:: data structures -> no serialisation buildt in, beware
    >> std::string is not Unicode-Savy
    >
    > You forgot to mention: crazy fast. Also, std::wstring will deal with
    > unicode just fine and Boost can provide serialization. If required.
    >
    >> - Core Data -> Even with an far higher abstraction layer it might be
    >> faster due to under-the-hood paging out of unused entries.
    >
    > I doubt it. The OPs use case sounds like a bad match for Core Data
    > actually. It is absolutely fine for doing structured queries but
    > analyzing parsed data that you have in memory in some handy data
    > structures is one of those things that maps terrible to that model.
    >
    > S.
  • Well, my issue will be storing Japanese and Chinese data. So I guess
    my question is simply whether this discussion affects me if I use
    Python....

    On Sep 22, 2007, at 2:03 PM, Clark Cox wrote:

    > On 9/22/07, Uli Kusterer <witness.of.teachtext...> wrote:
    >> On 22.09.2007, at 17:18, Stefan Arentz wrote:
    >>> You forgot to mention: crazy fast. Also, std::wstring will deal with
    >>> unicode just fine and Boost can provide serialization. If required.
    >>
    >> wstring does UTF32 now?? Wow! I didn't know that.
    >>
    >>
    >> I thought it still used 2-byte quantities and thus still worked on
    >> the wrong level,
    >
    > wchar_t has always been 32-bit on MacOSX.
    >
    >> sometimes giving you the middle of a decomposed
    >> character sequence.
    >
    > 32-bit vs. 16-bit has nothing to do with this, you can still
    > incorrectly break a decomposed character sequence in UTF-32 just as
    > easily as in UTF-16. The difference is, of course, in surrogate pairs.
    >
    >> Anyway, one would still have to normalize
    >> strings, because I'm sure wstring's compare routines will consider
    >> "ä" (lowercase 'A' umlaut) and a¨ (a followed by diaeresis as a
    >> decomposed sequence) to be different.
    >
    > Indeed, but for simple storage of the string, wstring is quite
    > sufficient.
    >
    >
    > --
    > Clark S. Cox III
    > <clarkcox3...>
  • please take me off this fucking email list you malcom prick

    On 9/22/07, Thomas Engelmeier <te-work-list...> wrote:
    >
    > On 21.09.2007, at 23:23, Daniel Child wrote:
    >>
    >> For example, let's say I use the generic parser to parse lexicon
    >> flat files having different data structures. Is there any way in
    >> Cocoa to create the class and describe the type and number of
    >> instance variables dynamically?
    >>
    >> Or should I really be looking into Core Data instead?
    >
    > Either that or "standard" data containers like NSDictionary, NSSet et
    > al.
    > For interconnected trees (graphs) you may need to add unique id
    > elements for any C pointersand resolve them after loading.
    >
  • Sorry for basic questions, but I've never looked  into using an
    alternate language like Python. Would I be able to make C-language
    Carbon calls as well, all from within the same project?

    On Sep 26, 2007, at 1:17 PM, Nir Soffer wrote:

    >
    > On Sep 26, 2007, at 18:34, Daniel Child wrote:
    >
    >> Wow, interesting suggestion. I have never used Python, but I will
    >> look into. I have to say that I find working with strings in Obj-C
    >> very tedious. Even my prototype Lexicon using NSDictionary doesn't
    >> seem to work, as I fill it with one set of values, and when I
    >> search, it returns something different than what I was searching
    >> for. If Python could make things easier, that would be great.
    >
    > Can you show example code that does not seem to work?
    >
    > Python will make your code much shorter. For example, instead of
    >
    > NSMutableDictionary *d = [NSMutableDictionary
    > dictionaryWithObjectsAndKeys:
    > [NSNumber numberWithUnsignedInt:1], @"key", nil];
    >
    > NSNumber *n = [d objectForKey:@"key"];
    > if (n) {
    > // do something with n
    > }
    >
    > You can write:
    >
    > d = {'key': 1}
    > if 'key' in d:
    > # do something with d['key']
    >
    >>
    >> When you say "OP" you mean "Object-Predicate"? I don't understand
    >> your meaning when you say Core Data would be a bad match for
    >> storing lexical data....
    >
    > He meant Original Poster :-)
    >
    > Why do you need to create classes on the fly?
    >
    >
    > Best Regards,
    >
    > Nir Soffer
    >
  • On Sep 26, 2007, at 12:50 PM, Daniel Child wrote:

    > Sorry for basic questions, but I've never looked  into using an
    > alternate language like Python. Would I be able to make C-language
    > Carbon calls as well, all from within the same project?

    Just speculating here, never having done it myself, but tools like
    PyObjc, in spite of having Objective-C in the name, allow you to
    communicate with application frameworks on Mac OS X through Python.
    Those same frameworks contain C routines as part of their interfaces
    so it makes sense that (through some mechanism) you should be able to
    call arbitrary C routines from Python.

    Scott
  • On Sep 26, 2007, at 11:12 AM, Scott Thompson wrote:
    > On Sep 26, 2007, at 12:50 PM, Daniel Child wrote:
    >> Sorry for basic questions, but I've never looked  into using an
    >> alternate language like Python. Would I be able to make C-language
    >> Carbon calls as well, all from within the same project?
    > Just speculating here, never having done it myself, but tools like
    > PyObjc, in spite of having Objective-C in the name, allow you to
    > communicate with application frameworks on Mac OS X through Python.
    > Those same frameworks contain C routines as part of their interfaces
    > so it makes sense that (through some mechanism) you should be able
    > to call arbitrary C routines from Python.

    If you can wait until Leopard ships, Leopard includes the
    BridgeSupport stuff and a version of PyObjC that fully embraces
    BridgeSupport.  This will also be migrated back to the public
    Subversion repository and should not be terribly hard to retarget to
    Tiger.  (Note also that Leopard includes Objective-C 2.0 which, as
    its name implies, is a vast step forward over previous versions.  As
    the name implies, the underpinnings have changed, including the
    runtime's API.  It is much much better, but the details are still
    covered under NDA.)

    RubyCocoa for Tiger uses BridgeSupport now.

    With BridgeSupport, it makes it quite easy for something like
    RubyCocoa or PyObjC to call into most API on the system, not just
    Objective-C and without requiring hand written wrapper functions.

    HOWEVER, getting back to the original posters question, I don't think
    that using either Ruby or Python to gain dynamic class generation is
    really going to be that terribly useful.    From my rather ignorant
    position of only casually following this thread, I'm not sure that
    dynamic class generation is an appropriate solution.  It could be
    done, but I don't see an advantage over creating a set of classes that
    effectively model whatever it is you are trying to model.  That can be
    quite dynamic and creating generic, dynamic, containers can vastly
    simplify lots of things (archival, for example).  This is exactly
    what CoreData does with NSManagedObject and entities -- you don't need
    to subclass NSManagedObject to store a particular entity.

    b.bum
  • On 26 Sep 07, at 10:50, Daniel Child wrote:
    > Sorry for basic questions, but I've never looked  into using an
    > alternate language like Python. Would I be able to make C-language
    > Carbon calls as well, all from within the same project?

    Yes. If you've got Python 2.5*, you get a really neat module called
    'ctypes' which lets you load arbitrary frameworks and use functions
    from them:

       >> import ctypes
       >> Carbon = ctypes.CDLL('/System/Library/Carbon.framework/Carbon')
       >> Carbon.SysBeep(0)

    Setting up arguments and return types takes a little legwork, but all
    the basics are there.

    * ctypes is available under earlier versions of Python as well,
    actually - it's just not part of the standard distribution until 2.5.
  • > When you say "OP" you mean "Object-Predicate"?

    It means "original poster", you in this case.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.killerbytes.com/
    (303) 722-0567 voice
  • My prototype simply uses NSSet and NSDictionary, but that is so I can
    work out other issues.

    I'd rather avoid C++ if I can.

    You seem to be recommending Core Data, though others are recommending
    Python. Are they either or? I thought Python would replace Obj-C
    syntax, whereas Core Data provides a chance to use data structures
    Apple provides.

    I've read a little about Core Data but am still not that clear on
    what happens when you use it.

    On Sep 22, 2007, at 11:07 AM, Thomas Engelmeier wrote:

    >
    > Am 22.09.2007 um 15:52 schrieb Daniel Child:
    >
    >> As the lexicons and corpus data get large (say up to half a
    >> million or even a million records), are the "standard" data
    >> containers going to pose performance problems?
    >
    > EVERY container will pose an performance problem with 1 Mega
    > entries and an inappropriate algorithm.
    >
    > I'd recommend to write an tiny prototype that generates some
    > arbitrary, random dataset and profiles your typical data access
    > pattern (search 100 entries). Profile should include timing and
    > memory, as soon your app starts swapping you have an immense
    > performance hit.
    >
    > - Cocoa data structures -> easiest to use, might be inefficient
    > - C++ std:: data structures -> no serialisation buildt in, beware
    > std::string is not Unicode-Savy
    > - Core Data -> Even with an far higher abstraction layer it might
    > be faster due to under-the-hood paging out of unused entries.
    >
    > Regards,
    > Tom_E
    >
  • Sorry, I missed this email as it went to an unexpected folder.

    You suggest that creating a class on the fly can be done. Since the
    set of classes would be infinitely variable, but in each individual
    case, it could be determined by interpreting data that is read in, or
    a description file format I plan to use, then creating classes on the
    fly (if reasonably trouble-free) would be desirable in my case.

    Maybe just for starters, are there methods like "create new class",
    "add instance variable of type X", etc. I would be really surprised,
    but it could be useful to me. Thanks.

    On Sep 26, 2007, at 2:27 PM, Bill Bumgarner wrote:

    > HOWEVER, getting back to the original posters question, I don't
    > think that using either Ruby or Python to gain dynamic class
    > generation is really going to be that terribly useful.    From my
    > rather ignorant position of only casually following this thread,
    > I'm not sure that dynamic class generation is an appropriate
    > solution.  It could be done, but I don't see an advantage over
    > creating a set of classes that effectively model whatever it is you
    > are trying to model.  That can be quite dynamic and creating
    > generic, dynamic, containers can vastly simplify lots of things
    > (archival, for example).  This is exactly what CoreData does with
    > NSManagedObject and entities -- you don't need to subclass
    > NSManagedObject to store a particular entity.
  • From your link, I can see that in theory, at least, that class
    creation could be done, though it looks very involved. I didn't see
    how you would do methods, though. I think for now I will stick to a
    prototype with built-in classes, and will consider this issue again
    when I am less of a novice.

    Thanks for the link.

    On Sep 21, 2007, at 5:32 PM, Scott Thompson wrote:

    >
    > On Sep 21, 2007, at 4:23 PM, Daniel Child wrote:
    >
    >> *** Is it possible to define the details of a class dynamically?
    >>
    >> For example, let's say I use the generic parser to parse lexicon
    >> flat files having different data structures. Is there any way in
    >> Cocoa to create the class and describe the type and number of
    >> instance variables dynamically?
    >>
    >
    > Yes.  That's how tools like RubyCocoa  and PyObjC can interact with
    > Objective-C code.
    >
    > see
    >
    > http://developer.apple.com/documentation/Cocoa/Reference/
    > ObjCRuntimeRef/Reference/reference.html
    >
    > There are two things to note, however.  First the mechanism could
    > change between releases of the OS.  In particular, there is
    > evidence to suggest that it will change somewhat in Leopard (though
    > I suspect it will become easier to do in Leopard than it is in Tiger).
    >
    > Scott
    >
  • Well i was wondering why one would want to create classes on the
    fly...i mean, there may be reasons for this, but i don't think that
    storing data could be the reason to do this. Besides Cocoa i'm
    developing with Smalltalk a lot and there're it is no problem to
    create classes and to compile methods dynamically, but there're really
    not many reasons why you would want to do this. I created classes and
    methods on the fly in order to store information using a source code
    management system, but besides this reason i don't see much advantage
    against storing data in some model classes that are good enough to
    handle all the data you would want to store. I think code data may do
    a big deal in helping you out there.

    Another thing is that i don't know how you are going to debug the
    stuff that you are creating on the fly?! i mean... if you have the
    classes, and the methods (however you compile them at runtime in
    cocoa), how do you want to debug the execution of these methods?

    just my 2++ct

    Karsten

    Am 04.10.2007 um 16:13 schrieb Daniel Child:

    > From your link, I can see that in theory, at least, that class
    > creation could be done, though it looks very involved. I didn't see
    > how you would do methods, though. I think for now I will stick to a
    > prototype with built-in classes, and will consider this issue again
    > when I am less of a novice.
    >
    > Thanks for the link.
    >
    > On Sep 21, 2007, at 5:32 PM, Scott Thompson wrote:
    >
    >>
    >> On Sep 21, 2007, at 4:23 PM, Daniel Child wrote:
    >>
    >>> *** Is it possible to define the details of a class dynamically?
    >>>
    >>> For example, let's say I use the generic parser to parse lexicon
    >>> flat files having different data structures. Is there any way in
    >>> Cocoa to create the class and describe the type and number of
    >>> instance variables dynamically?
    >>>
    >>
    >> Yes.  That's how tools like RubyCocoa  and PyObjC can interact with
    >> Objective-C code.
    >>
    >> see
    >>
    >> http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Ref
    erence/reference.html

    >>
    >> There are two things to note, however.  First the mechanism could
    >> change between releases of the OS.  In particular, there is
    >> evidence to suggest that it will change somewhat in Leopard (though
    >> I suspect it will become easier to do in Leopard than it is in
    >> Tiger).
    >>
    >> Scott
    >>

    >
    >
  • On 10/4/07, Karsten <karsten...> wrote:
    > Well i was wondering why one would want to create classes on the
    > fly...i mean, there may be reasons for this,

    The main reason that I can think of to do this is when making a bridge
    of sorts between Cocoa and another language. For instance, I once did
    just this when wrapping a C++ introspection framework to allow it to
    be used with Cocoa bindings. When my bridge was connected to a C++
    class registered with this framework, it would synthesize an
    Objective-C class that had named accessor methods that would call
    through to the appropriate C++ accessors on the wrapped object.

    > but i don't think that
    > storing data could be the reason to do this. Besides Cocoa i'm
    > developing with Smalltalk a lot and there're it is no problem to
    > create classes and to compile methods dynamically, but there're really
    > not many reasons why you would want to do this. I created classes and
    > methods on the fly in order to store information using a source code
    > management system, but besides this reason i don't see much advantage
    > against storing data in some model classes that are good enough to
    > handle all the data you would want to store. I think code data may do
    > a big deal in helping you out there.
    >
    > Another thing is that i don't know how you are going to debug the
    > stuff that you are creating on the fly?! i mean... if you have the
    > classes, and the methods (however you compile them at runtime in
    > cocoa), how do you want to debug the execution of these methods?

    Depending on how you construct the class, debugging them is not really
    that different from debugging any other class. Most of the methods on
    the classes in my bridge shared a few common method implementations
    (i.e. one implementation for a getter that returns an int, another for
    a getter that returns an object, another for a setter that takes a
    float, etc.). The debugger had no problem stopping at breakpoints
    placed within those implementations.

    --
    Clark S. Cox III
    <clarkcox3...>
previous month september 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today