On Tue, 5 Jun 2001, Alan F. Larimer, Jr. wrote:
> > Not necessarily. You might want to have your instance method do something
> > different when used in a list context versus being used in a scalar
> > context. If you used a reference, the user of your class would have to do
> > some funny things to go into a list context versus a scalar context. If
> > you let your method handle that, the user of your class will be happier.
>
> Whether it's a scalar, array, etc . . . if you return a reference, the class
> user has to dereference it. So for style's sake, wouldn't you want to keep it
> consistent. Still, there are the memory usage and speed issues. (I imagine
> their really isn't much of an issue, but I'd still like to have an idea.)
It's really no different than functions like split or keys that return
different values depending on their context (see the perldoc on
'wantarray'). To force the user to go through convolutions of
dereferencing an array reference makes the object interface more complex
and, as I said before, is not always necessary. If you are returning
complex data structures, that's a different story -- you do want to use
references when passing data in and out of functions and methods.
> So, for example (from perltoot again) . . .
> I have a Person class that saves (amoung other things) name and peers. I
> create the object and push it onto an array in package main. When I remove
> (pop, shift, or indexing) the object from that main array, the DESTROY is
> automatically called and decrements the class variable of population. Correct?
Unless you happen to save that popped array element into a variable...
then it doesn't get destroyed. Only when the last reference to that
object goes away (goes out of scope or whatever) will the DESTROY method
be called. You can call it explicitly, but it's usually not recommended.
-- Brett
Brett W. McCoy
Software Engineer
Broadsoft, Inc.
240-364-5225
[EMAIL PROTECTED]
