> =head1 TITLE
>
> my Dog $spot should call a constructor implicitly
>
What, then, happens to the following code:
my Dog $spot;
if ($age > 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
Would you seriously propose to create a Dog object, then wipe it in
either branch if
Perhaps there is some way to allow for both syntaxes? For example, in C++ I
can say:
string str();
or:
string* str = new string();
Depending on my needs.
So perhaps sometimes in Perl we could say:
my Dog $spot = undef;# Automagically knows to be a Dog ref instead
of a Dog obj
On Tue, Aug 29, 2000 at 10:00:13PM -0700, Nathan Wiger wrote:
> Matt Youell wrote:
> >
> > > mainstream OO languages go). It looks like Dog could be a type of String
> > > subclass.
> >
> > That was my first thought as well. Besides, I'd rather type:
> >
> > my Dog $spot("Spot");
> >
> >
On Wed, Aug 30, 2000 at 08:22:11AM +0100, Hildo Biersma wrote:
> > =head1 TITLE
> >
> > my Dog $spot should call a constructor implicitly
> >
>
> What, then, happens to the following code:
>
> my Dog $spot;
> if ($age > 12) {
> $spot = new Doberman();
> } else {
> $spot = new Corgi();
On Tue, Aug 29, 2000 at 12:57:07PM -0700, Matt Youell wrote:
> So perhaps sometimes in Perl we could say:
>
> my Dog $spot = undef;# Automagically knows to be a Dog ref instead
> of a Dog object because of the undef.
> if ($age > 12) {
> $spot = new Doberman();
> } else
Matt Youell wrote:
>
> So perhaps sometimes in Perl we could say:
>
> my Dog $spot = undef;# Automagically knows to be a Dog ref instead
> of a Dog object because of the undef.
> if ($age > 12) {
> $spot = new Doberman();
> } else {
> $spot = new Corgi();
>
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> my Dog $spot should call a constructor implicitly
Eeeeww. Most of the time I use 'my Dog $spot' is along the lines
of:
package Dog;
Damian Conway <[EMAIL PROTECTED]> writes:
>
>
>BTW, this is not just theoretical yearnings. I have written three modules
>in the past year that do not work as well as they could, simply because it
>is not possible to overload && and ||.
>
>Damian
I have one too.
--
Nick Ing-Simmons <[EMAIL PRO
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 Do
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
> > mai
Hildo Biersma <[EMAIL PROTECTED]> writes:
> 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.
Hmmm... having 'explicit' be implicit and vice versa? I think my head
may
> 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.
Yes, C++ implicitly treats single argument constructors
as conversion constructors. They convert th
Michael Fowler wrote:
>
> Regarding the STORE call, if RFC 159 gets adopted, sure, why not. I'll
> mention that alternative in the RFC's next version.
Cool.
> I need to mention the:
>
> my int $x;
> my int $i = 4;
> my int ($x, $y, $z) = (4, 5, 6);
>
> syntax in the RFC. It des
Hildo Biersma wrote:
>
> I feel this discussion confuses multiple things:
> - Is a scalar an object or a reference to an object?
The current thinking on this list is that a scalar == an object. That's
where this discussion is getting confusing, because people aren't
clarifying that this:
my
Piers Cawley wrote:
>
> Eeeeww. Most of the time I use 'my Dog $spot' is along the lines
> of:
>
> my Dog $spot = Dog::Dalmation->new(name => 'Spot');
> $spot->bark;
No problem, that still works, according to the RFC...
>sub bark {
>my Dog $self = shift;
>print
> What, then, happens to the following code:
>
> my Dog $spot;
> if ($age > 12) {
> $spot = new Doberman();
> } else {
> $spot = new Corgi();
> }
This is a tricky case that deserves a lot of attention, but not exactly
as written. Imagine this code block:
my int ($x, $y, $z) = (4, 5,
> Right now, the default behavior of perl is that un-initialized variables
> are automatically undef. It would be weird to have to do explicit
> assignment of an variable to say so.
You're right. And as another post mentioned, it's too much "magic". But It's
hard to come up with a comfortable sy
In a discussion last year about why "foreach my Dog $spot (@Dogs) {
... }" didn't work, Larry brought up an interesting idea...
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-09/msg00962.html
Seems reasonable to me. Especially since we might get tremendous
compiler speedups
On Wed, Aug 30, 2000 at 03:17:59PM -0400, Michael G Schwern wrote:
> Its not just objects and classes we're talking about, its types and
> variables, too. Remember, Perl ain't all OO yet. Which is further
> aggrivated if "my Class $obj" has magical meaning and calls a
> constructor.
>
> Now, we
On Wed, Aug 30, 2000 at 05:06:16PM -0400, James Mastros wrote:
> I don't see why this needs to be... either:
> 1) We clearly define in the beginning that if "Dog" is a basic type, then
> this has semi-magical properties.
> 2) We clearly define that basic types will always m/^[A-Z]+$/.
Or if clear
>Or if clearly make basic types look *very* different from user-defined
>types:
> my Dog $spot;
> my *int $i; # types that start with * are "basic"
Intrinsics (basic types) are in lower-case.
User-defined types aren't.
our num $Count;
my Word @verbs;
One wonde
At 04:20 PM 8/30/00 -0600, Tom Christiansen wrote:
> >Or if clearly make basic types look *very* different from user-defined
> >types:
>
> > my Dog $spot;
> > my *int $i; # types that start with * are "basic"
>
>Intrinsics (basic types) are in lower-case.
>User-defined type
>Do you really mean to suggest that $SPECIALVARS be (by convention)
>uppercase but built in types be (by grammar) lowercase?
Absolutely. That's how it's already worked. The pragmata are lowercase module
names are reserved to the Core. The type name is the class name, which
is the package nam
On Wed, 30 Aug 2000 18:27:04 -0400, Buddha Buck wrote:
>Do you really mean to suggest that $SPECIALVARS be (by convention)
>uppercase but built in types be (by grammar) lowercase?
Guess what is currently the case with all built-in functions. Lowercase.
Guess what is currently the custom with bu
24 matches
Mail list logo
