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 Socratese quote here)
I
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. [insert
attriel wrote:
AssignmentOK?Because...
========
my Basket $c = $a no $c's type: Basket (of Object)
X ^
Damian Conway [EMAIL PROTECTED] writes:
attriel wrote:
AssignmentOK?Because...
========
my Basket $c = $a no $c's type: Basket (of Object)
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, and Basket
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 gone,
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,
HUGE chungs of stuff cut
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...
==
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,
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 should act
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
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*
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
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 Cof or Creturns.
It defaults to Scalar.
[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
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
[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.
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
--- 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
(Cnewing) the array... you're not saying that @a can someday
hold an array obj, you're saying it already _is_ an array
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
[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
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
[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
[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.
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
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 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
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
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
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 think about
[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?
--
Halfjack Ah the joys of festival + Gutenburg project. I can now have
Moby Dick read to me by Stephen Hawking.
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... :)
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
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
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
35 matches
Mail list logo
