bremner@cpsc.ucalgary.ca (David Bremner) (03/22/89)
I am using ParcPlace Smalltalk-80 Version 2.3 on apollo domain SR10 Suppose I have the class declaration: Object subclass: #Test instanceVariableNames: 'foo' classVariableNames: 'Bar' ... "rest of keywords irrellevant" then the following is a legal method ----------------------- aMethod "testing smalltalk variable scoping" | Bar | ----------------------- But the following is not ------------------------ aMethod "testing smalltalk variable scoping" | foo | ------------------------ generating the error | Name already defined -> foo | What is going on here? Is this the way scoping is defined in the language? If so, where? ----------- BITNET: Bremner@UNCA-MULTICS.BITNET USENET: bremner@ksi.cpsc.ucalgary.ca
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (03/27/89)
<"Would you like me to summon Data so he could offer a few dozen synonyms?"> In article <935@cs-spool.calgary.UUCP>, bremner@cpsc.ucalgary.ca (David Bremner) writes: > Object subclass: #Test > instanceVariableNames: 'foo' > classVariableNames: 'Bar' > ... "rest of keywords irrelevant" ... (I've abbreviated the rest of the message) > aMethod > "testing smalltalk variable scoping" > | Bar | "this works" > anotherMethod > "testing smalltalk variable scoping" > | foo | "this doesn't work; Name already defined -> foo" Smalltalk is trying to do you a favor; it doesn't want you to lose access to your instance variable. Names beginning with capital letters are shared. I'm not quite sure what your implementation did with a shared temporary variable. IMHO, it goofed by not forbidding it. >Bremner@UNCA-MULTICS.BITNET, bremner@ksi.cpsc.ucalgary.ca Paul S. R. Chisholm, AT&T Bell Laboratories, att!pegasus!psrc psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
bremner@cpsc.ucalgary.ca (David Bremner) (03/27/89)
Hmm, yes, but are you saying it goofed in A) Allowing me a capitalized temporary variable? The capitalization of Class/Global variables is a convention in PPS Smalltalk, but can be overridden. B) Allowing me to lose access to one of my class variables, when, as you pointed out, it doesn't allow me to hide an instance variable? Sorry if this seems trivial, but I'm in the process of writing a pidgin Smalltalk compiler. ----------- BITNET: Bremner@UNCA-MULTICS.BITNET USENET: bremner@ksi.cpsc.ucalgary.ca
warner@s3snorkel.ARPA (Ken Warner) (03/28/89)
Along the same lines, how does one find out the super-class so that one can access the super class-pool variables without explicitly stateing the name of the super class. I recently had to do this and I couldn't figure out how to do this without hard-wireing the name of the super-class. The message; super class is the same as; self class. Ken Warner
elt@entire.UUCP (Edward L. Taychert) (03/29/89)
In article <1721@scubed.UUCP>, warner@s3snorkel.ARPA (Ken Warner) writes: > Along the same lines, how does one find out the super-class so that one can > access the super class-pool variables without explicitly stateing the name of > the super class. Try self class superclass to get the name of the superclass, Don't have a clue on how to get at its class-pool though. Ed Taychert ...!rochester!rocksanne!entire!elt
alan@rnms1.paradyne.com (0000-Alan Lovejoy(0000)) (03/29/89)
In article <1721@scubed.UUCP< warner@s3snorkel.UUCP (Ken Warner) writes:
<Along the same lines, how does one find out the super-class so that one can
<access the super class-pool variables without explicitly stateing the name of
<the super class. I recently had to do this and I couldn't figure out how to do
<this without hard-wireing the name of the super-class.
<
<The message;
<super class
<is the same as;
<self class.
Try "self superclass." (Or is it "self class superclass"?)
Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.
Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me.
__American Investment Deficiency Syndrome => No resistance to foreign invasion.
Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.johnson@p.cs.uiuc.edu (03/29/89)
From Ken Warner: >How does one find out the super-class so that one can access the super >class-pool variables without explicitly stateing the name of the super class? Various people answered that "self class superclass" would give you the superclass of an object's class. This might be the direct answer, but it might not be answering the real question. I don't see why there can be any problem in accessing pool variables, and wonder if Ken isn't trying to access some other kind of variables. Subclasses use the exact same copies of class variables as the superclass that defines the variables. I think that pool variables are also inherited, so they shouldn't be a problem either. Therefore, I think that Ken must be talking about class instance variables. Class variables are really just global variables whose name is only accessible to a particular class and its subclasses. However, since classes are objects, they have instance variables, and class instance variables are instance variables declared specially for a class. Subclasses inherit the class instance variable definitions, but each class object has its own copy of the variable. If you want to access the instance variable of a superclass then you have to send a message to the superclass. However, which superclass? It might reallly be defined in the superclass of your superclass's supeclass, and you should use a technique that won't break when more classes are added. Here is a technique that is not too awful. Suppose that class X defines a class instance variable v. Define a class method in X to access v by v self == X ifTrue: [^v] ifFalse: [^self superclass v] This method is a little ugly because it accesses X directly, but then it is defined in X and only has to be defined once, so it isn't all that bad. It is much better than writing code in dozens of places that accesses X. Ralph Johnson
hmm@laura.UUCP (Hans-Martin Mosner) (03/30/89)
In article <3350@entire.UUCP> elt@entire.UUCP (Edward L. Taychert) writes: >In article <1721@scubed.UUCP>, warner@s3snorkel.ARPA (Ken Warner) writes: >Try > self class superclass > >to get the name of the superclass, >Don't have a clue on how to get at its class-pool though. What about self class superclass classPool I LIKE unary messages :-) Hans-Martin -- Hans-Martin Mosner | Don't tell Borland about Smalltalk - | hmm@unido.{uucp,bitnet} | they might invent Turbo Smalltalk ! | ------------------------------------------------------------------------ Disclaimer: Turbo Smalltalk may already be a trademark of Borland...
khaw@pplace.COM (Mike Khaw) (03/30/89)
<3350@entire.UUCP>, by elt@entire.UUCP (Edward L. Taychert):
- In article <1721@scubed.UUCP>, warner@s3snorkel.ARPA (Ken Warner) writes:
-> Along the same lines, how does one find out the super-class so that one can
-> access the super class-pool variables without explicitly stateing the name of
-> the super class.
-
- Try
-
- self class superclass
-
- to get the name of the superclass,
- Don't have a clue on how to get at its class-pool though.
Class "Class" implements the methods "sharedPools" and "allSharedPools",
which respond with a Set of the names of the pools that are specified
in the receiver or in the receiver and all its superclasses, respectively
(cf. Goldberg and Robson, Smalltalk-80: The Language and Its Implementation,
p 276).
Each pool is a Dictionary, so once you know the name of a pool, you can
send the pool the message "keys", which responds with a Set of the names
of its keys.
Mike Khaw
ParcPlace Technical Support
--
E-Mail: Internet=khaw@parcplace.com, UUCP={uunet,sun,decwrl}!pplace!khaw
USPS: Parcplace Systems, Inc., 2400 Geng Road, Palo Alto, CA 94303
Phone: (415) 859-1052goldfain@osiris.cso.uiuc.edu (03/31/89)
] Written 9:13 am Mar 29, 1989 by johnson@p.cs.uiuc.edu :
] > From Ken Warner:
] > How does one find out the super-class so that one can access the super
] > class-pool variables without explicitly stateing the name of the
] > super class?
]
] Various people answered that "self class superclass" would give you the
] superclass of an object's class. This might be the direct answer, but it
] might not be answering the real question. I don't see why there can be
] any problem in accessing pool variables, and wonder if Ken isn't trying
] to access some other kind of variables. Subclasses use the exact same
] copies of class variables as the superclass that defines the variables.
] I think that pool variables are also inherited, so they shouldn't be a
] problem either.
So if one simply wants to get the value of superclass pool variable "Foo",
one can simply ask for Foo, without even finding the superclass.
On the other hand, if one really wants to know just what class variables are
defined in the superclass, the message:
self class superclass classPool
will give the desired answer, while:
self class classPool
will give a superset consisting of those found by the former message plus
those class variables defined in self class.