At 7:48 PM -0400 9/3/02, Miko O'Sullivan wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
>> How about a JPEG object? Might take a string with the image data, an
>> array with byte data, a filehandle that's got the data to it.
>
>But those situations are all covered by the #= concept:
We call t
> my Date $date .= new('June 25, 2002');
If we're assuming that C creates an C
object, then that object should be able to overload its assignment operator.
I don't know what the perl6 syntax will be, but something along the lines of
class Date
{
method operator= ($value is rx//)
{
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> How about a JPEG object? Might take a string with the image data, an
> array with byte data, a filehandle that's got the data to it.
But those situations are all covered by the #= concept: call the new method
passing the right argument. So for a JPEG th
At 6:03 PM -0400 9/3/02, [EMAIL PROTECTED] wrote:
>From: Dan Sugalski [EMAIL PROTECTED]
>> This will potentially get out of hand quickly
>
>I don't think this is a case where out-of-hand-generalization is necessary.
>I'm only saying that there could be a handy shorthand for a single very
>common
Damian Conway:
# Though I expect he probably will, since treating classes as
# "first class" entities in Perl 6 implies that capability
# (amongst many others).
I fear we're treading a little too close to classes being the "new
filehandles"--relatively limited entities with no sigils that confu
From: Dan Sugalski [EMAIL PROTECTED]
> This will potentially get out of hand quickly
I don't think this is a case where out-of-hand-generalization is necessary.
I'm only saying that there could be a handy shorthand for a single very
common case. Nevertheless, I'll simplify the proposal. Oh, and
On Tue, Sep 03, 2002 at 04:04:13PM -0400, [EMAIL PROTECTED] wrote:
> Looks pretty groovy to me too. It looks like the .=
> operator, no longer being employed as a string appender,
> now means "use the class I just mentioned".
Er, not quite. It's just like the other X= operators:
$a
> On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>
> >> my Date $date .= new('Jun 25, 20002');
> >
> > H. That's a very interesting idea.
> > I like it.
>
> Looks pretty groovy to me too. It looks like the .=
> operator, no longer being employed as a string appender,
> no
At 4:21 PM -0400 9/3/02, [EMAIL PROTECTED] wrote:
>From: Trey Harris [EMAIL PROTECTED]
>> no strict 'refs';
>> my Date $date;
>> $date .= 'Sep 21, 1963';
>>
>> There is a method name there--'Date::Sep 21, 1963'.
>
>But that's my point. You wouldn't have to put the method name or t
Trey Harris wrote:
> In a message dated Tue, 3 Sep 2002, Buddha Buck writes:
>
>>I suspect that, if it makes sense to say
>>
>>$foo = &$date.method;
>>
>>then it would also make sense to say
>>
>>$date .= $foo;
>>
>>as well.
>
>
> Interesting, that first line
> $foo = &$date.method;
>
> I ne
In a message dated Tue, 3 Sep 2002, Buddha Buck writes:
> I suspect that, if it makes sense to say
>
> $foo = &$date.method;
>
> then it would also make sense to say
>
> $date .= $foo;
>
> as well.
Interesting, that first line
$foo = &$date.method;
I need a bit of a refresher here, as my searc
[EMAIL PROTECTED] wrote:
> From: Trey Harris [EMAIL PROTECTED]
>
>>no strict 'refs';
>> my Date $date;
>> $date .= 'Sep 21, 1963';
>>
>>There is a method name there--'Date::Sep 21, 1963'.
>
>
> But that's my point. You wouldn't have to put the method name or the
class
> be
From: Trey Harris [EMAIL PROTECTED]
> no strict 'refs';
> my Date $date;
> $date .= 'Sep 21, 1963';
>
> There is a method name there--'Date::Sep 21, 1963'.
But that's my point. You wouldn't have to put the method name or the class
because the compiler would understand what to ca
In a message dated Tue, 3 Sep 2002, [EMAIL PROTECTED] writes:
> On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>
> >> my Date $date .= new('Jun 25, 20002');
> >
> > H. That's a very interesting idea.
> > I like it.
>
> Looks pretty groovy to me too. It looks like the .=
> o
On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>> my Date $date .= new('Jun 25, 20002');
>
> H. That's a very interesting idea.
> I like it.
Looks pretty groovy to me too. It looks like the .=
operator, no longer being employed as a string appender,
now means "use the cla
In a message dated Tue, 3 Sep 2002, Trey Harris writes:
> > So what again is wrong with:
> >
> > my Date $date = 'June 25, 2002';
>
> Nothing--if Date is tieable and implements a STORE method which
> instantiates a new object.
Well, now that I re-read my own comments, I have to retract this, beca
In a message dated Tue, 3 Sep 2002, Garrett Goebel writes:
> Don't the following statements have identical meaning?
>
> my Date $date;
> my Date $date = Date->new();
Not at all. The first declares that $date is a variable containing Date
objects, the second does the same, plus instantiates a ne
From: Damian Conway
> But I must say I now like Adam's
>
> my Date $date .= new('June 25, 2002');
>
> much more than my own proposal.
This thread appears to have wound down, but I'm still a little confused. I
understand the above syntax could be used to pass initialization data to the
con
On Monday, September 2, 2002, at 10:00 AM, Damian Conway wrote:
> No, I never said (nor intended to imply) that. Note that I carefully
> avoided the
> word "alias" in my description of this technique. ;-)
That was my doing. Sorry folks.
David
--
David Wheeler
On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>> my Date $date .= new('Jun 25, 20002');
>
> H. That's a very interesting idea.
> I like it.
Hallelujah! I like it, too! It's only one character more than my
original suggestion!
Regards,
David
--
David Wheeler
Mike Lambert wrote:
> class Date is Really::Long::Package::Name::Ugh;
>
> class DateManipulator;
> our Date $date2manip;
> ...date manip methods here...
>
> An external class is thus unable to do:
> $DateManipulator::date2manip = new Really::Long::Package::Name::Ugh()
>
> Is that correct?
Ye
Damian Conway wrote:
> Trey Harris wrote:
>
> > An alias? Isn't
> >
> > class Date is Really::Long::Package::Name::Ugh;
> >
> > a new class declaration, declaring 'Date' as a subclass of
> > Really::Long::Package::Name::Ugh?
>
> Yes. It's not an alias.
class Date is Really::Long::Package::Nam
At 4:01 PM +0100 8/29/02, Nicholas Clark wrote:
>On Thu, Aug 29, 2002 at 07:52:42AM -0700, Steve Canfield wrote:
>> From: Dan Sugalski [EMAIL PROTECTED]
>> >I actually had something a bit more subversive
>> >in mind, where the assignment operator for the
>> >Date class did some magic the same
Nicholas Clark wrote:
> So, based on what I remember about variables, would
>
> class Date := Really::Long::Package::Name::Ugh;
>
> express aliasing of classes?
By analogy to:
my $date := $really::long::variable::name::ugh;
yes.
If Larry allows aliasing of classnames at all, that
Trey Harris wrote:
> An alias? Isn't
>
> class Date is Really::Long::Package::Name::Ugh;
>
> a new class declaration, declaring 'Date' as a subclass of
> Really::Long::Package::Name::Ugh?
Yes. It's not an alias.
> it will have a similar effect to aliasing Really::Long::Package::Name::Ugh
Graham Barr wrote:
> I would say it is not always redundant to specify the type on both
> sides
>
> my Dog $dog = Greyhound.new('black');
Sure. But it's the redundant case we were trying to simplify.
>>And, furthermore, that you could easily define special semantics
>>for void-context con
Adam D. Lopresto wrote:
> That's pretty close to what I was thinking of, but I don't think the
> constructors actually have to be special. What if "my Date $date;" lets the
> compiler know that $date belongs to the Date class, even if it's undef? If
> that's the case you could call static funct
On Mon, Sep 02, 2002 at 04:40:14AM -0400, Trey Harris wrote:
> An alias? Isn't
>
> class Date is Really::Long::Package::Name::Ugh;
>
> a new class declaration, declaring 'Date' as a subclass of
> Really::Long::Package::Name::Ugh? Because the class body is empty, i.e.
> this line is equivale
In a message dated 1 Sep 2002, Uri Guttman writes:
> > "DW" == David Wheeler <[EMAIL PROTECTED]> writes:
>
> DW> On Sunday, September 1, 2002, at 05:30 AM, Damian Conway wrote:
> >> Sure. But the right solution is to permanently eliminate the
> >> sesquipedalian
> >> name (so you don
On Sat, Aug 31, 2002 at 01:52:18PM +, Damian Conway wrote:
> I'd suggest that redundancy in syntax is often a good thing and
> that there's nothing actually wrong with:
>
> my Date $date = Date.new('June 25, 2002');
I would say it is not always redundant to specify the type on both
sid
> "DW" == David Wheeler <[EMAIL PROTECTED]> writes:
DW> On Sunday, September 1, 2002, at 05:30 AM, Damian Conway wrote:
>> Sure. But the right solution is to permanently eliminate the
>> sesquipedalian
>> name (so you don't have to retype it for every single typed variable):
>>
> And, furthermore, that you could easily define special semantics
> for void-context constructor calls via undef'd but typed variables,
> so that you could just write:
>
> (my Date $date).new('June 25, 2002');
>
> and have the interpreter autovivify the object.
That's pretty close to wha
On Sunday, September 1, 2002, at 05:30 AM, Damian Conway wrote:
> Sure. But the right solution is to permanently eliminate the
> sesquipedalian
> name (so you don't have to retype it for every single typed variable):
>
> class Date is Really::Long::Package::Name::Ugh;
Oh, that's nice. As
David Wheeler wrote:
> Yes, but this:
>
>my Really::Long::Package::Name::Ugh $date is now {.init 'June 25,
> 2002' };
>
> Is shorter than this:
>
> my Really::Long::Package::Name::Ugh $date =
>Really::Long::Package::Name::Ugh.new( 'June 25, 2002' );
>
> It's not the short package nam
On Saturday, August 31, 2002, at 06:52 AM, Damian Conway wrote:
> my Date $date = Date.new('June 25, 2002');
>
>> my Date $date is now { .init 'June 25, 2002' };
>
> As is that.
Yes, but this:
my Really::Long::Package::Name::Ugh $date is now {.init 'June 25,
2002' };
Is shorter
Larry wrote:
> :my $date = Date.new('June 25, 2002');
>
> Assignment is wrong for conferring compile-time properties, I think.
Agreed. For a start, it's too late. The declaration is compile-time;
the assignment, run-time.
> We almost need some kind of topicalization:
>
> my Date $d
On Thu, Aug 29, 2002 at 07:52:42AM -0700, Steve Canfield wrote:
> From: Dan Sugalski [EMAIL PROTECTED]
> >I actually had something a bit more subversive
> >in mind, where the assignment operator for the
> >Date class did some magic the same way we do
> >now when we do math on strings.
>
> I was t
From: Dan Sugalski [EMAIL PROTECTED]
>I actually had something a bit more subversive
>in mind, where the assignment operator for the
>Date class did some magic the same way we do
>now when we do math on strings.
I was thinking a simple general purpose rule. If the variable is
typed, and its class
At 5:19 PM -0700 8/28/02, Larry Wall wrote:
>On Thu, 29 Aug 2002, Steffen Mueller wrote:
>: Nicholas Clark wrote:
>: [...]
>: > If the compiler were able to see that my Date $bday = 'June 25, 2002';
>: > is one statement that both types $bday as Date, and then assigns a
>: > constant to it, is it
On Thu, 29 Aug 2002, Steffen Mueller wrote:
: Nicholas Clark wrote:
: [...]
: > If the compiler were able to see that my Date $bday = 'June 25, 2002';
: > is one statement that both types $bday as Date, and then assigns a
: > constant to it, is it possible to do the conversion of that constant
: >
Nicholas Clark wrote:
[...]
> If the compiler were able to see that my Date $bday = 'June 25, 2002';
> is one statement that both types $bday as Date, and then assigns a
> constant to it, is it possible to do the conversion of that constant
> to a constant $bday object at compile time? (and hence
On Wednesday, August 28, 2002, at 09:56 AM, Larry Wall wrote:
> my Date $date { 'June 25, 2002' };
>
> Either way, this makes data declarations more like sub declarations
> in syntax, though the semantics of what you do with the final closure
> when are obviously different. That is, for ord
At 5:29 PM +0100 8/28/02, Nicholas Clark wrote:
>On Wed, Aug 28, 2002 at 12:17:55PM -0400, Dan Sugalski wrote:
>> At 10:36 AM +0200 8/28/02, [EMAIL PROTECTED] wrote:
>> > >> Will there be automatic calling of the deserialization method
>> >>> for objects, so that code like this DWIMs...
>> >
On Wed, 28 Aug 2002, David Wheeler wrote:
: I have to agree with this. Ideally, IMO, there'd be some magic going on
: behind the scenes (maybe with a pragma?) that automatically typed
: variables so we wouldn't have to be so redundant, the code would look
: more like (most) Perl 5 OO stuff, and
On Wed, Aug 28, 2002 at 12:17:55PM -0400, Dan Sugalski wrote:
> At 10:36 AM +0200 8/28/02, [EMAIL PROTECTED] wrote:
> > >> Will there be automatic calling of the deserialization method
> >>> for objects, so that code like this DWIMs...
> >
> >>> my Date $bday = 'June 25, 2002';
> >
> >> Err..
At 10:36 AM +0200 8/28/02, [EMAIL PROTECTED] wrote:
> >> Will there be automatic calling of the deserialization method
>>> for objects, so that code like this DWIMs...
>
>>> my Date $bday = 'June 25, 2002';
>
>> Err... what do you mean it to do?
>
>Wow, this is nice. He means (I think) that t
On Wednesday, August 28, 2002, at 06:11 AM, [EMAIL PROTECTED]
wrote:
> Is there some kind of third option? I have to admit I've always found
> Java
> commands like "Date bday = new Date('June 25, 2002')" somehow
> redundant.
I have to agree with this. Ideally, IMO, there'd be some magic goi
>From: [EMAIL PROTECTED]
>> Wow, this is nice. He means (I think) that this will be translated into
>> my Date $bday = Date->new('June 25, 2002');
I don't think this is going to work. First off, there
is no predefined constructor name in Perl. Secondly,
you can have multiple constructors in t
From: [EMAIL PROTECTED]
> Wow, this is nice. He means (I think) that this will be translated into
> my Date $bday = Date->new('June 25, 2002');
I rather like it too, but it hinges on how strictly typing is enforced. If
typing is strictly enforced then it works because the VM can always know
th
>> Will there be automatic calling of the deserialization method
>> for objects, so that code like this DWIMs...
>> my Date $bday = 'June 25, 2002';
> Err... what do you mean it to do?
Wow, this is nice. He means (I think) that this will be translated into
my Date $bday = Date->new('June 25
On Tue, Aug 27, 2002 at 02:50:27PM -0700, Steve Canfield wrote:
> Will there be automatic calling of the deserialization method for objects,
> so that code like this DWIMs...
>
> my Date $bday = 'June 25, 2002';
What sort of dwimmery do you desire?
It's my understanding that variable declara
On Tue, Aug 27, 2002 at 02:50:27PM -0700, Steve Canfield wrote:
> Will there be automatic calling of the deserialization method for objects,
> so that code like this DWIMs...
>
> my Date $bday = 'June 25, 2002';
Err... what do you mean it to do?
--
Michael G. Schwern <[EMAIL PROTECTED]>
Will there be automatic calling of the deserialization method for objects,
so that code like this DWIMs...
my Date $bday = 'June 25, 2002';
_
Send and receive Hotmail on your mobile device: http://mobile.msn.com
53 matches
Mail list logo
