What bless() do actually?

[Marc Espie]

Perl's problem with OO isn't that you can't do some things (you can),
but that you can do some things in too many ways.

Nonsense. Being able to do things in many ways has always been THE trademark
of the language. I've yet to be stopped by it, and so do lots of people,
since CPAN is thriving with interesting modules, a lot of them showing
very advanced object techniques.

It begins with choosing an object type. In most OO languages, an object
is a struct-like data type. In Perl you get to chose if you want to use
a hash, an array, a scalar or one of the more exotic types, and they
are incompatible unless the programmer(s) take extra efforts. If they
don't a program that uses one class to inherit from the other will
crash an burn. That has so far stopped Perl from developing a useful
class library. Many OO languages are more strongly characterized through
their class library than anything else.

A useful class library ? ah! then what I use every day isn't useful.
You have everything at your disposal, and it's usually about ten lines
of code to adapt stuff to use an outside class you don't know anything
about.

Focusing on inheritance is a bad design decision in my opinion. Too tight
coupling. Composition is often much better. And you can use the autoloader
to great effect to build new behavior on top of existing classes.

Inside-out classes are promising in this respect. They can be inherited
without restriction by every other class (inside-out or not). They can
also inherit from one (but not more) non-inside-out classes, besides,
of course, arbitrary other inside-out classes.

Well, I don't care too much about clients misusing my code. I focus on
writing useful code, and then if they abuse it, that's their problem, not
mine.

There was a quote in _programming perl_ to the effect that perl doesn't
really need private/public because perl programmers prefer you stay out
of their internals because you politely ask them to, not because you
string a fence with barbed wire around it. I adopted this as my
opinion.

 

[Marc Espie]

Oh, and "abstraction" is often in that list too - but I would be happier
saying that that is a consequence of inheritance (and perhaps polymorphism).

Personally, I would tend to put `abstraction' at the top.

Inheritance and polymorphism are actually not really needed in many cases.

You can build OO languages without inheritance. Cloning prototype objects
comes to mind.

This kind of behavior is even not too hard to build in perl, and I've
built Object-oriented PostScript code in the past by using that technique.

The only `feature' you need for object-orientation is a way to associate
code with data, namely have an operator so that o->f(args) will call an f
which is dependent on o.

So any language with hashes and anonymous subs leads itself to object-oriented
techniques in a very straightforward way: just let your hashes be objects,
and key the anonymous subs with method names. Everything else, including
using an extra indirection through a `class' to have uniform object behavior
and save memory is just optimization. ;-)

 

[David Squire]

Personally, I would tend to put `abstraction' at the top.

In terms of importance yes, but is it a fundamental language property or
a something constructed by coding? From a language point of view, it's
about being about to have abstract classes (e.g. pure virtual functions
in C++, interfaces in Java), which to me is all about inheritance.

Inheritance and polymorphism are actually not really needed in many cases.

You can build OO languages without inheritance. Cloning prototype objects
comes to mind.

This kind of behavior is even not too hard to build in perl, and I've
built Object-oriented PostScript code in the past by using that technique.

The only `feature' you need for object-orientation is a way to associate
code with data, namely have an operator so that o->f(args) will call an f
which is dependent on o.

So any language with hashes and anonymous subs leads itself to object-oriented
techniques in a very straightforward way: just let your hashes be objects,
and key the anonymous subs with method names. Everything else, including
using an extra indirection through a `class' to have uniform object behavior
and save memory is just optimization. ;-)

Your definition of OO as no more than "code associated with data" is at
odds with the currently accepted (academic) definition of what an OO
language is. This is not a value judgment, just a statement of current
dogma.

I have a lot of sympathy with your view, but ultimately I think this
argument leads towards the conclusion that all Turing-complete languages
are OO, since you could built such machinery out of them one way or
another. It must surely be a question of what the language natively
supports, rather than what can be built using it.

I think we need to make a distinction between OO languages and OO
techniques. Years ago I wrote a widget set (before I was aware of that
term) for SGI machines in C, using structs with function pointers to
represent "widgets". In retrospect an OO technique, but that does not
make C an OO language.


DS

 

[Marc Espie]

Your definition of OO as no more than "code associated with data" is at
odds with the currently accepted (academic) definition of what an OO
language is. This is not a value judgment, just a statement of current
dogma.

I disagree. You're talking buzzwords and undergraduate academics.

All the stuff I've seen regarding semantics research and type checking,
for instance, boils down to extending traditional lambda-calculus somehow
to include object constructs.

Any half decent course on language theory/compilation/semantics will have
some reduction towards object = data + associated methods, together with
a discussion of space-constraint optimizations (e.g., vtables) and
type systems and their various limitations.

 

[anno4000]

Nonsense. Being able to do things in many ways has always been THE trademark
of the language. I've yet to be stopped by it, and so do lots of people,
since CPAN is thriving with interesting modules, a lot of them showing
very advanced object techniques.

Quite so. But when you want to use two of them together you must study
both quite carefully to see how that can best be done. It gets worse
with more modules, and the more advanced ones are often hardest to
integrate with others.

Perl's motto TIMTOWTDI shouldn't make us blind to the risks and
drawbacks this approach also has.

A useful class library ? ah! then what I use every day isn't useful.
You have everything at your disposal, and it's usually about ten lines
of code to adapt stuff to use an outside class you don't know anything
about.

Focusing on inheritance is a bad design decision in my opinion. Too tight
coupling. Composition is often much better. And you can use the autoloader
to great effect to build new behavior on top of existing classes.

Inheritance is an integral part of OO programming. Without neglecting
other techniques, inheritance ought to be available when it is the right
tool. Using inheritance is not, per se, a bad design decision. A
programmer who does everything through it (or tries to) isn't making
a bad design decision but is following a bad habit.

In Perl inheritance isn't as freely available as it should be.

Well, I don't care too much about clients misusing my code. I focus on
writing useful code, and then if they abuse it, that's their problem, not
mine.

The point of inside-out classes isn't protection of object data. That's
a useful side effect. The point is that every class has its own
name space without conflicts with other classes.

Even in a world where every object was standardized to be a hash ref
whose keys and values are used like the fields of a struct, (a very
popular implementation) you can't safely add more fields without knowing
the implementation of the host object. It gets worse when the host
can be of any type.

Inside-out classes are a way to get rid of that dependency. They are
not about protecting your data from malicious users.

There was a quote in _programming perl_ to the effect that perl doesn't
really need private/public because perl programmers prefer you stay out
of their internals because you politely ask them to, not because you
string a fence with barbed wire around it. I adopted this as my
opinion.

Roughly: "Perl prefers you to stay outside the living room because you
were not invited, not because it has a shotgun."

That's very well as far as it goes. I, too, am happy to indicate
private routines and methods with a leading underscore and nothing
else.

The problem is that you don't always know when you are entering
someone's living room. Then you find out they do have a shotgun
after all.

Anno