Fwd: resetting ivars safely

  • forgot to cc the list, apologies

    Begin forwarded message:

    > From: Daniel Child <wchild...>
    > Date: September 13, 2007 11:17:37 AM EDT
    > To: Uli Kusterer <witness.of.teachtext...>
    > Subject: Re: resetting ivars safely
    > Interesting. I am wondering about the relation of what I'm
    > designing to the MVC. My model will have various classes, but some
    > of them do not want to be torn down and rebuilt each time as a lot
    > of data (thousands of records) will need to be imported or
    > initialized each time. Since the parser will be working more or
    > less constantly, tearing it down and rebuilding it each time new
    > data comes in seems wasteful.
    > Let's say I have an "Input Controller" which works with a GUI of
    > some kind to handle input. Does it not make sense for the Input
    > Controller to have instance variables which constitute
    > representatives of the main model components. These components
    > could be things like Lexicon, MorphologicalBoundaryFinder,
    > InputExaminer, WordParser, WordFinder, etc. (I haven't totally
    > decided because at this point I'm simply learning to do the
    > programming generally.)
    > Entries in the lexicon would naturally have thousands of individual
    > objects (Words or whatever), but why bother destroying and
    > recreating the others when you simply need to reinitialize some
    > values each time you handle new input? In the case of lexicons,
    > reimporting thousands and thousands of records makes no sense. OOP
    > doctrine or not, it seems wasteful.
    > At this point, the key is to get a feel for proper memory
    > management idioms so I can focus on other things. Which brings me
    > to your other email.
    > Thanks for this comment.
    > On Sep 13, 2007, at 5:02 AM, Uli Kusterer wrote:
    >> On 13.09.2007, at 03:12, Daniel Child wrote:
    >>> It makes sense for it to be a singleton. It will eventually be
    >>> interfacing with a component. And there is no need for "lots of
    >>> them." The same "machine" processes streams of words one set at a
    >>> time. No need to create a new machine for each set of data. I am
    >>> simply clearing fields that store input or that store output
    >>> temporarily.
    >> Don't confuse objects in an OOP language with real-world,
    >> physical objects: An object in OOP is simply a combination of data
    >> (=state) and actions that modify this data. Hence, if you find you
    >> need to replace 90% of the data, you might as well tear down and
    >> recreate the object. That way, you don't duplicate clean-up code
    >> and risk it going out of sync, and even if you have a -cleanUp
    >> method that's called both by -reset and -dealloc, it's still two
    >> separate code paths that may diverge by accident.
    >> If you have some hardware you're interfacing to, it may help to
    >> have separate objects for state and actual hardware control. All
    >> state objects would share the same hardware controller, but would
    >> nonetheless be separate. However, one can also over-engineer
    >> things, and you didn't give enough information to say for certain
    >> in your case. *In general*, you don't have objects that can be
    >> reset in OOP, and instead you create new objects (the performance
    >> implications are minimal, and if you find your case is different,
    >> *after profiling*, then you can always refactor the design).
    >> Cheers,
    >> -- M. Uli Kusterer
    >> http://www.zathras.de
previous month september 2007 next month
          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