[Tutor] Function return

Paul Sidorsky paulsid@shaw.ca
Wed, 20 Feb 2002 21:56:17 -0700

Earlier, Paul Hartley wrote:

> However I was trying to get at the records and fields and tried to 
> return the records array from a function because in
> prevous languages I read that it is better to wrap data in a class 
> around a function rather than accessing the data
> directly and my program fell over when I tried to return 
> self.records in the code below (see the function getRecords

Then Kirby Urner wrote:

> A comment on style:  I think using a class to wrap the the
> functionality needed to read some fixed length records is overkill
> in this example.  What you get at the end of the day is a single
> instance containing a list of dictionary instances, which is
> a somewhat exotic data structure.

Agreed, but it's a darn nice way to learn classes.  The main problem
with classes is most people have to write them to learn them, but most
things worthy of classes are too complicated to make learning
practical.  I think I mentioned this some time ago, but forcing yourself
to use classes for a trivial situation is probably the best way to learn

However, implementing things with classes just because one of those
gung-ho Object Oriented Design books tells you it's the only way things
should be done is of course a Very Bad Thing.  OO is not the
end-all-and-be-all of design paradigms, despite what some books try to
get you to believe.  It has its place, but I know from personal
experience than attempting to use it for every little chore is enough to
drive one insane.  (Unless C has warped my mind so much that I already
am insane.)

Personally I have a much easier time understanding a good non-OO
implementation of something then I do with a bad OO implementation of
it.  So if I can't work out how to do something cleanly with OO then I
just don't use it.  Since all of my programs are small- or medium-scale
and I'm the only one working on them, it's not a big deal.  Of course if
you have to write a big program or one that's going to be worked on by a
team then OO will probably make things a lot easier.  Otherwise, use
what you are comfortable with.

Paul Sidorsky                                          Calgary, Canada
paulsid@shaw.ca                        http://members.shaw.ca/paulsid/