At 9:47 AM -0800 1/6/03, Dave Whipp wrote:
That's sort of like saying that a pointer or a double is an optimization beyond the general object. (Or, more succinctly, "No" :)"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 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 remarkablyuseful... Let me suggest two interpretations of Dan's remark that seem reasonable to me: 1. The internal implementation for an array is an optimization beyond that of a generic object. This would not be visible to the programmer, so isn't important wrt the language.
Not unless Larry really insists. "Primitive" arrays aren't sub-, super-, or side-classes of objects--they aren't objects at all. (They're arrays, hence the name "array") You may be able to treat them in some ways as objects, but that doesn't make them objects any more than treating arrays like integers makes them integers.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 reason as the int/Int types are.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
