greetings all,
I am using ConfigurationOfODBC in Pharo 1.3. I have had success with getting an ODBCResultTable(OrderedCollection) containing ODBCRow containing about 30 fields. By default the fields are accessed by "row at: #fieldName" but I wanted to add some convenience methods to instead go "row fieldName." My searching and experimentation led me to subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on each ODBCRow to convert it to the subclass. This was to avoid having to having to understand and change any of the ConfigurationOfODBC code. I had tried copyFrom: but some of the instance variables inherited from ODBCRow were not filled in, generating exceptions in some of the inherited methods. I had also considered "become:" but that didn't seem appropriate. Using "adoptInstance:" worked fine until I added a new instance variable to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = #'bad receiver'. The "adoptInstance:" method comment says it follows the same rules as "primitiveChangeClassTo:" (yet note that "primitiveChangeClassTo:" never worked) The "primitiveChangeClassTo:" method comment says "The primitive will fail in most cases that you think might work [...] The facility is really provided for certain, very specific applications (mostly related to classes changing shape) and not for casual use" so I wondered if there was another way to achieve this. The full code is hopefully not too long to include for reference below. The use of "adoptInstance:" in the last section listed. ------ ODBCRow subclass: #EAPPackage instanceVariableNames: 'parent' "note adoptInstance works without this instance variable, and not with" classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackage >> name ^ self at: #Name ------ ODBCResultTable subclass: #EAPPackages instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackages class >> newFromConnection: connection | packages parent | packages := (connection query: 'select * from t_package;') execute asTable. self adoptInstance: packages. packages do: [ :row | EAPPackage adoptInstance: row. ]. ^packages. ------ In a Workspace I successfully evaluate the following three lines without : connection := ODBCConnection dsn: 'CIM' user: '' password: ''. packages := EAPPackages newFromConnection: connection. connection close. ------ I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One alternative I've considered is to somehow pass through a custom SomeClass in a variable to replace the hard reference to ODBCRow - but I don't want to chase back all the cascading call references. Is there another way to change an existing object to another class, such that it can be specialised with both additional methods and instance variables? I would appreciate any pointers. regards, Ben |
Ben,
That's a lot to read. If I'm getting the message, you want to subclass ODBCRow and are concerned about Metacello. Can't you simply subclass and then always load your code after the ODBC configuration does its thing in a new image? FWIW, I suspect I would make some type of wrapper class for the rows rather than subclass - the goal being to strive for uses-a vs. is-a. Idealistically (and perhaps naively) yours, Bill ________________________________________ From: [hidden email] [[hidden email]] on behalf of Ben Coman [[hidden email]] Sent: Tuesday, December 27, 2011 11:46 PM To: [hidden email] Subject: [Pharo-project] changing the class of an existing object to a subclass greetings all, I am using ConfigurationOfODBC in Pharo 1.3. I have had success with getting an ODBCResultTable(OrderedCollection) containing ODBCRow containing about 30 fields. By default the fields are accessed by "row at: #fieldName" but I wanted to add some convenience methods to instead go "row fieldName." My searching and experimentation led me to subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on each ODBCRow to convert it to the subclass. This was to avoid having to having to understand and change any of the ConfigurationOfODBC code. I had tried copyFrom: but some of the instance variables inherited from ODBCRow were not filled in, generating exceptions in some of the inherited methods. I had also considered "become:" but that didn't seem appropriate. Using "adoptInstance:" worked fine until I added a new instance variable to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = #'bad receiver'. The "adoptInstance:" method comment says it follows the same rules as "primitiveChangeClassTo:" (yet note that "primitiveChangeClassTo:" never worked) The "primitiveChangeClassTo:" method comment says "The primitive will fail in most cases that you think might work [...] The facility is really provided for certain, very specific applications (mostly related to classes changing shape) and not for casual use" so I wondered if there was another way to achieve this. The full code is hopefully not too long to include for reference below. The use of "adoptInstance:" in the last section listed. ------ ODBCRow subclass: #EAPPackage instanceVariableNames: 'parent' "note adoptInstance works without this instance variable, and not with" classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackage >> name ^ self at: #Name ------ ODBCResultTable subclass: #EAPPackages instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackages class >> newFromConnection: connection | packages parent | packages := (connection query: 'select * from t_package;') execute asTable. self adoptInstance: packages. packages do: [ :row | EAPPackage adoptInstance: row. ]. ^packages. ------ In a Workspace I successfully evaluate the following three lines without : connection := ODBCConnection dsn: 'CIM' user: '' password: ''. packages := EAPPackages newFromConnection: connection. connection close. ------ I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One alternative I've considered is to somehow pass through a custom SomeClass in a variable to replace the hard reference to ODBCRow - but I don't want to chase back all the cascading call references. Is there another way to change an existing object to another class, such that it can be specialised with both additional methods and instance variables? I would appreciate any pointers. regards, Ben |
Schwab,Wilhelm K wrote:
> Ben, > > That's a lot to read. If I'm getting the message, you want to subclass ODBCRow and are concerned about Metacello. Point taken. In hindsight too much background info and a mixed message. Actually it wasn't not a question about Metacello - though my other recent mention of ConfigurationOfODBC was. I only mentioned ConfigurationOfODBC here to distinguish it from the ODBC in DBXTalk - and in hindsight that is not the core question. The short version is "how do I change the class of existing object into one of its subclasses". I've got it working, but not if I add an instance variable to the subclass. > FWIW, I suspect I would make some type of wrapper class for the rows rather than subclass - the goal being to strive for uses-a vs. is-a. > I had considered that briefly but was concerned that the wrapped class needed to understand every message that the wrapped-class understood. I wanted to use the existing ODBCResultTable which holds the ODBCRows to contain my new subclass of ODBCRow. I will think further about this. > Idealistically (and perhaps naively) yours, > More than I would know. Thanks for your time. -Ben > Bill > > > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Ben Coman [[hidden email]] > Sent: Tuesday, December 27, 2011 11:46 PM > To: [hidden email] > Subject: [Pharo-project] changing the class of an existing object to a subclass > > greetings all, > > I am using ConfigurationOfODBC in Pharo 1.3. I have had success with > getting an ODBCResultTable(OrderedCollection) containing ODBCRow > containing about 30 fields. By default the fields are accessed by "row > at: #fieldName" but I wanted to add some convenience methods to instead > go "row fieldName." My searching and experimentation led me to > subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on > each ODBCRow to convert it to the subclass. This was to avoid having to > having to understand and change any of the ConfigurationOfODBC code. I > had tried copyFrom: but some of the instance variables inherited from > ODBCRow were not filled in, generating exceptions in some of the > inherited methods. I had also considered "become:" but that didn't seem > appropriate. > > Using "adoptInstance:" worked fine until I added a new instance variable > to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = > #'bad receiver'. The "adoptInstance:" method comment says it follows > the same rules as "primitiveChangeClassTo:" (yet note that > "primitiveChangeClassTo:" never worked) > The "primitiveChangeClassTo:" method comment says "The primitive will > fail in most cases that you think might work [...] The facility is > really provided for certain, very specific applications (mostly related > to classes changing shape) and not for casual use" so I wondered if > there was another way to achieve this. > > The full code is hopefully not too long to include for reference below. > The use of "adoptInstance:" in the last section listed. > ------ > ODBCRow subclass: #EAPPackage > instanceVariableNames: 'parent' "note adoptInstance works without > this instance variable, and not with" > classVariableNames: '' > poolDictionaries: '' > category: 'BTC-EA-Explore' > ------ > EAPPackage >> name > ^ self at: #Name > ------ > ODBCResultTable subclass: #EAPPackages > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'BTC-EA-Explore' > ------ > EAPPackages class >> newFromConnection: connection > | packages parent | > packages := (connection query: 'select * from t_package;') execute > asTable. > self adoptInstance: packages. > > packages do: [ :row | EAPPackage adoptInstance: row. ]. > > ^packages. > ------ > In a Workspace I successfully evaluate the following three lines without : > connection := ODBCConnection dsn: 'CIM' user: '' password: ''. > packages := EAPPackages newFromConnection: connection. > connection close. > ------ > > I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One > alternative I've considered is to somehow pass through a custom > SomeClass in a variable to replace the hard reference to ODBCRow - but I > don't want to chase back all the cascading call references. > > Is there another way to change an existing object to another class, such > that it can be specialised with both additional methods and instance > variables? > I would appreciate any pointers. > > regards, Ben > > > > |
Ben: In CogVM you have #adoptInstance:
MyClass adoptInstance: whateverObject. Before Cog, you had #primitiveChangeClassTo: whateverObject primitiveChangeClassTo: anotherOBJECT in this case, whateverObject will change its class to the class of anotherOBJECT cheers On Wed, Dec 28, 2011 at 12:08 PM, Ben Coman <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
In reply to this post by Ben Coman
On 28.12.2011 05:46, Ben Coman wrote:
> greetings all, > I am using ConfigurationOfODBC in Pharo 1.3. I have had success with > getting an ODBCResultTable(OrderedCollection) containing ODBCRow > containing about 30 fields. By default the fields are accessed by > "row at: #fieldName" but I wanted to add some convenience methods to > instead go "row fieldName." My searching and experimentation led me > to subclassing ODBCRow as EAPPackage and then using "adoptInstance:" > on each ODBCRow to convert it to the subclass. This was to avoid > having to having to understand and change any of the > ConfigurationOfODBC code. I had tried copyFrom: but some of the > instance variables inherited from ODBCRow were not filled in, > generating exceptions in some of the inherited methods. I had also > considered "become:" but that didn't seem appropriate. > > Using "adoptInstance:" worked fine until I added a new instance > variable to EAPPackage. Subsequently for "<primitive: 160 error: > ec>", ec = #'bad receiver'. The "adoptInstance:" method comment says > it follows the same rules as "primitiveChangeClassTo:" (yet note that > "primitiveChangeClassTo:" never worked) > The "primitiveChangeClassTo:" method comment says "The primitive will > fail in most cases that you think might work [...] The facility is > really provided for certain, very specific applications (mostly > related to classes changing shape) and not for casual use" so I > wondered if there was another way to achieve this. adoptInstance: only works when the object shapes are the same. (It only switches the class pointer in the object's header, and does not touch any contents) This is no longer true when the class you switch to have additional variables. > The full code is hopefully not too long to include for reference > below. The use of "adoptInstance:" in the last section listed. > ------ > ODBCRow subclass: #EAPPackage > instanceVariableNames: 'parent' "note adoptInstance works without > this instance variable, and not with" > classVariableNames: '' > poolDictionaries: '' > category: 'BTC-EA-Explore' > ------ > EAPPackage >> name > ^ self at: #Name > ------ > ODBCResultTable subclass: #EAPPackages > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'BTC-EA-Explore' > ------ > EAPPackages class >> newFromConnection: connection > | packages parent | > packages := (connection query: 'select * from t_package;') execute > asTable. > self adoptInstance: packages. > > packages do: [ :row | EAPPackage adoptInstance: row. ]. > > ^packages. > ------ > In a Workspace I successfully evaluate the following three lines > without : > connection := ODBCConnection dsn: 'CIM' user: '' password: ''. > packages := EAPPackages newFromConnection: connection. > connection close. > ------ > > I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One > alternative I've considered is to somehow pass through a custom > SomeClass in a variable to replace the hard reference to ODBCRow - but > I don't want to chase back all the cascading call references. > > Is there another way to change an existing object to another class, > such that it can be specialised with both additional methods and > instance variables? > I would appreciate any pointers. > > regards, Ben > ODBCRow >> #basicNew ^EAPPackages basicNew I'm somewhat puzzled that the copyFrom:/become: strategy (while an ugly approach imho) would fail though, do you think you could reduce it to a simple test using classes in the base image? Cheers, Henry |
Henrik Sperre Johansen wrote:
> On 28.12.2011 05:46, Ben Coman wrote: >> <snip> > adoptInstance: only works when the object shapes are the same. (It > only switches the class pointer in the object's header, and does not > touch any contents) This is no longer true when the class you switch > to have additional variables. I was hoping that adding an instance variable to a subclass did not change the shape from the perspective of the superclass methods accessing superclass instance variables. >> <snip> > You could act preemtively, and create an extension in your package: > ODBCRow >> #basicNew > ^EAPPackages basicNew I was trying to avoid tainting upstream code, but if I had to go there I'd rather replace the hardcoded "row := ODBCRow new: columns size." in method "ODBCResultSet>>fetchRow" with "row := theReturnClassLikeODBCRow new: columns size." and new method "ODBCStatement>>execute:args withReturnClass: theReturnClassLikeODBCRow" with existing method "ODBCStatement>>execute:args" changed to call "ODBCStatement>>execute:args withReturnClass: ODBCRow" > > I had tried copyFrom: but some of the instance variables inherited from ODBCRow were not filled in, > > generating exceptions in some of the inherited methods. I had also considered "become:" but that didn't seem appropriate. > I'm somewhat puzzled that the copyFrom:/become: strategy (while an > ugly approach imho) would fail though, do you think you could reduce > it to a simple test using classes in the base image? I've lost track of that code and I can't reproduce it so I must have been doing something wrong. However I had also been considering become: and copyFrom: independently and not as a combined strategy. Together they are sufficient. Thanks for the pointer Henry. To close this out, here is what worked... EAPPackages >> newFromConnection: connection | packages parent | packages := (connection query: 'select * from t_package;') execute asTable. "comes back as an ODBCResultTable" self adoptInstance: packages. "no additional instance variables in subclass" packages do: [ :pkg || tmppkg | tmppkg := EAPPackage new copyFrom: pkg. tmppkg become: pkg ]. ^packages. >> <snip> >> EAPPackages class >> newFromConnection: connection >> | packages parent | >> packages := (connection query: 'select * from t_package;') execute >> asTable. >> self adoptInstance: packages. >> packages do: [ :row | EAPPackage adoptInstance: row. ]. "this line >> replaced by copyFrom: & become:" >> ^packages. >> <snip> > > Cheers, > Henry cheers, Ben |
In reply to this post by Ben Coman
On Wed, Dec 28, 2011 at 12:08 PM, Ben Coman <[hidden email]> wrote:
Just in case of interest, in DBXTalk you CAN access not only by index but by name. rawValueAt: anIndex "It returns the value of the raw at the specified index. No conversion is here, so all values will be String" ^rawValues at: anIndex rawValueNamed: aString "It returns the value of the raw with the specified name. No conversion is here, so all values will be String" ^self rawValueAt: (self columnIndex: aString) And you can also get the values and convert them to smalltalk objects: valueAt: anIndex "It returns the value of the raw at the specified index. Each string returned from openDBX will be converted, if supported, to Squeak types" ^self convertValueAt: anIndex valueNamed: aString "It returns the value of the raw with the specified name. Each string returned from openDBX will be converted, if supported, to Squeak types" ^self convertValueAt: (self columnIndex: aString). Cheers - and in hindsight that is not the core question. The short version is "how do I change the class of existing object into one of its subclasses". I've got it working, but not if I add an instance variable to the subclass. -- Mariano http://marianopeck.wordpress.com |
Free forum by Nabble | Edit this page |