Re: copy contructor

Abigail <abigail@xxxxxxxxxx> wrote in comp.lang.perl.misc:
> Moritz Karbach (moritz.karbach@xxxxxxx) wrote on MMMMCCCXXXVI September
> MCMXCIII in <URL:news:db8ihi$d616$1@xxxxxxxxxxxxxx>:
> [] >> I'm writing some code in object oriented Perl, and I'm missing a default
> [] >> copy constructor. Are there some default workarounds?
> [] >
> [] > Huh? Standard OO doesn't know about copy constructors. They come
> [] > into play with operator overloading, but even then you don't necessarily
> [] > have to define one.
> []
> [] You're right. But IIRC at least C++ copies all attributes (or class members
> [] or how you call it) of a class, if you say
>
> Yeah, C++ has. But then, C++ has attributes, Perl doesn't. Perl has the
> least language support I've ever seen for doing OO - it doesn't even have
> attributes.
>
> And the step from "no attributes" to "no functionality to copy attributes"
> is trivial.
>
>
> My advice: if you really want to do OO, use a different language.

The problem isn't so much that real OO couldn't be done in Perl, but
that what the language lacks in support must be supplied by the programmer,
and it can be supplied in various incompatible ways. This is a point
where Perl's TIMTOWTDI becomes a problem.

A lot would be gained if the role of accessors in Perl OO were better
appreciated. Any method that de-references its object is an accessor,
and an (inheriting) client class may have to override all of them. So it
needs to know which they are, and it is good to restrict them in number.

Usually that only means to define a few field accessors in the usual way,
and then *base all other methods on them*. There is much so-called Perl OO
code about that accesses the object all over the place and is almost
impossible to inherit from. More complex accessors are sometimes wanted
for efficiency or flexibility. They must be clearly documented so that
a client class knows how to override them.

A parent class that is designed (and maintained) to these principles
can be safely and relatively painlessly inherited from even across
changes in implementation.

Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
.

Relevant Pages

  • Re: Word 2003 - different pagination on different documents
    ... I had the users check on any installed or turn-on language support. ... our problem doc to my own Normal (and clicking the “Automatically ... Has the paragraph been given a negative right ...
    (microsoft.public.word.docmanagement)
  • Re: copy contructor
    ... if you really want to do OO, use a different language. ... I never said OO couldn't be done in Perl. ... Accessors don't solve the fundamental problem OO in Perl has: ... refs to hashes) encapsulation has to be broken to do inheritance. ...
    (comp.lang.perl.misc)
  • Re: multiple language support: dialog-boxes
    ... I`ve a sdi application where I want to add multiple language support. ... using a simple std::map to map language abbreviations to DLL handles might ... Both have the same resources as ...
    (microsoft.public.vc.mfc)
  • Help regarding MUI
    ... "Regional and Language support" component lists what are the ... an option to "Enable multilanguage user interface for this component ...
    (microsoft.public.windowsxp.embedded)
  • Re: Dijkstra gets it wrong [was: Re: D gets it right]
    ... > language feature is inherently evil. ... Of course, accessors can be ... without automatically requiring changes in all the using code. ...
    (comp.programming)