That #perl6 discussion on character strings over the last hour then
evolved into a discussion on binary strings, where the
pseudo-conclusion started here:
http://colabti.de/irclogger/irclogger_log/perl6?date=2006-08-09,Wed&sel=294#l520
And so, I formally propose the addition of an immutable an
At 5:25 PM -0700 8/8/06, Darren Duncan wrote:
I'm wondering if it would not be inappropriate to change the name
Str to something more descriptive of its content within the
historical or current wider context.
For example, would the name Text be any worse? In my mind, that is
less ambiguous
This may be a non-problem in practice, but ...
Regarding the Str data type, which Perl 6 defines as holding a
compact sequence of characters, I'm thinking that this type's current
name is ambiguous considering the traditional uses of the word.
Traditionally, a "string" isn't necessarily a seq
On Tue, Aug 08, 2006 at 11:42:15 +, Luke Palmer wrote:
> I'm not up-to-date on coersion; last I checked it was hand-wavily
> defined.
Currently it's a unary multimethod:
my $hamburger = $cow.as(Food);
However, the MMD rules are counterintuitive for dispatch rules.
The reason annota
On Tue, Aug 08, 2006 at 12:00:03 +, Luke Palmer wrote:
> The difference, though, is that this ambiguity error happens at
> call-time, whereas most ambiguity errors happen at composition time.
As I saw it it's not really a role, it's more of a no-op coercion.
Instead of actually writing an ad
On 8/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
My original idea was that this is again an ambiguity error - without
the helper function stating which role it's using it cannot dispatch
the "header" method at all, since it's in a role-conflicted state.
The difference, though, is that this am
On 8/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
It's much more relevant for:
fun( $x.foo :: Bar );
in order to annotate the return type for a call's context even if
the 'fun' function's signature accepts Any.
Touche, this is independent of type inference.
I'm not up-to-date on coe
On Tue, Aug 08, 2006 at 11:35:30 +, Luke Palmer wrote:
> On 8/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> >I personally prefer delegates for almost any design dillema, but
> >most CPAN modules aren't that way.
>
> Well, what way are they?
Usually not polymorphic at all.
We have the capab
Actually this particular example is just like coercion, and it's a
bad one sorry.
It's much more relevant for:
fun( $x.foo :: Bar );
in order to annotate the return type for a call's context even if
the 'fun' function's signature accepts Any.
--
Yuval Kogman <[EMAIL PROTECTED]>
h
On 8/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
I personally prefer delegates for almost any design dillema, but
most CPAN modules aren't that way.
Well, what way are they? How else has this problem been solved?
Yes, this is necessary for anything heavyweight and probably better
design,
On 8/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
On Tue, Aug 08, 2006 at 11:12:11 +0100, Daniel Hulme wrote:
> I may be in a little world of my own here, but isn't this what 'as' is
> supposed to do?
>
> foo($x as Moose);
as is a method invocation not a type annotation... It's related, but
no
On Tue, Aug 08, 2006 at 11:14:40 +, Luke Palmer wrote:
>Mail::TheOneTrueWay.new.header; # which one?
Either neither, or the "default" one (which is declared default by
the class).
> A related question: if Mail::SomeAPI and Mail::SomeOtherAPI both
> exported a method, say "send", and you
On 8/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
The way it could work is a bit like this:
class Mail::TheOneTrueWay {
does Mail::SomeAPI is weak {
method header; # this method has different semantics for
# each role. It w
On Tue, Aug 08, 2006 at 11:12:11 +0100, Daniel Hulme wrote:
> I may be in a little world of my own here, but isn't this what 'as' is
> supposed to do?
>
> foo($x as Moose);
as is a method invocation not a type annotation... It's related, but
not the same (last I heard)
--
Yuval Kogman <[EMAI
> Is it possible to say this one expression? Haskell's syntax is shiny
> but everybody wants the colon:
>
> foo( ( $x :: Moose ) );
I may be in a little world of my own here, but isn't this what 'as' is
supposed to do?
foo($x as Moose);
--
"Of all things, good sense is the most fairly
Is there any way to type annotate a single expression, without using
a temporary variable?
my Moose $x = $y; # definitely a Moose now, may have been coerced
foo( $x );# foo() doesn't necessarily say it wants Moose
Is it possible to say this one expression? Haskell's syntax is shi
On Tue, Aug 08, 2006 at 09:05:07 +0200, Mark Overmeer wrote:
> Of course, we could use the Email::Abstract interface as a base-
> class to all email related modules, but you know that this wouldn't
> work for the Perl community...
Actually I'd like to expand on this.
There are two problem with y
On Tue, Aug 08, 2006 at 09:05:07 +0200, Mark Overmeer wrote:
> Sometimes, the external interface of a module looks the same, and
> there are cases where the internals behave as such as well. In
> general, however, the internals are more different then the user
> code shows. That makes your propos
* Yuval Kogman ([EMAIL PROTECTED]) [060808 01:04]:
> The CPAN has many reinvented wheels. This happened since we have so
> many authors (== opinions) over so many years.
>
> For example, we have Mail::Message to Email::Simple, to
> Mail::Internet to They all do the same thing differently.
Som
19 matches
Mail list logo
