On Fri, 2004-05-14 at 18:53, Luke Palmer wrote:
> Aaron Sherman writes:
> > or did Larry mention a way to define a converter and I missed it?
>
> Yep, that's what happened. See Apocalypse 12 under "Overloading."
Ok, so in the case of:
my int $i = ...;
we should apply C and fail at r
Aaron Sherman writes:
> On Fri, 2004-05-14 at 18:53, Luke Palmer wrote:
> > Aaron Sherman writes:
>
> > > or did Larry mention a way to define a converter and I missed it?
> >
> > Yep, that's what happened. See Apocalypse 12 under "Overloading."
>
>
> Ok, so in the case of:
>
> my int $
Would it be a good idea to make ==, and other numeric comparators polymorphic
so they can be used also for string comparisons? Or the will is to keep eq,
gt and the others. (not very nice emho).
Regards.
--
Pedro Larroy Tovar | Linux & Network consultant | piotr%member.fsf.org
Software paten
On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote:
> Would it be a good idea to make ==, and other numeric comparators polymorphic
> so they can be used also for string comparisons?
How does the compiler know which is which?
Is "10" a string? Is it a number? Is "10base-T" a string? Is it a
num
On Mon, May 17, 2004 at 01:42:26PM -0700, chromatic wrote:
> On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote:
>
> > Would it be a good idea to make ==, and other numeric comparators polymorphic
> > so they can be used also for string comparisons?
>
> How does the compiler know which is which?
>
Pedro Larroy writes:
> Would it be a good idea to make ==, and other numeric comparators
> polymorphic so they can be used also for string comparisons? Or the
> will is to keep eq, gt and the others. (not very nice emho).
It was decided long ago that the distinction between == and eq is going
to s
On Mon, 2004-05-17 at 13:51, Pedro Larroy wrote:
> I thought perl internally would know. At least in perl5 it has to know
> somehow, since you can $var++ when is numeric and also when it's a
> string, and behaves different in each case.
True. Perl 5 scalars do keep track of the context in which
Luke Palmer wrote:
Admittedly, if you use == for everything, you can force string or
numeric comparison this way:
if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string
Hmm.
In my head, I would expect == to have implicit numification on the
operands (unless user-overloaded to some
Rod Adams writes:
> Luke Palmer wrote:
>
> >Admittedly, if you use == for everything, you can force string or
> >numeric comparison this way:
> >
> > if +$a == +$b {...} # numeric
> > if ~$a == ~$b {...} # string
> >
> >
> Hmm.
> In my head, I would expect == to have implicit numification
Luke Palmer wrote:
Oh, sorry, wasn't clear. That's *if* eq was eliminated and == became a
polymorphic operator.
You're correct in terms of the current (and hopefully continuing) state
of things.
Went back and re-read your first post, and that is indeed what you were
saying, I just read it too
Luke Palmer skribis 2004-05-17 14:54 (-0600):
> Admittedly, if you use == for everything, you can force string or
> numeric comparison this way:
> if +$a == +$b {...} # numeric
> if ~$a == ~$b {...} # string
And $a :=: $b could be written as \$a == \$b. Oh, hm.
It does sound kind of a
> -Original Message-
> From: Rod Adams [mailto:[EMAIL PROTECTED]
> I'd be seriously annoyed if eq went away. It's one of
> those things that makes Perl Perl. It's up there with
> the postfix if.
>
> ~$a == ~$b
> feels too much like:
> Cast(String, $a).Compare(Cast(String, $b))
>
12 matches
Mail list logo
