At 6:35 PM + 1/13/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 1:10 PM + 1/6/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
An object is a data type, as much as an array or hash is a data type,
but that doesn't make an array an object. [ins
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 1:10 PM + 1/6/03, Piers Cawley wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> writes:
>>> An object is a data type, as much as an array or hash is a data type,
>>> but that doesn't make an array an object. [insert obligatory "all men
>>> are Socrates
Damian Conway <[EMAIL PROTECTED]> writes:
> attriel wrote:
>
>> AssignmentOK?Because...
>> ========
>> my Basket $c = $a no $c's type: Basket (of Object)
>>
attriel wrote:
AssignmentOK?Because...
========
my Basket $c = $a no $c's type: Basket (of Object)
X ^
On Wed, Jan 08, 2003 at 05:59:14PM +0800, Damian Conway wrote:
> > my Array @array := SpecialArray.new;
> >
> > Should the value in @array act like an Array or a SpecialArray? Most
> > people would say SpecialArray, because a SpecialArray ISA Array.
>
> Weell...*I'd* say that @array shoul
At 2:08 PM + 1/9/03, Peter Haworth wrote:
On Wed, 8 Jan 2003 15:39:52 -0500, Dan Sugalski wrote:
At 7:29 PM -0700 1/7/03, John Williams wrote:
>Perhaps you could explain how the $0 object will work in your mind.
>A5 assert that $0 is a object, and it behaves as an array and a hash,
>depen
> my Set of Apple $a;
> my Basket of Fruit $b;
>
> and a generic assignment:
>
> $c = $a;
> $c = $b;
>
> Now we can fill in your list (which is somewhat expanded):
>
AssignmentOK?Because...
=======
On Thu, 9 Jan 2003, Peter Haworth wrote:
> On Wed, 8 Jan 2003 15:39:52 -0500, Dan Sugalski wrote:
> > At 7:29 PM -0700 1/7/03, John Williams wrote:
> > >Perhaps you could explain how the $0 object will work in your mind.
> > >A5 assert that $0 is a object, and it behaves as an array and a hash,
>
On Wed, 8 Jan 2003 15:39:52 -0500, Dan Sugalski wrote:
> At 7:29 PM -0700 1/7/03, John Williams wrote:
> >Perhaps you could explain how the $0 object will work in your mind.
> >A5 assert that $0 is a object, and it behaves as an array and a hash,
> >depending on how you subscript it. Typeglobs are
Rafael Garcia-Suarez asked:
> Damian Conway <[EMAIL PROTECTED]> wrote:
>
>>There are in fact *two* types associated with any Perl variable
>
> How does it work regarding inheritance and polymorphism ?
> E.g. consider
> my @a is Set of Apple;
> my @b is Basket of Fruit;
> with Apple isa Fruit,
At 7:29 PM -0700 1/7/03, John Williams wrote:
On Tue, 7 Jan 2003, Dan Sugalski wrote:
>2. There is a primitive "array" type that is promoted to an
>objectified Array class when needed. This would be analogous
>to the int/Int distinction for primitive numbers. This would be
>visible to progra
[EMAIL PROTECTED] (Brent Dax) writes:
> Is that clear enough, or should I say it a little slower?
Clear as it's going to get, I fear.
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
Simon Cozens:
# [EMAIL PROTECTED] (Damian Conway) writes:
# > There are in fact *two* types associated with any Perl variable:
#
# Is there any chance we could make this a little more
# confusing? One or two people still appear to be following you.
I'll make it a little simpler. If A is the typ
[EMAIL PROTECTED] (Damian Conway) writes:
> There are in fact *two* types associated with any Perl variable:
Is there any chance we could make this a little more confusing? One or
two people still appear to be following you.
--
You advocate a lot of egg sucking but you're not very forthcoming wi
Damian Conway <[EMAIL PROTECTED]> wrote:
>
> There are in fact *two* types associated with any Perl variable:
>
> 1. Its "storage type" (i.e. the type(s) of value it can hold)
> This is specified before the variable or after an C or C.
> It defaults to Scalar.
>
>
On Tue, 07 Jan 2003 12:21:48 +0100, Rafael Garcia-Suarez wrote:
> Delegation has drawbacks compared to inheritance : you can't use
> a object that delegates to class Foo where an instance of Foo is
> expected.
That sounds more like a problem with the polymorphism implementation than an
argument a
John Williams wrote:
I'm still not buying the autoinstantiation argument. All the other
(non-M.L.) threads I have read are requiring
my $a is Foo = .new; # or some such...
Yes. You're confusing auto-instantiation of *implementation type* (good)
with autoinstantiation of *stored value* (bad
One of the wise may override my evaluation,
Or I could do it. ;-)
Can the type of a variable vary independenty of its value?
My understanding is that the type of a variable merely restricts the type
of value you can assign to it. (Well, it probably does more, but I'm not
clear on what or h
At 12:21 PM +0100 1/7/03, Rafael Garcia-Suarez wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Like I said, you can always use delegation to subclass an array,
or limit yourself to an odd and restrictive subset of behaviour.
(Basically just vtable method overriding)
Delegation has drawbacks c
On Mon, 6 Jan 2003, Michael Lazzaro wrote:
> So we're using "is Blah" here as a method of creating an
> already-instantiated object, not just typing a variable(?) But that,
> in turn, would imply that:
>
> my Foo $a; # declares $a as holding objects of type C
> my $a is Foo; # instan
On Tue, 7 Jan 2003, Dan Sugalski wrote:
>
> >2. There is a primitive "array" type that is promoted to an
> >objectified Array class when needed. This would be analogous
> >to the int/Int distinction for primitive numbers. This would be
> >visible to programmers, but may be acceptable for the same
>
At 9:47 AM -0800 1/6/03, Dave Whipp wrote:
"Piers Cawley" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Dan Sugalski <[EMAIL PROTECTED]> writes:
> An object is a data type, as much as an array or hash is a data type,
> but that doesn't make an array an objec
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Like I said, you can always use delegation to subclass an array,
> or limit yourself to an odd and restrictive subset of behaviour.
> (Basically just vtable method overriding)
Delegation has drawbacks compared to inheritance : you can't use
a object that
[EMAIL PROTECTED] (Simon Cozens) writes:
> they arrays?
Bluh, I mean objects. Getting carried away; this is something I do actually
care about, and I'll be quite unhappy if we screw it up.
--
The Blit is a nice terminal, but it runs emacs.
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Nothing, the impractical part is making arrays objects--they aren't,
Hang on. We're saying that they should be. You're saying that they're
not. You haven't produced any reasons *WHY* they're not. Why *aren't*
they arrays?
It's perfectly practical; most o
At 10:54 AM + 1/7/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
The short answer, I suppose, is that we're not recreating
Smalltalk--at least some small nod is being made towards Practicality.
I really don't follow your argument here.
What's impractical about being abl
[EMAIL PROTECTED] (Dan Sugalski) writes:
> The short answer, I suppose, is that we're not recreating
> Smalltalk--at least some small nod is being made towards Practicality.
I really don't follow your argument here.
What's impractical about being able to inherit from Arrays?
--
Familiarity bre
At 9:30 AM + 1/7/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
Well, you'll certainly be able to use delegation to get in the way if
nothing else. Beyond that I'm not sure, but anything that's not based
on the parrot Object PMC (which we've not quite yet defined) won't
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> These lines all declare @a to be an array that stores ints. That
> would imply that the "is Array" part is actually instantiating
> (Cing) the array... you're not saying that @a "can someday
> hold an array obj", you're saying it already _is_ an arr
"Piers Cawley" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> > An object is a data type, as much as an array or hash is a data type,
> > but that doesn't make an array an object. [insert obligatory "all men
> > are Soc
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Well, you'll certainly be able to use delegation to get in the way if
> nothing else. Beyond that I'm not sure, but anything that's not based
> on the parrot Object PMC (which we've not quite yet defined) won't
> necessarily be directly inheritable from.
At 1:10 PM + 1/6/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
An object is a data type, as much as an array or hash is a data type,
but that doesn't make an array an object. [insert obligatory "all men
are Socratese" quote here)
I really hope you're wrong here Dan. At
On Friday, January 3, 2003, at 01:19 PM, Dave Whipp wrote:
Conversly, an C operation should be nothing more than
$obj = new ArrayLikeThing;
@a := $obj; # the tie
I was under the impression that a more concise way of saying that would
be:
my @a = new ArrayLikeThing;
-or-
my @a is
Dan Sugalski <[EMAIL PROTECTED]> writes:
> An object is a data type, as much as an array or hash is a data type,
> but that doesn't make an array an object. [insert obligatory "all men
> are Socratese" quote here)
I really hope you're wrong here Dan. At least in that particular
case. Being able to
At 8:43 PM + 1/5/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
> I am taking the viewpoint that "everything is in object".
Then you'll likely be somewhat surprised at times.
Can you elucidate?
(I admit to be very tempted to answer this "Yes" and leave it at that...
[EMAIL PROTECTED] (Dan Sugalski) writes:
> > I am taking the viewpoint that "everything is in object".
>
> Then you'll likely be somewhat surprised at times.
Can you elucidate?
--
Ah the joys of festival + Gutenburg project. I can now have
Moby Dick read to me by Stephen Hawking.
On Fri, 3 Jan 2003, Dave Whipp wrote:
> John Williams wrote:
>
> > Do they? One is obviously an array, and one is obviously a scalar.
> > You may get an error (cannot alias an array as a scalar) or $b get aliased
> > to the array-in-scalar-context (a reference).
>
> This is one of those "how we th
At 1:19 PM -0800 1/3/03, Dave Whipp wrote:
I am taking the viewpoint that "everything is in object".
Then you'll likely be somewhat surprised at times.
--
Dan
--"it's like this"---
Dan Sugalski
[EMAIL PROTECTED] (Dave Whipp) writes:
> am taking the viewpoint that "everything is in object". A number is an
> object; an array is an object, a hash is in object. The only thing
> that differs is that they implement different interfaces.
>
> Perl6 provides syntaxes for those interfaces. $a and
John Williams wrote:
Do they? One is obviously an array, and one is obviously a scalar.
You may get an error (cannot alias an array as a scalar) or $b get aliased
to the array-in-scalar-context (a reference).
This is one of those "how we think about the fundamentals" things. I am
taking the v
One of the wise may override my evaluation, but...
On Thu, 2 Jan 2003, Dave Whipp wrote:
> Can the type of a variable vary independenty of its value?
My understanding is that the type of a variable merely restricts the type
of value you can assign to it. (Well, it probably does more, but I'm no
Dave Whipp wrote:
>print @a + $b
>
> This will evaluate each, in numeric context. To get at those numbers,
> Perl will translate this to something like
>
>print @a.FETCHSIZE + $b.FETCHNUM
I thought[*0] that Larry said arrays in a scalar context are now treated
as array references, so ac
Can the type of a variable vary independenty of its value?
Consider the following:
my @a = (1,2,3);
my $b := @a;
@a and $b both refer to the same object. $b's object has methods such as
PUSH, POP, etc, as does @a's.
So the type of the value (object) is the same in each case, but the
vari
43 matches
Mail list logo
