Strange OO Concepts

[ash.gti]

I know just about every OO language has something quirky about its OO implementation. But sometimes there is merit to the way they choose to do it. For instance, Ruby's OO is pretty strange by most standards....

• Objects can only have private variables
• Inherited Objects get all private variables
• Inherited Objects do not get any of the protected class methods.
  This one has to do with the way Ruby handles private/protected/public. In Ruby, public means public like normal. Private means only objects with its self ID can call the method. Protected methods can be called from a class or descendant class instances, but also with another instance as its receiver. The catch is that with this model, protected class methods don't make sense. You can set a class method to protected, but it doesn't actually mean anything given the inheritance model.
  

Also because Ruby uses a message passing system it has a very nice feature of the missing_method function. When a function fails to call it calls that instead, before an error is reported. This gives ruby a great deal of flexibility with dynamic functions.

I am just curious how others feel about, for instance, the way Ruby handles private/protected and what other languages have their OO quirks.

This may not be that big a quirk, but I started OO programming in C++ and this differs vastly from the way C++ handles private and protected methods.

[Micron]

Objects can only have private variables

This is, I think, the right idea. Public variables can expose too much of a class' implementation and cause problems later when you want to deprecate use of a variable, make its access thread safe, or otherwise change the implementation. Of course writing getter and setter methods for everything is overly verbose and tedious so I prefer a language which allows you to expose private variables as properties which can be accessed as if they had getter and setter methods but whose access can be overridden if you want to explicitly control the getter/setter behavior.

As for protected methods I'm still undecided on exactly how I prefer to see protected access used.

[Rysto]

Objects can only have private variables

This is, I think, the right idea. Public variables can expose too much of a class' implementation and cause problems later when you want to deprecate use of a variable, make its access thread safe, or otherwise change the implementation

Yes, but if I'm reading the OP correctly Ruby ruins this by giving derived classes access to private instance variables of base classes.

[Micron]

Yes, but if I'm reading the OP correctly Ruby ruins this by giving derived classes access to private instance variables of base classes.

I think that's a slightly different issue and trade-off. I was thinking about cases where some other block of code is using but not extending the class I'm working on and in that case not using public variables increases my chances of being able to make implementation changes cleanly.
If you're extending a class then I can see an argument being made to allow you to change implementation details by altering private variables or overriding private methods. There are cases when you really want to be able to reuse and modify code like that but it also sounds like a great way to shoot yourself in the foot, hard, repeatedly.

Since the OP seemed to be looking for comments on other OO concepts I'll add that I really like mixins although I'm not yet sure if Ruby is the best implementation. After working in Java for a while I get really tired of copy-pasting method implementations (or calls out to some delegate class) into classes which share an interface. I much prefer being able to say "this class provides this interface using this implementation" efficiently.

[aleflamedyud]

Objects can only have private variables

This is, I think, the right idea. Public variables can expose too much of a class' implementation and cause problems later when you want to deprecate use of a variable, make its access thread safe, or otherwise change the implementation. Of course writing getter and setter methods for everything is overly verbose and tedious so I prefer a language which allows you to expose private variables as properties which can be accessed as if they had getter and setter methods but whose access can be overridden if you want to explicitly control the getter/setter behavior.

As for protected methods I'm still undecided on exactly how I prefer to see protected access used.

Who's to say that some public variables don't get declared with the genuine intent of providing a consistent interface to a piece of information? Seriously, why do the extra computation of calling a function that returns an int from a private variable when you can just read the int?

I've got all my own weird views on how OO should be done. When, God-willing, I get the ear of a professor who'd like to help me, I'm going to make a language that will actually do what I want.

[Micron]

Who's to say that some public variables don't get declared with the genuine intent of providing a consistent interface to a piece of information?

Of course that is the intent unfortunately it is only a matter of time until you find something in your design which has to change for one reason or another. Now if you have to change the actual interface you're screwed either way because regardless of if you're changing a variable or a method anyone depending on the class is going to have to refactor their code in order to use the new version. However it should be possible to change anything about a class' implementation without changing the interface and without forcing everyone relying on your code to rewrite their work as a result.

As for speed; a compiler can inline simple method calls like getters and setters so while some specific environment might see a performance difference I see no reason why that should be the case in general.

[ash.gti]

Since the OP seemed to be looking for comments on other OO concepts I'll add that I really like mixins although I'm not yet sure if Ruby is the best implementation. After working in Java for a while I get really tired of copy-pasting method implementations (or calls out to some delegate class) into classes which share an interface. I much prefer being able to say "this class provides this interface using this implementation" efficiently.

Lots of languages use mixins. Go look at Objective-C for instance. Anything declared in a Category is a mixin. You can do stuff like add methods at run time to a class, or over ride the default functionality of a function. Pretty nice.

Ruby takes mixins a step further though because in Objective-C you can't add instance variables to a class, but in Ruby, your mixins can add varables.

Code: Select all

module SillyModule
  def self.included
    # method is called when the module gets included into anything
    class_eval <<-end_eval
      attr_accessor :blah
    end_eval
  end
  def hello
    "Hello."
  end
end
class SillyClass
  include SillyModule
end

a = SillyClass.new
p a.instance_variables
# prints out ["blah"] which is the only declared variable


If you like Java, have you tried Groovy? Or JRuby? I don't know much about Groovy, other than that it runs on the JVM. I do know that with JRuby you can write ruby code and compile it into a Java .class file. You can even mix normal Java with your Ruby or have Ruby use normal Java.

Yes, but if I'm reading the OP correctly Ruby ruins this by giving derived classes access to private instance variables of base classes.

True, that is one of the reasons I find some of the OO concept's ruby uses as weird. No other OO language I am aware of does this. This one I am not so sure I like, but I do like the way ruby handles private/protected/public methods.

I've got all my own weird views on how OO should be done. When, God-willing, I get the ear of a professor who'd like to help me, I'm going to make a language that will actually do what I want.

Why wait till you get the ear of a professor? If you already know some assembly you could be on your way to building your own language. I'd suggest investing into a book like the Dragon Book (see my sig) or the Blue Book (Smalltalk-80's book on JIT implementations, which is kinda funny because some of the optimizations they used back then are JUST NOW getting implemented in Java, Ruby, Python, etc... anything that uses a JIT system and bytecode compilation)

[aleflamedyud]

Oh, I've got the Dragon Book already. I'd just rather have the help of someone with experience in designing the grammar and syntax (also, I need to work out an issue with memory allocation safety) and get honors/research credit while at it than implement a very simple compiler for a hobby, receive no credit, and find at the end that I should have done something differently.

Also, the Dragon Book spends a bloody huge amount of time going on about parsers rather than genuine linguistic issues.

[Rysto]

Also, the Dragon Book spends a bloody huge amount of time going on about parsers rather than genuine linguistic issues.

In fairness, the Dragon Book is more aimed towards people writing compilers for existing languages than people inventing new languages.

[aleflamedyud]

Also, the Dragon Book spends a bloody huge amount of time going on about parsers rather than genuine linguistic issues.

In fairness, the Dragon Book is more aimed towards people writing compilers for existing languages than people inventing new languages.

Point. And when I mean it spends a lot of time on parsing, I mean that literally two chapters cover lexing and syntactic parsing (200 pages between them), while the authors mixed in semantic analysis with the chapters on intermediate code generation and optimization. I guess they do that because semantic analysis remains an open and healthy research field rather than an established science.

Admittedly, optimization has so far in programming history been the Killer Application of semantic analysis. Behind it, and in current research, comes the proving of desirable theorems about code semantics, which I actually feel is quite important aside from its uses in optimization. For example, without the Hindley-Milner type-inference algorithm we couldn't statically type many highly-polymorphic functional programming languages. We'd end up with programmers declaring variant types to get around the annotation-fueled type system instead of letting the inference engine Do What I Mean.

To someone looking to make a new language, all of this research into semantics looks like a treasure chest because we can design a new language to use certain theorem-proving algorithms as language features.

[ash.gti]

So what OO concepts would you change or how would you like to see them work?

Of course, it'd be nice to hear your justification for your differences. If you read through some of the Ruby email lists you can hear from Matz (the designer of Ruby) why he did things the way he did. It has to do with the fact that Ruby doesn't have predefined variables. So, in your ruby classes you don't define any variables at all because they are all added at run-time. You can declare accessors, which create a variable of the scope you declared, but they aren't really added to the class till they are run.

*edit*

If building a whole compiler/language from scratch is a bit much you could always use an existing system, like the LLVM, to tie into then you'd just have to write the parser that converts your source into LLVM byte code, which can then convert it to C and to a standard executable. Or you could write your language for yacc/bison and have it build the compilable.

I still don't see why you cant start out building out your concepts of syntax and the like. Any professor is much more likely to listen if you have actually put enough thought to be able to sketch out a basic BNF or explanation as to why you want to do this. I knew people that did things like that in college and got research grants for doing it, but they put for the effort and took the initiative.

[aleflamedyud]

So what OO concepts would you change or how would you like to see them work?

Of course, it'd be nice to hear your justification for your differences. If you read through some of the Ruby email lists you can hear from Matz (the designer of Ruby) why he did things the way he did. It has to do with the fact that Ruby doesn't have predefined variables. So, in your ruby classes you don't define any variables at all because they are all added at run-time. You can declare accessors, which create a variable of the scope you declared, but they aren't really added to the class till they are run.

Generic functions and multimethods. They're just far more useful, in my experience, than Smalltalk-style classes with methods attached.

*edit*

If building a whole compiler/language from scratch is a bit much you could always use an existing system, like the LLVM, to tie into then you'd just have to write the parser that converts your source into LLVM byte code, which can then convert it to C and to a standard executable. Or you could write your language for yacc/bison and have it build the compilable.

I'm pretty much hoping to go the LLVM route.

I still don't see why you cant start out building out your concepts of syntax and the like. Any professor is much more likely to listen if you have actually put enough thought to be able to sketch out a basic BNF or explanation as to why you want to do this. I knew people that did things like that in college and got research grants for doing it, but they put for the effort and took the initiative.

Yeah, I'm working on learning how to write a BNF grammar. It doesn't seem too complicated.

A prof told me he teaches a compilers class that has most of what I need to know, so I'll actually take it next spring, provided it's offered.

[ash.gti]

Like template metaprogramming?

I am just trying to understand which aspects of current ways of doing things like template metaprogramming that are not as well developed as you'd like.

How much do you know about metaprogramming in ruby or smalltalk or lisp?

[aleflamedyud]

Like template metaprogramming?

I am just trying to understand which aspects of current ways of doing things like template metaprogramming that are not as well developed as you'd like.

How much do you know about metaprogramming in ruby or smalltalk or lisp?

You're still talking to me, right? I said generic functions and the multimethods that go with them. AKA multiple dynamic dispatch, something I started a thread about the implementation of a while back. It's only tangentially related to template metaprogramming in that it's got "generic" in the name.

I honestly don't see much wrong with template metaprogramming as we know it, and I love Lisp macros. Absolutely love them. I just wish they could work in a language other than Lisp.

[davean]

I honestly don't see much wrong with template metaprogramming as we know it, and I love Lisp macros. Absolutely love them. I just wish they could work in a language other than Lisp.

Dylan?

[aleflamedyud]

I honestly don't see much wrong with template metaprogramming as we know it, and I love Lisp macros. Absolutely love them. I just wish they could work in a language other than Lisp.

Dylan?

That's just Lisp with slightly different surface syntax.

[Berengal]

Lisp has syntax? Since when?

[EvanED]

Since McCarthy decided that the following shouldn't be a valid program?

Code: Select all

)

[aleflamedyud]

Lisp has syntax? Since when?

Some Lisps lack most surface-syntax, but they all have the same skeleton-syntax:

<sexpr> ::= <atom> | (<list-contents>)
<list-contents> ::= <sexpr> | <sexpr> <list-contents>

[qbg]

Lisp has syntax? Since when?

Lisp has a highly regular syntax; Forth would/might be a better candidate for a language with no syntax.

[ash.gti]

So...

Um... about this multi-dispatch issue.

I did some research in to methods of implementing it, you can do it pretty simply in ruby (even though it doesn't support it by default).

That does seem interesting, yet I can't help but wonder what the more immediate practical uses of it are. Its a relatively new concept so I have only seen the basic examples illustrated in the gem to give ruby multiple dispatch.

for instance:

Code: Select all

class Foo
  def initialize
    multi(:hiya, 0)       {|x| puts "Zero: #{x}" }
    multi(:hiya, Integer) {|x| puts "Int: #{x}" }
    multi(:hiya, String)  {|x| puts "Str: #{x}" }
    multi(:hiya, lambda {|x| x.size > 2 }) {|x| puts "GT2: #{x}"}
  end
end

f = Foo.new()
f.hiya(0)
f.hiya(5)
f.hiya("hello")
f.hiya([1, 2, 3])


On a completely different side note, do these forums have syntax highlighting for programming languages if you use a code block?

[qbg]

So...

Um... about this multi-dispatch issue.

I did some research in to methods of implementing it, you can do it pretty simply in ruby (even though it doesn't support it by default).

That does seem interesting, yet I can't help but wonder what the more immediate practical uses of it are.

Think WRT the visitor pattern.

[Xanthir]

Specifically, multiple dispatch makes the visitor pattern completely invisible. The wikipedia article actually has a bit talking about multiple-method dispatch in Lisp.

Or, to put it another way, the Visitor Pattern is a way to hack multiple-method dispatch into a language that lacks it.

[aleflamedyud]

Most of the so-called "design patterns" are ways of hacking a language feature into a language that lacks it.

[0xBADFEED]

Most of the so-called "design patterns" are ways of hacking a language feature into a language that lacks it.

I've heard this ridiculous tripe regurgitated so many times. Most of the time it comes from people who don't really know what they're talking about, heard someone say it once, and now parrot it whenever the subject of design patterns comes up. I'm not saying that design patterns are the pinnacle of software design, but not everything should be a "language feature".

<Disclaimer - This may get into religious war territory, if it does I'm sorry>

Design patterns describe the collaboration between different objects in an OO language in a language-agnostic way. They give software developers a common vocabulary to talk about higher-level software constructs. Whether or not they are a "language feature" is irrelevant.

Some design pattens like iterator, visitor, and observer roll up nicely into language features, others don't. There are lots of useful design patterns, I don't even want to see the mess of a language that tries to turn them all into "features". People give C++ a hard time for being too complex, I can't imagine what kind of monstrosity this would create. Syntactic-sugar is not the end-all-be-all of language design.

[qbg]

Some design pattens like iterator, visitor, and observer roll up nicely into language features, others don't. There are lots of useful design patterns, I don't even want to see the mess of a language that tries to turn them all into "features". People give C++ a hard time for being too complex, I can't imagine what kind of monstrosity this would create. Syntactic-sugar is not the end-all-be-all of language design.

The point when design patters become a burden is when the language doesn't sufficiently abstract the design pattern away and the user can't sufficiently abstract the design pattern away. A language doesn't need to turn all design patterns into features, but should at least simplify as many as it practically can.

[ash.gti]

The point when design patters become a burden is when the language doesn't sufficiently abstract the design pattern away and the user can't sufficiently abstract the design pattern away. A language doesn't need to turn all design patterns into features, but should at least simplify as many as it practically can.

Which is why languages evolve, like how C++ has the new C++0x spec coming out to introduce features to give it new features to lessen the burden of using a design pattern (like the new for each syntax).

Most of the so-called "design patterns" are ways of hacking a language feature into a language that lacks it.

Hacking a language to give it new features is common practice. Look at lisp, its extremely basic but is capable of so much because of the fact its extensible.

People give C++ a hard time for being too complex, I can't imagine what kind of monstrosity this would create.

I don't consider C++ to be to complex. Its big, but it its not like some other languages that have grown way over bloated with 'features'. Consider PERL, its IMO the most complicated language I have ever had to use. After you get something to work in PERL you often have no earthly clue what it does from just looking at the code. That's a language that has made way to many features into it. C++ is pretty basic compared to PERL, but C++ IMO is a lot lower of a programming language than PERL, if the lowest is assembly, I'd consider PERL way higher. C++ is complex because of pointers, not because of the language features. Its OO system isn't the most complicated in the world, although it does get a bit tricky once you start using multiple inheritance.



Another intersting thing I like about certain languages (Ruby, Groovy, Python, CLOS) is the use of a metaobject protocol. Gives you a lot of extra flexibility in the language.

[aleflamedyud]

Hacking a language to give it new features is common practice. Look at lisp, its extremely basic but is capable of so much because of the fact its extensible.

That is precisely what I meant. In Lisp and Forth, you don't program design patterns, you add language features as and when you need them.

[0xBADFEED]

I don't consider C++ to be to complex. ...

C++ is complex because of pointers, not because of the language features. ...

You've obviously never done much template meta-programming in C++ or had to sort through any.

I like C++ a lot, but if you think it's not that complex you haven't had sufficient exposure to any non-trivial modern C++ libraries. Download the Boost libraries, spend a couple of days sifting through the less documented portions and then come back and tell me that C++ isn't that complicated. Pointers are something that trip up first-year CS students, but when it comes to complexity they are the least of C++'s worries. I'm not ragging on Boost or C++. I really enjoy working with the Boost libraries, but wading through the undocumented sections is not for the timid.

That is precisely what I meant. In Lisp and Forth, you don't program design patterns, you add language features as and when you need them.

Maybe I'm misunderstanding what you mean.

Please define what this "hacking a language" is. Specifically, how it differs from "programming" in said language. If you can "hack" a "language feature" into a language without too much difficulty using standard programming techniques in said language, I would argue that provides a strong case that it should not be incorporated into the core language but remain as part of the standard library.

In any case it doesn't address the fact that many design patterns have no business as part of a language specification (for example, interpreter, flyweight, builder, mediator). In what way are these missing "language features"?

[qbg]

Please define what this "hacking a language" is. Specifically, how it differs from "programming" in said language. If you can "hack" a "language feature" into a language without too much difficulty using standard programming techniques in said language, I would argue that provides a strong case that it should not be incorporated into the core language but remain as part of the standard library.

This assumes that the hack can be abstracted away and put into the standard library (perhaps it is only a hack if you can't abstract it away)...

In any case it doesn't address the fact that many design patterns have no business as part of a language specification (for example, interpreter, flyweight, builder, mediator). In what way are these missing "language features"?

In Design Patterns in Dynamic Programming, Peter Norvig mentions in slide 10 that Interpreter (due to macros), Flyweight (due to first-class types), and Mediator (due to method combination) are invisible or simpler.

[0xBADFEED]

In Design Patterns in Dynamic Programming, Peter Norvig mentions in slide 10 that Interpreter (due to macros), Flyweight (due to first-class types), and Mediator (due to method combination) are invisible or simpler.

Making a pattern easier to implement doesn't negate the existence of the pattern. I'm all for evolving languages to make implementing common patterns easier. The fact that you implement a builder with multi-methods doesn't remove the conceptual use of the builder pattern to do the work (albeit in a modified form). Using a language's built-in macro system to implement an interpreter doesn't negate the fact that you're using the interpreter pattern. Using first-class types to ease or hide the implementation of the flyweight pattern is not the same as completely eliminating the pattern. You still need some concept to describe lightweight sharing of common state. However, multi-methods, first-class types, and macros are higher-order tools that support the implementation of existing patterns, abstract away some patterns, and give birth to new patterns. Brushing-off all existing patterns as short-comings of languages misses a lot of the point.

In the original post aleflamedyud made a blanket statement that, at least by my interpretation, seemed to imply that nearly all common design patterns could be abstracted away with language features. In many cases even if the pattern is made invisible to the programmer the concept remains. Design patterns developed primarily as a way to conceptualize the structure of programs. They're stronger when treated as concepts than when treated as explicit implementations. That's generally how I view them.

[aleflamedyud]

See, the problem is that we can't use Lisp for everything, nor Forth. Only those two languages, and others like them that build their code out of a data-structure available in the language, allow the style of programming that lets a programmer add language features as they become necessary. So instead we ask that other languages get a few of the more useful features from Lisp or Forth, like templates; macros; or multimethods, so that we don't have to implement extensive "design patterns" that disappear utterly into the background when we've got a language that doesn't impose those patterns on us.

[0xBADFEED]

I agree that making the implementation of design patterns invisible or at least easier on the language user is a good thing. The strategy pattern is a good example of something that just becomes invisible in functional language. There's no need for a strategy object when you have first-class functions combined with currying. You can create any strategy you want by composing function implementations.

Even though the strategy pattern, as strictly defined in say the GOF text (as a collaboration between different object instances), has disappeared I think the idea of the pattern still has value. It is still useful to be able to talk about a particular composition of functions that will at some point be passed into a larger algorithm as the "strategy" for performing a particular portion of the algorithm.

I disagree that implementing the strategy pattern is an attempt to hack on first-class functions and currying. The strategy pattern describes something more specific, the modularization of algorithms. Likewise, first-class functions are something much more powerful and general than the strategy pattern and can be used in a myriad other ways that have nothing to do with algorithm modularization. First-class functions do not make the strategy pattern concept redundant, even if they make its implementation implicit instead of explicit.

A similar case can be made for the factory pattern using first-class types as the factory. Even though first-class types can eliminate the use of explicit factory objects, the factory concept remains useful as a way of describing the indirect creation of objects and decoupling the creation of an object from its use.

Maybe this is extending the concepts of "strategy" and "factory" a bit too far but I don't know of anything higher level than design patterns that attempts to capture software behavioral and structural information in a language-agnostic way. I'm merely saying that beyond the implementation of design patterns they have value in that they provide a taxonomy for software constructs.

It's entirely possible that my view of design patterns pushes the boundaries of what might be considered acceptable. But I think it's also possible that your view is overly narrow.

Is there another taxonomy that attempts to capture these ideas that I'm not aware of?

[btilly]

I don't consider C++ to be to complex. Its big, but it its not like some other languages that have grown way over bloated with 'features'. Consider PERL, its IMO the most complicated language I have ever had to use. After you get something to work in PERL you often have no earthly clue what it does from just looking at the code. That's a language that has made way to many features into it. C++ is pretty basic compared to PERL, but C++ IMO is a lot lower of a programming language than PERL, if the lowest is assembly, I'd consider PERL way higher. C++ is complex because of pointers, not because of the language features. Its OO system isn't the most complicated in the world, although it does get a bit tricky once you start using multiple inheritance.

OK, I get that you don't like Perl. But can't you please learn to call it by its real name? As perlfaq1 says, Perl is not an acronym, and so should not be written PERL.

With that out of the way, how readable Perl is depends very much on both the author and the reader. There are many good Perl programmers, and their code tends to be very easy to read, even a long time afterwards. There are many programmers who write Perl and cannot be understood by anybody, including themselves. Please do not confuse the limitations of the latter programmers with the limitations of the language.

On Perl's OO. The OO system was hacked in. It is very simple and flexible, but has some major problems, particularly when it comes to things like multiple inheritance. That's not to say that it doesn't work - it does work quite well. As long as you use it like it was meant to be used. For an inspiring book, if you can find it, Object Oriented Perl by Damian Conway is an excellent guide demonstrating just what you can accomplish using Perl's OO system.

But if you wish to do a lot of advanced OO within Perl, it is best that you learn about Moose. See also http://search.cpan.org/~sartak/Moose-0.55/lib/Moose.pm. The summary is that that fixes a lot of the problems in Perl 5's OO's system, and brings to Perl 5 some of the more interesting features that were dreamed up for Perl 6. Features like roles. As the author says, the fact that Moose was possible at all is a testament to the hidden power of Perl's OO system.