Re: Draft RFC: my Dog $spot is just an assertion
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
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
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
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