Perl is worse!

[David Bolen]

grey at despair.rpglink.com (Steve Lamb) writes:

> On 28 Jul 2000 16:49:31 GMT, gbreed at cix.compulink.co.uk
> <gbreed at cix.compulink.co.uk> wrote:
> >?  You said it was only declared to "get the name space in there".
> 
>     Yup.  "I'm going to use a, for what I know not.  Could be string, could be
> integer, could be whatever I want."  The point was defining the name and
> assiciate it with nothing.  But since the type is inferred on first use might
> as well have the C declarations.

I don't think I agree with "the type is inferred on first use" as far
as Python's behavior.  Nothing is really inferred - the type of an
object is always explicit in the object itself.

This is, however, quite different from the name used to reference the
object, which has no type in and of itself.  So something like "a =
None" places a reference in the namespace (a) for the object "None".
The object None is an explicit object with an explicit type (just as
any object would be).

If you don't know what objects you might want to refer to eventually
with "a", that's fine - just don't bother defining a until you know,
and at the point at which you associate a with an object, then that
object will have an explicit type.  But that still won't affect a, as
far as a will still not have any type relationship.

In the case here it seems as if you don't really want to define the
name and associate it with nothing, you want to define the name and
associate it with an object that will support being appended to.  In
such a case, the notation "a = []" as suggested in other responses is
proper.  That associates a with a new sequence object (which you start
as empty) which supports the operations you are going to wish to
perform.

Or conversely, you could be asking to really have no definition for a,
but have the language implicitly create a new object upon your first
attempt to use an ".append" method - something which I don't think is
really either intuitive or something that works in the general case
for an object oriented model.

(Oh, and as an aside - this is an impressive thread - even with the
few warts, I think there's useful information going on)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/