Ok.. Definitely a newbie question here. This seems to cause me some
frustration as I'm not really sure what the ramifications are of using one form over another.. Perhaps someone can shed some light on what I'm missing here. What is the difference between the two classes below where the only difference is the first line of the class definition, and is that somehow tied to the "imports" option? Many thanks in advance.. -- Rick Smalltalk.Seaside defineClass: #User superclass: #{Core.Object} indexedType: #none private: false instanceVariableNames: 'userId familyId orgId nameLast nameFirst streetAddress city state zip phone email username password lastLogin flags ' classInstanceVariableNames: '' imports: '' category: 'MyTest' =================================================== Smalltalk defineClass: #User superclass: #{Core.Object} indexedType: #none private: false instanceVariableNames: 'userId familyId orgId nameLast nameFirst streetAddress city state zip phone email username password lastLogin flags ' classInstanceVariableNames: '' imports: '' category: 'MyTest' |
The receiver of the #defineClass:... method determines the scope in which the new class will be visible. The imports: keyword determines the scope of things the class can "see" without explicitly qualifying the names. So if Smalltalk.Seaside is imported, the class can see everything in that namespace without adding 'Seaside.' all the time. If the class is defined in Smalltalk.Seaside, then other parts of the system might need to either import Seaside or qualify references, like Seaside.User
Dave -covering message- +----------------------------- | Date: Tue, 14 Feb 2006 17:09:10 -0800 | From: Rick Flower <[hidden email]> | Subject: Why specify Smalltalk ... defineClass vs. Smalltalk.Seaside .. defineClass | Ok.. Definitely a newbie question here. This seems to cause me some | frustration as I'm not really sure what the ramifications are of using | one form over another.. Perhaps someone can shed some light on what I'm | missing here. What is the difference between the two classes below | where the only difference is the first line of the class definition, and | is that somehow tied to the "imports" option? Many thanks in advance.. | -- Rick | Smalltalk.Seaside defineClass: #User | superclass: #{Core.Object} | indexedType: #none | private: false | instanceVariableNames: 'userId familyId orgId nameLast nameFirst | streetAddress city state zip phone email username password lastLogin flags ' | classInstanceVariableNames: '' | imports: '' | category: 'MyTest' | =================================================== | Smalltalk defineClass: #User | superclass: #{Core.Object} | indexedType: #none | private: false | instanceVariableNames: 'userId familyId orgId nameLast nameFirst | streetAddress city state zip phone email username password lastLogin flags ' | classInstanceVariableNames: '' | imports: '' | category: 'MyTest' |
In reply to this post by Rick Flower
Oh yeah, and if the class is defined in Smalltalk.Seaside, it can implicitly see everything in Smalltalk.Seaside without explicitly importing that namespace.
Dave (again) -covering message- +----------------------------- | Date: Tue, 14 Feb 2006 17:14:06 -0800 | From: [hidden email] | Subject: Re: Why specify Smalltalk ... defineClass vs. Smalltalk.Seaside .. defineClass | The receiver of the #defineClass:... method determines the scope in which the new class will be visible. The imports: keyword determines the scope of things the class can "see" without explicitly qualifying the names. So if Smalltalk.Seaside is imported, the class can see everything in that namespace without adding 'Seaside.' all the time. If the class is defined in Smalltalk.Seaside, then other parts of the system might need to either import Seaside or qualify references, like Seaside.User | Dave | -covering message- | +----------------------------- | | Date: Tue, 14 Feb 2006 17:09:10 -0800 | | From: Rick Flower <[hidden email]> | | Subject: Why specify Smalltalk ... defineClass vs. Smalltalk.Seaside .. defineClass | | Ok.. Definitely a newbie question here. This seems to cause me some | | frustration as I'm not really sure what the ramifications are of using | | one form over another.. Perhaps someone can shed some light on what I'm | | missing here. What is the difference between the two classes below | | where the only difference is the first line of the class definition, and | | is that somehow tied to the "imports" option? Many thanks in advance.. | | -- Rick | | Smalltalk.Seaside defineClass: #User | | superclass: #{Core.Object} | | indexedType: #none | | private: false | | instanceVariableNames: 'userId familyId orgId nameLast nameFirst | | streetAddress city state zip phone email username password lastLogin flags ' | | classInstanceVariableNames: '' | | imports: '' | | category: 'MyTest' | | =================================================== | | Smalltalk defineClass: #User | | superclass: #{Core.Object} | | indexedType: #none | | private: false | | instanceVariableNames: 'userId familyId orgId nameLast nameFirst | | streetAddress city state zip phone email username password lastLogin flags ' | | classInstanceVariableNames: '' | | imports: '' | | category: 'MyTest' |
[hidden email] wrote:
> Oh yeah, and if the class is defined in Smalltalk.Seaside, it can implicitly see everything in Smalltalk.Seaside without explicitly importing that namespace. > > Hmm.. Interesting.. The case I got in trouble with was using my "User" class as part of a Glorp session and Glorp didn't seem to like it when my "User" class was defined using the "Smalltalk.Seaside" line but works perfectly when I remove the ".Seaside" portion.. So, if I'm thinking correctly here, Glorp was probably getting confused because my descriptors for my "User" class didn't specifically call out the object as a "Seaside.User" class but were looking at just plain "User".. Hopefully I'm barking up the right tree here.. Thanks much! -- Rick |
At 08:20 PM 2/14/2006, Rick Flower wrote:
>[hidden email] wrote: >>Oh yeah, and if the class is defined in Smalltalk.Seaside, it can implicitly see everything in Smalltalk.Seaside without explicitly importing that namespace. >> >> >Hmm.. Interesting.. The case I got in trouble with was using my "User" class as part of a Glorp session and Glorp didn't seem to like it when my "User" class was defined using the "Smalltalk.Seaside" line but works perfectly when I remove the ".Seaside" portion.. So, if I'm thinking correctly here, Glorp was probably getting confused because my descriptors for my "User" class didn't specifically call out the object as a "Seaside.User" class but were looking at just plain "User".. Hopefully I'm barking up the right tree here.. Thanks much! > >-- Rick Yes, that's right. What you might want to do is define your own namespace, and have it import both the Seaside and Glorp namespaces. Or you could just refer to the classes in one or both using dotted names. -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
Free forum by Nabble | Edit this page |