Object oriented language restrictions

Yes, I’m following.

I’ve actually coded in C++ ( I now know that ended up in flames as I was trying to learn windows programming and C++ at the same time, a really stupid thing to do when you have NO support system and you are talking about windows 3.1), and there were a number of books that I studied, many times over… trying to remember the titles… seeking… seeking… record not found.

I can understand the deal with encapsulation, inheritance, polymorphism … all that stuff is great, and seems cool, and would help tremendously.

Maybe my problem is I’m expecting too much, and simply making it harder than it really is. I learned my programming skills in the procedural years, and I learned them on the job from some of the brightest people in the industry (not bragging here; but there were some major projects going on in the Navy at the time that were decades ahead of their time; I lucked into being part of them).

Anyway, I guess my point in all that is I think I was (sort of) programming object wise using procedural languages (primarily C and Pascal), as much as is possible; as I was quite a stickler for sticking to clean, well documented code, rewriting a procedure for as many times as needed until it felt right, and was as short and quick as possible.

I can say that one of my MAJOR stumbling blocks with OO is persistence; I’d rate my SQL skills at a 10; but I’ll be damned if I can conceptualize saving an object to disk without the use of anything other than an OODB.

On the other hand, I had teams of developers using everything from Smalltalk to C++ in the 90’s; some used Versant, some other OO products, some mapped to relational and back; they all seemed to completely suck for one reason or another… I don’t know what the current status is, but I’d guess that since Oracle is still around, and OO is still growing… the problem has been solved reasonably.

I can’t really go into examples of where I get tripped up with OO, as after all the years I no longer have questions, only vague feelings of helplessness and frustration; but I’ll be jumping into a rewrite of a system I started developing about 3 years ago in VB, using Java, C++, or one of the .asp variants (Still have a few arch. decisions to make that will dictate the technology to use).

I appreciate your all’s comments and attention here… will be posting questions as I move forward with this.

Thanks again!

Thanks for the references. I pretty much “get” OO stuff, I just find the implementations somewhat vile at times.

i.e.

JTable jt = new JTable(tm);
JScrollPane jsp = new JScrollPane(jt);
getContentPane().add(jsp, BorderLayout.CENTER);

final TableChartPopup tcp = new TableChartPopup(tm);
JButton button = new JButton("Show me a chart of this table");
button.addActionListener(new ActionListener() {
  public void actionPerformed(ActionEvent ae) {
    tcp.setVisible(true);
  }
} );
getContentPane().add(button, BorderLayout.SOUTH);

Yes, well, that’s what happens when you use Java. It’s like trying to write poetry in Morse Code.

You may find something like Objective C, Python, Perl, or Ruby more to your liking.

Perl, yes, yes, yes. I haven’t tried Python or Ruby, but if they are Perl-like, I am sure I will approve of them too.

I used to think this, and I kind of still do, however, after cranking out a small-ish prototype for a web app (around 10k lines, altogether) using the new 1.5/5.0/Tiger SDK, I have a MUCH higher opinion of Java. I’ve managed to use pretty much all the new language features (even annotations! I wrote a tool to automatically generate TLD files from annotations, and altogether it couldn’t have been more then a few hundred lines), and they really add to the language.

Throw in Eclipse, the only IDE I’ve ever used that begins to approach the greatness of my lisp machine’s environment (Genera 8.3 running on a MacIvory II), and it starts to smell somewhat sweet. Not Common Lisp sweet, but sweet nonetheless.

A lot of specifics have been mentioned, but I’d like to mention Ruby as one of the languages that are of fore-front of, shall we say, OO flexibility.

In Ruby, a class is a somewhat loose concept, unlike in C++ and Java where static typing restricts, by design, how code can interact. In these languages, a class is a static thing; once you have declared a class, it stays the same.

In Ruby, a class is mostly a way of assigning functionality, or behaviour if you will, to instances. You can extend existing classes at runtime, and you can even extend individual instances.

For example, Ruby has an Array class. Let’s imagine we would like a function that summed the elements of an array. In static languages, you might define a global function that took an array as its parameter.

In Ruby that would be unidiomatic. Instead we do this:


class Array
  def sum
    inject(0) do |sum, element|
      sum + element.to_i
    end
  end
end

Then we can try it out on the interactive irb prompt:


>> [1, 2, 3].sum
=> 6

This adds the method sum to the Array class and makes it immediately available to all current and future instances.

If the method of adding functionality to existing classes seems dangerous and wild, don’t worry. This is a common reaction, and an unnecessary fear; but in reality, runtime modification has many benefits and very few practical downsides.

In static languages, classes are all about rigidly-defined interfaces – you simply can’t call non-existent methods, or pass the wrong arguments to one. In Ruby, everything is late-binding, and so has the concept of duck typing involved – duck as in “if it walks like a duck, quacks like a duck” etc.; in short, if a class behaves like X and looks looks like X, then it’s fair to say that it’s X, even though it might be implemented by Y.

This means that in Ruby, I can create a new class – which does not descend from Array – that behaves like an array, even though it isn’t one. This makes it easy to write elegant programs around natural idioms; your object is free to act like both an array and a hash table and a file, all using the language’s first-class tools.

This puts Ruby closer to C++, which provides operator overloading, in flexibility, than a language like Java, which adopts a near-pristine model where all operators except string operators are built in and fixed.

As you can see, in Ruby, arrays first-class objects that are instances of the Array class. This is another difference from most static languages. It makes certain constructs very natural; an oft-quoted example is counting:


>> 3.times { puts "Hello world" }
Hello world
Hello world
Hello world

Compare this to for or while loops involving counters. It expresses your intent clearly and succinctly. The above is possible because numbers are objects. You can, of course, add methods to numbers, and some people have done so in their own projects:


>> 5.minutes
300

(That’s 5 minutes expressed in seconds.)

Ruby is a good language.

One example is that Java does not allow multiple inheritance of classes, which is allowed in C++. Java does allow multiple inheritance of interfaces, which would be equivalent to a class with all pure virtual functions in C++.

You might look into PHP 5. Not that it’s “complete”, but by this point in the thread hopefully you see that there’s no “pure” OO approach, just many different ones with different advantages.

Note that I said PHP5, not PHP4… if you’re a Perl fan, PHP4 will make your blood boil in many, many ways. :mad:

If you like Perl you’ll definitely get a kick out of Ruby. Python is like Perl feature-wise but at the opposite end of the spectrum syntax-wise.

“When you write a Ruby program, you concentrate on getting the job done, not on building scaffolding to support the language itself.”

I’m liking Ruby already.

http://www.rubycentral.com