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
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 new
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, because
you
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 class I
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 call.
[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
because the
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 searches of the
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 need a bit of a refresher
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 the class
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
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 = $a
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
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 confuse
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 case.
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
sides
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't have to retype it
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 equivalent to
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 functions
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
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
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 is.
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 way we do
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::Name::Ugh;
class
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?
Yes. You
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
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
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 names like
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
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 what I
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):
class Date is
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 $date =
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 than
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
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 thinking a
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,
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
that
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 the
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 going on
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 this will be
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... what do you mean
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,
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...
my Date
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
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 get
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
: to
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 possible
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
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
48 matches
Mail list logo
