Re: RFC 336 (v1) use strict 'objects': a new pragma for using Java-like objects in Perl

Hi all

Preamble:
1) Everybody: excuse my english, my italian is better but you don't want
me to write in italian :-)
2) Listmaster: excuse this post from an unknown address, I've just
subscribed as [email protected];
3) Everybody again: excuse the address @perlguru.com, but I didn't want
my work mailbox filled of ML messages... and that address is free and
works well ;)

Said this, the message.

Jonathan Scott Duff wrote:
> 
> On Thu, Sep 28, 2000 at 09:05:52PM -0000, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> >
> > use strict 'objects': a new pragma for using Java-like objects in Perl
> 
> > =head2 protected
> >
> > Just take Conway's RFC 188 and do a s/private/protected/g :-)
> 
> "protected" is a very loaded term.  What you propose to call protected
> in Perl isn't the same as protected in C++.  This will cause
> confusion.

Significance we attribute to "protected" is similar to Java's. Many
languages use the same keyword with different meanings, nor this creates
any ambiguity. Who gets confused by the fact that the "=" operator has
different meanings in C and Pascal, raise your hands :) Leaving the joke
out, "our" protected operator is similar to Java's; we don't want Perl
to become C++ or Java: we just would like to have better objects.

> > =head2 private
> >
> > Like Conway's private operator defined in RFC 188, but accessing an
> > hash key or a method that has been marked as private from outside the
> > defining package should result in a fatal error.
> 
> What does this buy us?  What is the benefit?

The benefit is: having real (s/real/more realistic/ if you like)
objects: an object's attributes should be accessible only by the object
itself; accesses from outside should happen by means of methods, and
methods are responsible for object's data consistency. Can you
accomplish this with perl 5 without doing weird games with closures?

> > =head2 static
> > Methods not marked as such should return a fatal error if called
> > directly on the class.
> 
> Again, where's the benefit?

You have one in the last example of the RFC: you have methods (say:
subs) you can access from a class in an object oriented way. This gives
you more coherence. And you don't need to instanciate objects to use
them, you just use them from the class. Moreover, if you need those
functions in many methods (again, say: subs) you don't have to
instanciate an object and pass it around, nor you have to instanciate
one over and over, nor you use plain functions: you use classes and
methods, coherently.

We hope we explained our point of view. In case we didn't, I'm on this
list now (with a awful address, but -maybe- it doesn't matter).

Ciao
Marco & Stefano

-- 
  ____  ____  ____  _  _ 
 / ___)| __ \/ ___)/ /| | Marco Marongiu ([email protected])
| (___ |    /\___ \\__  | Computers & Network Group
 \____)|_|\_\(____/   |_| Phone: +39 070 2796 336