Re: Draft RFC: my Dog $spot is just an assertion

2000-09-13 Thread Hildo Biersma

Piers Cawley wrote:

 =head1 ABSTRACT
 
 The behaviour of the my Dog $spot syntax should simply be an
 assertion of the invariant:
 
(!defined($spot) || (ref($spot) $spot-isa('Dog)))

Apart from the buglet that Damian pointed out, agree.

Instead of an implementation based on tie, I'd rather define logical
sequence points where the core would check this assertion - e.g., just
after any modification (assignment, bless, change in @ISA-tree, ...).

Hildo



Re: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Hildo Biersma

Piers Cawley wrote:
 =head1 ABSTRACT
 
 Cmy Big::Long::Prefix::Class $object = Big::Long::Prefix::Class-Egtnew
 is a pain in the bum to type. We should replace this with
 
 use namespace 'Big::Long::Prefix';
 my ::Class $object = ::Class-new;

This is a bit dangerous, since we can get into ambiguities again.
If I have A::B::C::Foo,  A::B::C::Bar, X::Y::Z::Foo and X::Y::Z::Bar,
I'd like to use shorthands for A::B::C's Foo and X::Y::Z's Bar at the
same time.

While we don't want to go the whole C++ namespace route, I'd like to be
able to import 'all' of a namespace, or just selected classes from a
namespace.

Hildo



Re: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Hildo Biersma

Piers Cawley wrote:
 
  This is a bit dangerous, since we can get into ambiguities again.
  If I have A::B::C::Foo,  A::B::C::Bar, X::Y::Z::Foo and X::Y::Z::Bar,
  I'd like to use shorthands for A::B::C's Foo and X::Y::Z's Bar at the
  same time.
 
 Well you can't. The patch that I pinched this RFC from is a lexically
 scoped affair, so if you want to use a different namespace somewhere
 else you are free to do so:
 
 use namespace 'A::B::C';
 my ::Foo = ::Foo-new;
 use namespace 'X::Y::Z';
 my ::Foo = ::Foo-new
 
 should work.

Yeah but - I am asking for more control.

Could we not support both:
   using namespace 'A::B::C';
in which ::Foo refers to A::B::C::Foo, and no reference to X::Y::Z works

and

  using A::B::C::Foo;
  using X::Y::Z::Bar;
in which ::Foo is now an alias for A::B::C::Foo and ::Bar is an alias
for X::Y::Z::Bar.  This would end the effect of a previous 'using
namespace' statement.

I've written this with a 'using' keyword, we can of course also use the
module syntax in your proposal...

Hildo



Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly

2000-08-30 Thread Hildo Biersma

Jonathan Scott Duff wrote:
 
 On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote:
  First greatly stylistic compatibilty.  An inexperienced programmer would
  see:
  my Dog $spot = "Spot";
 
  And become confused.  It's totally unintuitive (at least so far as other
  mainstream OO languages go).  It looks like Dog could be a type of String
  subclass.
 
 Why would the programmer become confused?  In C++ (a mainstream OO
 language), if a Dog constructor was defined that took a string as an
 argument, the string would be auto-converted to a Dog.
 
 So, if this were adopted for Perl, the programmer would know that the
 class constructor for Dog would be called to instantiate $spot, then,
 because of the assignment, the Dog-STORE() method would be called.
 And if the programmer were inexperienced, it would be a perfect time
 for them to learn something.

Note that in C++ this can be sufficiently confusing that the 'explicit'
keyword is required to mark constructors as "do not use them for this
kind of behavior". 

Many people see even this as a bad choice, saying that 'explicit' should
be the default, and that C++ constructors should be marked 'implicit'
for this behavior to be allowed.

Anyway, what's wrong with:
  my Dog $spot = Dog-new("Spot");
as that scales to
  my Animal $spot = Dog-new("Spot");
  my Dog $fifi = PersistentDog-restoreFromDatabase("fifi");
and others - i.e., it does not impose policy on the poor user.

Hildo