in reply to Programming using data structures

I agree with derby. All programming is about how you organize your data. If you organize in structure A, you have to use algorithm A. If you want to use algorithm B, use structure B. A simplistic example of this is when you're figuring out what searching algorithm to use, depending on if your stuff is sorted or quasi-sorted or random or whatever. (CS 101, for those who're wondering why I even care about searching algorithms.)

I have a number of ... nits ... with your Disadvantages section. (Of course, I might be missing something ...)

  1. If your behavior is all bound up in your variables, then you have a lot of switch-type statements. I'd prefer to determine what my general forms of behavior will be, then write objects for them.
  2. Why not do something like: 
    #### Define like:
my %sort_by = (
    ( map { $_ => sub { $a->{$_}{order} <=> $b->{$_}{order} } }
          qw(title subject author isbn)),
};
#### Use like:
    my @titles = sort &{$sort_by{title}} @books;

    [download]
  3. it is usually possible to wrap an OO layer around your data structure.

    There are so many things wrong with that statement I don't know where to begin. OO isn't a "layer". That is a procedural programmer talking who doesn't understand what OO is about. That would be like me, who doesn't do functional programming (and take that as you will), saying that I can just wrap a bunch of closures around my objects and it now got a "functional layer". You don't have re-use, you don't have decomposition, you don't have anything that makes OO programming ... OO.

I also have a bunch of nits with your Advantages, too.
  1. Worry about the capabilities of syntax is a programmer discipline issue. Now, if that's how you enforce your discipline, that's your choice and Perl supports you. But, I hate to see someone limit themselves because they don't want to learn good discipline.
  2. If you use e.g. polymorphism, you may have several method calls to debug.

    Again, a procedural programmer's gripe about OO. You shouldn't be debugging more than one object at a time cause you shouldn't be working on more than one object at a time. If you make changes in too many places between tests, of course you're going to be clueless about where the bug is. If you make one change - test, one change - test ... you'll know with 75% certainty where the bug is because you just changed that piece of code. (The other 25% is if you fixed something that exposed another flaw somewhere else.)

I'm sorry if I sound harsh, but, just as you have your opinion, I have mine. Your post is a good post. I just happen to disagree with it. :-)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Replies are listed 'Best First'.
Re: Re: Programming using data structures
by dash2 (Hermit) on Feb 20, 2003 at 17:35 UTC
    Feel free to disagree, I don't object.

    Yes, you don't want to use switch statements. (Excessively.)

    I know what OO is - a little, at least. Sometimes you want to make an object based on a data structure. It isn't necessarily true that by doing this you forgo the advantages of OO. Often, it is a transitional phase. Having done something quick and dirty, you then add the OO layer. You then hollow out the quick and dirty stuff and replace it with nice OO stuff - all without breaking your code, which has been insulated by the OO layer.

    Syntax isn't just about discipline. It is also about making life easy for yourself. I have been programming for a couple years - but I still regularly forget the semicolon at the end of a statement. Perl's syntax is complex. Using a simple subset can sometimes be good.

    As for the final point... yes, of course you should change just one object at a time. And you should write unit tests for _all_ your code. Hands up everyone who does that all the time. I mentioned this was a "quick and dirty" project.

    dave hj~

[reply]

In Section Meditations