Re: problams with IO::Socket::INET

garrow@whirlwind.fmr.com
Wed, 28 Jan 1998 09:59:20 -0500


Mark writes:
   In message "Re: problams with IO::Socket::INET", 
   'tchrist@jhereg.perl.com' writes:
[Someone no one bothered to remember wrote:]
   >>As well, C++ and Java require you to use new(). I know that's not a
   >>bulletproof reason, but it makes it more obvious to someone who has
   >>never used the class in question before.

I'd agree with this reasoning. I dont think it would justify
_mandating_ 'new' by giving it special parsing status, but it
certainly means there is value to following the convention generally.

   >That's a good reason not to.  Perl's constructors are very 
   >different.  They don't call overridden versions.  They have 
   >to allocate memory.  etc.  Better not to deceive.

Perl does not _HAVE_ constructors.  There is a popular pretense at
having objects which happens to be documented in the core
distribution. That pretense advocates the use of the same routine to
allocate and to initialize objects.

I have provided an alternate implementation which uses "genuine"
constructors. The kind which operate on objects that have already had
superclass constructors executed, and which have no return value.

At any time, Perl could "grow up" and improve its implementation of
OOP support.

   Implementation of objects and interfaces to objects are different things.
   In C++/Java, the allocation is hidden from the class author. In perl,
   the author of the class must allocate the object themselves.

No. In Perl, the author who believes the documentation is fooled into
believeing that, but it isnt necessarilly true.

   P.S.
	Now what i'm really wishing existed was a _generic_ version of TomC's
	delegation object model. I want the derived class data type (hash,etc.) to
	be completely independant of the implementation of the base class. And
	i don't want to have an AUTOLOAD() sub{} in each of my classes. But i can
	tell this won't happen anytime soon :-) See with this kind of model, we
	_could_ have the constructor for each class (including MI) run properly.

Yes, well.. you could use my implementation of that. I know it dosent
require any of those huge C code patches to the core; but if you can
somehow manage to actually like "Perl" code, its all yours.

--
John Redford
GArrow