Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!eru!luth!sunic!bmc!sys_ms
From: Mats.Sundvall@bmc.uu.se
Newsgroups: comp.sys.mac.programmer
Subject: Re: methods or functions in oo programming
Message-ID: <2621.2531be57@bmc.uu.se>
Date: 10 Oct 89 09:03:03 GMT
References: <2616.252ca3bb@bmc.uu.se> <4606@internal.Apple.COM>
Organization: Biomedical Center, University of Uppsala, Sweden
Lines: 46

In article <4606@internal.Apple.COM>, lsr@Apple.COM (Larry Rosenstein) writes:
> In article <2616.252ca3bb@bmc.uu.se> Mats.Sundvall@bmc.uu.se writes:
> 
> In general, you should avoid examining the fields of an object from 
> outside the object.
> 
>> The other method/function I want to implement is LIGATE. I pass LIGATE
>> two objects of DNA and it assembles these into one object of DNA.
>> Should this be a method or should it be a function.
> 
> This is less clear since the operation involves 2 DNA objects and neither 
> is really dominant (although the ordering seems to matter).  If the 
> operation modifies one of the original DNA objects, then it should 

The problem I had to understand how to implement this "method" was that
it takes two objects and you get one new object that is the sum of the
two original objects. I guess I implement it as a method and pass the
other object to the method. Then I have to dispose that object as it
will not exist anymore.

> definitely be a method.  Even if it doesn't this operation needs to access 
> the internal state of the objects, and should still be a method.
> 
> There is an issue of how the method accesses the state of the second DNA 
> object.  If it accesses the state directly, then it is assuming what the 
> object's class will be.  Otherwise, it should call methods to access the 
> object's state.
> 
> If the operation doesn't change either shape, then you could make it a 
> plain routine.  Making it a method still provides a useful kind of 
> scoping, both in terms of the C function names and in terms of the 
> programmer's understanding.
> 
> 
> 
> Larry Rosenstein, Apple Computer, Inc.
> Object Specialist
> 
> Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
> AppleLink: Rosenstein1
-- 
		Mats Sundvall			

		Biomedical Center		+46/18174583
		University of Uppsala		Mats.Sundvall@BMC.UU.SE
		Sweden				psi%24020019700620::MATS