Re: Variable Types Vs Value Types
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 inherit from Array or Hash or whatever as a neater way of implementing, say, Tie semantics would be remarkably useful...
Re: AW: nag Exegesis 2
On Sat, 4 Jan 2003, Luke Palmer wrote: > From: Luke Palmer <[EMAIL PROTECTED]> > > is a fatal error. I could argue for this to change, as to support > better readability (and it would). It's obvious WIM, so why doesn't it > DWIM (disclaimer: cannot be used as an argument for arbitrary features. > Is not a slogan. I repeat, is not a slogan. :) ? But it has such a Johnnie Cochran sound to it: "It's obvious WIM, you must DWIM". Language design by catch phrase... -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Variable Types Vs Value Types
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 ArrayLikeThing .= new;
Where ArrayLikeThing must inherit from, or at least present the same
interface as, the built-in Array (array?) type. But that, in turn,
should just be equiv to:
my @a is ArrayLikeThing;
Oof. There might be a big problem here. If we work backward from
previously stated examples:
my int @a;# these should all be identical, right?
my @a returns int;
my @a is Array of int;
my @a is Array returns int;
my int @a is Array;
Here we're using "is" not as a property marker, but meaning "isa".
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 array obj.
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; # instantiates $a as a C.
Oh dear. That looks quite wrong.
BUT we *need* to be able to explicitly say "is Array", or something
like it, if we're to be able to easily make alternate implementations
of arrays:
class MyArray is Array {
... stuff overriding the default behavior...
}
my @a is MyArray; # Boom! No C needed, ever!
or if we're to make complex constructs like:
my @a is Array of Array of Hash of str;
It also could be a cornerstone of classless OO:
my $obj is $parent;
So there appears to be either a flaw in my logic, in my syntax, or in
something bigger. Given that p6d is supposed to start working on
Arrays, I think we (or at least I) need some clarification...
MikeL
Re: Variable Types Vs Value Types
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 least in that particular case. Being able to inherit from Array or Hash or whatever as a neater way of implementing, say, Tie semantics would be remarkably useful... 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. Doesn't mean you won't be able to build your own custom PMC types based on existing PMC types, but I'm not really sure I'd consider that OO or inheritance as such. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
