Abigail said:
Arved Sandstrom (
[email protected]) wrote on MMMMDCCCXXVIII [ SNIP ]
** I cringe a bit when the term "native" comes up, because it means so
many
** different things in programming. But I will assume that by "native"
object
** attributes you mean that there is a way, in the language, of
syntactically
** distinguishing the fields of the object that are logical attributes
from
** those that are not (and are just implementation details).
**
** In other words, how much built-in support is there in the language for
** encapsulation. Which in turn leads to so much else in OOP.
**
** Am I reading you correctly?
What I mean is that the language Perl does not have object attributes.
It's not there in the language, in the same way that C doesn't have
regular expressions.
OK, we understand each other on that point. I was being a tad nitpicky,
because I'd argue that neither does Java or C++, for example, exactly have
object attributes, any *more* than Perl 5 does. We have an _understanding_,
a contract if you will, that if we do certain things with access specifiers
and accessor methods (get/sets or properties like in C#) that we will agree
that certain fields are object attributes and others are just implementation
details. But there is absolutely nothing stopping me from exposing a
implementation field as a public field in Java, for example, or exposing it
with a public getX() - does the language have anything to say about whether
or not that field is an attribute of the object? No, it doesn't - it's down
to convention and best practices.
I'd argue that the Perl conventions in this sense are no worse than they are
in many of the mainstream OOP languages.
That doesn't mean you can't do regular expressions in C. They are just
natively not in the language. If you want them, you as the programmer
have to do all the work yourself.
I'm from the school that doesn't consider a language and its common
(standard) libraries in isolation. I understand how you're using the term
"native" here - I just don't find it important. I can't do foldr/foldl or
zip/zipWith or length or map or filter in Haskell either without a library,
short of rewriting them, but I consider those native capabilities.
Similarly, if regex capability is available in a standard C library, I
consider RE handling to be native in C. Strip away all the libraries from
Java and the language is a pretty poor thing.
I actually have to do roughly the same amount of work in Java or C++ or C#
or Eiffel to define object attributes as I do in Perl 5. I am, quite
frankly, unconcerned that some people may perceive "public int X" in a Java
class as somehow being more pure and native than a field X in a blessed hash
ref in Perl. At that point they are in fact identical.
I'm just amazed that people call the absence of elementary construct
(given that you've decided to support OO in the language) a *feature*.
I've never heard anyone advocate Java or C for their lack of native
support for regular expressions or hashes, but people keep considering
the lack of support for object attributes as the best thing since sliced
bread.
I don't think Perl is that bad. I fall very strongly on the side of those
who say that it's a knowledgeable programmer who should follow a contract,
not the language that imposes the contract on him or her. Not only that, but
I expect knowledgeable user of my classes, provided that I document them.
There are enough, fairly simple, safeguards in Perl OOP to ensure that if a
user of an OOP module wants to do something that they oughtn't do, they put
some effort into discovering how to do what they shouldn't. And isn't that
really the basic issue?
As far as object attributes go in Perl 5, they are what I say they are, as
fields in whatever ref I choose. I document them. I provide suitable access.
People use them as recommended, or they don't. End of story.
AHS
later....