How to remove a class extension from a package
Locked
How to remove a class extension from a package
 
|
So I added a class extension for ArithmeticValue when a class extension
for Number would have sufficed. Now I don't dare to remove it in the browser, since I get the impression that I will remove the core class instead of only my extension. How do I get rid of this thing again? Thanks, s. -- Stefan Schmiedl |
RE: How to remove a class extension from a package
|
|
Compile empty method #blah and remove it, as soon as there are no
extensions left it'll remove the empty class from your package. If anyone knows a better way I'm all ears ;) -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: Stefan Schmiedl [mailto:[hidden email]] > Sent: Monday, June 04, 2007 10:06 AM > To: [hidden email] > Subject: How to remove a class extension from a package > > So I added a class extension for ArithmeticValue when a class extension > for Number would have sufficed. Now I don't dare to remove it in the > browser, since I get the impression that I will remove the core class > instead of only my extension. > > How do I get rid of this thing again? > > Thanks, > s. > -- > Stefan Schmiedl |
Re: How to remove a class extension from a package
|
|
In reply to this post by Stefan Schmiedl
Remove the method not the class from the package. The class will disappear
automatically. ----- Original Message ----- From: "Stefan Schmiedl" <[hidden email]> To: <[hidden email]> Sent: Monday, June 04, 2007 12:06 PM Subject: How to remove a class extension from a package > So I added a class extension for ArithmeticValue when a class extension > for Number would have sufficed. Now I don't dare to remove it in the > browser, since I get the impression that I will remove the core class > instead of only my extension. > > How do I get rid of this thing again? > > Thanks, > s. > -- > Stefan Schmiedl > > |
RE: How to remove a class extension from a package
|
|
Right, except that sometimes you have an empty extension with no methods
if you change your mind or pick the wrong class or whatever, so you have to create a method first before removing it, very silly. -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: Charles Adams [mailto:[hidden email]] > Sent: Monday, June 04, 2007 10:16 AM > To: Stefan Schmiedl; [hidden email] > Subject: Re: How to remove a class extension from a package > > Remove the method not the class from the package. The class will disappear > automatically. > > ----- Original Message ----- > From: "Stefan Schmiedl" <[hidden email]> > To: <[hidden email]> > Sent: Monday, June 04, 2007 12:06 PM > Subject: How to remove a class extension from a package > > > > So I added a class extension for ArithmeticValue when a class > > for Number would have sufficed. Now I don't dare to remove it in the > > browser, since I get the impression that I will remove the core class > > instead of only my extension. > > > > How do I get rid of this thing again? > > > > Thanks, > > s. > > -- > > Stefan Schmiedl > > > > |
Re: How to remove a class extension from a package
|
|
Hmm, I've not seen that.
----- Original Message ----- From: "Boris Popov" <[hidden email]> To: "Charles Adams" <[hidden email]>; "Stefan Schmiedl" <[hidden email]>; <[hidden email]> Sent: Monday, June 04, 2007 12:19 PM Subject: RE: How to remove a class extension from a package > Right, except that sometimes you have an empty extension with no methods > if you change your mind or pick the wrong class or whatever, so you have > to create a method first before removing it, very silly. > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. Unless otherwise indicated, it contains information that is > private and confidential. If you have received it in error, please > notify the sender and delete the entire message including any > attachments. > > Thank you. > >> -----Original Message----- >> From: Charles Adams [mailto:[hidden email]] >> Sent: Monday, June 04, 2007 10:16 AM >> To: Stefan Schmiedl; [hidden email] >> Subject: Re: How to remove a class extension from a package >> >> Remove the method not the class from the package. The class will > disappear >> automatically. >> >> ----- Original Message ----- >> From: "Stefan Schmiedl" <[hidden email]> >> To: <[hidden email]> >> Sent: Monday, June 04, 2007 12:06 PM >> Subject: How to remove a class extension from a package >> >> >> > So I added a class extension for ArithmeticValue when a class > extension >> > for Number would have sufficed. Now I don't dare to remove it in the >> > browser, since I get the impression that I will remove the core > class >> > instead of only my extension. >> > >> > How do I get rid of this thing again? >> > >> > Thanks, >> > s. >> > -- >> > Stefan Schmiedl >> > >> > > > > |
RE: How to remove a class extension from a package
|
|
Create package A, extend Object class, but don't add any methods.
Question is, how to remove that extension from package A now? The only way I found is to compile a bogus method and remove it, but there's got to be a better way, that's all I'm saying. -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: Charles Adams [mailto:[hidden email]] > Sent: Monday, June 04, 2007 10:23 AM > To: Boris Popov; Stefan Schmiedl; [hidden email] > Subject: Re: How to remove a class extension from a package > > Hmm, I've not seen that. > > ----- Original Message ----- > From: "Boris Popov" <[hidden email]> > To: "Charles Adams" <[hidden email]>; "Stefan Schmiedl" > <[hidden email]> > Sent: Monday, June 04, 2007 12:19 PM > Subject: RE: How to remove a class extension from a package > > > > Right, except that sometimes you have an empty extension with no methods > > if you change your mind or pick the wrong class or whatever, so you have > > to create a method first before removing it, very silly. > > > > -Boris > > > > -- > > +1.604.689.0322 > > DeepCove Labs Ltd. > > 4th floor 595 Howe Street > > Vancouver, Canada V6C 2T5 > > http://tinyurl.com/r7uw4 > > > > [hidden email] > > > > CONFIDENTIALITY NOTICE > > > > This email is intended only for the persons named in the message > > header. Unless otherwise indicated, it contains information that is > > private and confidential. If you have received it in error, please > > notify the sender and delete the entire message including any > > attachments. > > > > Thank you. > > > >> -----Original Message----- > >> From: Charles Adams [mailto:[hidden email]] > >> Sent: Monday, June 04, 2007 10:16 AM > >> To: Stefan Schmiedl; [hidden email] > >> Subject: Re: How to remove a class extension from a package > >> > >> Remove the method not the class from the package. The class will > > disappear > >> automatically. > >> > >> ----- Original Message ----- > >> From: "Stefan Schmiedl" <[hidden email]> > >> To: <[hidden email]> > >> Sent: Monday, June 04, 2007 12:06 PM > >> Subject: How to remove a class extension from a package > >> > >> > >> > So I added a class extension for ArithmeticValue when a class > > extension > >> > for Number would have sufficed. Now I don't dare to remove it in > >> > browser, since I get the impression that I will remove the core > > class > >> > instead of only my extension. > >> > > >> > How do I get rid of this thing again? > >> > > >> > Thanks, > >> > s. > >> > -- > >> > Stefan Schmiedl > >> > > >> > > > > > > > |
Re: How to remove a class extension from a package
|
|
On Mon, 4 Jun 2007 10:25:32 -0700
"Boris Popov" <[hidden email]> wrote: > Create package A, extend Object class, but don't add any methods. That's my exact situation. > Question is, how to remove that extension from package A now? The only > way I found is to compile a bogus method and remove it, but there's > got to be a better way, that's all I'm saying. I'm happy with your workaround. Thanks, s. |
RE: How to remove a class extension from a package
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Hello list,
I'm a newbie Smalltalk developer and am currently working on a project to migrate code from VW 3.0 to VW 7.4. I hit an issue that I'm wondering if anyone out there could help me out with. I have the following code that formats a table columns: elementFormats "^an Array Private" ^#(#left #left #left #right #right #right #right #right) at: 1 put: self duplicateBlock; at: 6 put: self actualVsCurrentBlock; yourself When I execute this in v.7 it gives me the error Unhandled exception: nil in Array(Object)>>noModificationErrorFor:index:value: when sending the first at:put: message. When I execute this exact same code in v.3 no error message is issued. I tried to debug the code in v.3 by stepping into the at:put: method class but for an unknown reason (to me, at least) the debugger doesn't display the called/executed class/method. Next, I added a breakpoint to the Object class at:put: method, but after executing the code again it didn't stop at the breakpoint (so I am assuming that the Object class code is not being executed in v.3.) Later on I changed the code in v.3 to the following: elementFormats "^an Array Private" |newArray| newArray := Array new. newArray at:1 put: self duplicateBlock; at: 6 put: self actualVsCurrentBlock; yourself. ^newArray When I execute this updated code the Object class breakpoint is reached. From my very limited experience, I am guessing that there's probably a class extension somewhere that has a different at:put: definition. Is this a reasonable guess? The best way I know of finding this out is to debug and check where the process is going to. But unfortunately I can't step into the code. So, does anyone know of any way that I can "force" the debugger to go into the method's class? maybe a special combination of keys? By the way, the system uses ENVY and PDP debugger in v.3. TIA and I apologize for the long email. Roberto Fonseca Solution Center Blue Heron Consulting 90 Airpark Dr, Suite 200 Rochester, NY 14624 www.BlueHeron-Consulting.com Office: 800.253.3449 / 585.464.8035 x 211 Fax: 800.464.9901 / 585.464.9760 |
Immutability was: [Re: How to remove a class extension from a package ]
|
|
Later versions of VisualWorks have extended support for object
immutability. Literally created objects like the array in your original code are immutable. Creating them through message sends creates mutable instances. You can make immutable objects mutable by sending them the message #beMutable, or you can do as you have and create them through messages, rather than the compiler. An example to demonstrate | immutable mutable | immutable := ''. mutable := String new. immutable writeStream nextPutAll: 'test' >> throws no modification error. mutable writeStream nextPutAll: 'test' >> works normally. Mike On Jun 4, 2007, at 12:50 PM, Roberto Fonseca wrote: > Hello list, > > I'm a newbie Smalltalk developer and am currently working on a > project to > migrate code from VW 3.0 to VW 7.4. I hit an issue that I'm > wondering if > anyone out there could help me out with. I have the following code > that > formats a table columns: > > elementFormats > "^an Array > Private" > > ^#(#left #left #left #right #right #right #right #right) > at: 1 put: self duplicateBlock; > at: 6 put: self actualVsCurrentBlock; > yourself > > When I execute this in v.7 it gives me the error Unhandled > exception: nil in > Array(Object)>>noModificationErrorFor:index:value: when sending the > first > at:put: message. > > When I execute this exact same code in v.3 no error message is > issued. I > tried to debug the code in v.3 by stepping into the at:put: method > class but > for an unknown reason (to me, at least) the debugger doesn't > display the > called/executed class/method. Next, I added a breakpoint to the > Object class > at:put: method, but after executing the code again it didn't stop > at the > breakpoint (so I am assuming that the Object class code is not being > executed in v.3.) Later on I changed the code in v.3 to the following: > > elementFormats > "^an Array > Private" > > |newArray| > newArray := Array new. > newArray > at:1 put: self duplicateBlock; > at: 6 put: self actualVsCurrentBlock; > yourself. > ^newArray > > When I execute this updated code the Object class breakpoint is > reached. > From my very limited experience, I am guessing that there's > probably a class > extension somewhere that has a different at:put: definition. Is this a > reasonable guess? The best way I know of finding this out is to > debug and > check where the process is going to. But unfortunately I can't step > into the > code. So, does anyone know of any way that I can "force" the > debugger to go > into the method's class? maybe a special combination of keys? By > the way, > the system uses ENVY and PDP debugger in v.3. > > TIA and I apologize for the long email. > > Roberto Fonseca > Solution Center > Blue Heron Consulting > 90 Airpark Dr, Suite 200 > Rochester, NY 14624 > www.BlueHeron-Consulting.com > Office: 800.253.3449 / 585.464.8035 x 211 > Fax: 800.464.9901 / 585.464.9760 > |
RE: How to remove a class extension from a package
|
|
In reply to this post by Roberto Fonseca
Robert
I don't have v3.0 in front of me, but possibly the literal array being created is not of class Array. I suspect the reason the debugger did not step into the #at:put: method is that is a primitive method. When you attempt to step into a primitive method the primitive is first executed. If it fails and executes the failure code then the debugger will be in the failure code. If it succeeds then it will appear as though the debugger did not enter the method. Additionally, there are a few special primitive methods that perform some other method, such as #perform:, in these methods the debugger will return control in the client method. One other thing, you need to be careful when putting breakpoints in methods that are used by the rest of the system. You can end up hanging your image. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Roberto Fonseca [mailto:[hidden email]] > Sent: Monday, June 04, 2007 2:51 PM > To: [hidden email] > Subject: RE: How to remove a class extension from a package > > Hello list, > > I'm a newbie Smalltalk developer and am currently working on a project to > migrate code from VW 3.0 to VW 7.4. I hit an issue that I'm wondering if > anyone out there could help me out with. I have the following code that > formats a table columns: > > elementFormats > "^an Array > Private" > > ^#(#left #left #left #right #right #right #right #right) > at: 1 put: self duplicateBlock; > at: 6 put: self actualVsCurrentBlock; > yourself > > When I execute this in v.7 it gives me the error Unhandled exception: nil > in > Array(Object)>>noModificationErrorFor:index:value: when sending the first > at:put: message. > > When I execute this exact same code in v.3 no error message is issued. I > tried to debug the code in v.3 by stepping into the at:put: method class > but > for an unknown reason (to me, at least) the debugger doesn't display the > called/executed class/method. Next, I added a breakpoint to the Object > class > at:put: method, but after executing the code again it didn't stop at the > breakpoint (so I am assuming that the Object class code is not being > executed in v.3.) Later on I changed the code in v.3 to the following: > > elementFormats > "^an Array > Private" > > |newArray| > newArray := Array new. > newArray > at:1 put: self duplicateBlock; > at: 6 put: self actualVsCurrentBlock; > yourself. > ^newArray > > When I execute this updated code the Object class breakpoint is reached. > From my very limited experience, I am guessing that there's probably a > class > extension somewhere that has a different at:put: definition. Is this a > reasonable guess? The best way I know of finding this out is to debug and > check where the process is going to. But unfortunately I can't step into > the > code. So, does anyone know of any way that I can "force" the debugger to > go > into the method's class? maybe a special combination of keys? By the way, > the system uses ENVY and PDP debugger in v.3. > > TIA and I apologize for the long email. > > Roberto Fonseca > Solution Center > Blue Heron Consulting > 90 Airpark Dr, Suite 200 > Rochester, NY 14624 > www.BlueHeron-Consulting.com > Office: 800.253.3449 / 585.464.8035 x 211 > Fax: 800.464.9901 / 585.464.9760 |
RE: Immutability was: [Re: How to remove a class extension from a package ]
|
|
In reply to this post by Mike Hales
Mike and Eliot,
I was able to fix the problem!! Thanks (again) for your help, Roberto -----Original Message----- From: Mike Hales [mailto:[hidden email]] Sent: Monday, June 04, 2007 3:26 PM To: Roberto Fonseca Cc: VW NC Subject: Immutability was: [Re: How to remove a class extension from a package ] Later versions of VisualWorks have extended support for object immutability. Literally created objects like the array in your original code are immutable. Creating them through message sends creates mutable instances. You can make immutable objects mutable by sending them the message #beMutable, or you can do as you have and create them through messages, rather than the compiler. An example to demonstrate | immutable mutable | immutable := ''. mutable := String new. immutable writeStream nextPutAll: 'test' >> throws no modification error. mutable writeStream nextPutAll: 'test' >> works normally. Mike On Jun 4, 2007, at 12:50 PM, Roberto Fonseca wrote: > Hello list, > > I'm a newbie Smalltalk developer and am currently working on a project > to migrate code from VW 3.0 to VW 7.4. I hit an issue that I'm > wondering if anyone out there could help me out with. I have the > following code that formats a table columns: > > elementFormats > "^an Array > Private" > > ^#(#left #left #left #right #right #right #right #right) > at: 1 put: self duplicateBlock; > at: 6 put: self actualVsCurrentBlock; > yourself > > When I execute this in v.7 it gives me the error Unhandled > exception: nil in > Array(Object)>>noModificationErrorFor:index:value: when sending the > first > at:put: message. > > When I execute this exact same code in v.3 no error message is issued. > I tried to debug the code in v.3 by stepping into the at:put: method > class but for an unknown reason (to me, at least) the debugger doesn't > display the called/executed class/method. Next, I added a breakpoint > to the Object class > at:put: method, but after executing the code again it didn't stop at > the breakpoint (so I am assuming that the Object class code is not > being executed in v.3.) Later on I changed the code in v.3 to the > following: > > elementFormats > "^an Array > Private" > > |newArray| > newArray := Array new. > newArray > at:1 put: self duplicateBlock; > at: 6 put: self actualVsCurrentBlock; > yourself. > ^newArray > > When I execute this updated code the Object class breakpoint is > reached. > From my very limited experience, I am guessing that there's probably a > class extension somewhere that has a different at:put: definition. Is > this a reasonable guess? The best way I know of finding this out is to > debug and check where the process is going to. But unfortunately I > can't step into the code. So, does anyone know of any way that I can > "force" the debugger to go into the method's class? maybe a special > combination of keys? By the way, the system uses ENVY and PDP debugger > in v.3. > > TIA and I apologize for the long email. > > Roberto Fonseca > Solution Center > Blue Heron Consulting > 90 Airpark Dr, Suite 200 > Rochester, NY 14624 > www.BlueHeron-Consulting.com > Office: 800.253.3449 / 585.464.8035 x 211 > Fax: 800.464.9901 / 585.464.9760 > |
RE: How to remove a class extension from a package
|
|
In reply to this post by Terry Raymond
Terry,
Thanks for the explanation. Actually I believe the at:put: is a primitive method. So, your explanation definitely makes sense. And yes, I have made the mistake of putting a breakpoint in a wrong place before! :) Fortunately, I didn't loose much. Roberto -----Original Message----- From: Terry Raymond [mailto:[hidden email]] Sent: Monday, June 04, 2007 3:46 PM To: 'Roberto Fonseca'; [hidden email] Subject: RE: How to remove a class extension from a package Robert I don't have v3.0 in front of me, but possibly the literal array being created is not of class Array. I suspect the reason the debugger did not step into the #at:put: method is that is a primitive method. When you attempt to step into a primitive method the primitive is first executed. If it fails and executes the failure code then the debugger will be in the failure code. If it succeeds then it will appear as though the debugger did not enter the method. Additionally, there are a few special primitive methods that perform some other method, such as #perform:, in these methods the debugger will return control in the client method. One other thing, you need to be careful when putting breakpoints in methods that are used by the rest of the system. You can end up hanging your image. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Roberto Fonseca [mailto:[hidden email]] > Sent: Monday, June 04, 2007 2:51 PM > To: [hidden email] > Subject: RE: How to remove a class extension from a package > > Hello list, > > I'm a newbie Smalltalk developer and am currently working on a project > to migrate code from VW 3.0 to VW 7.4. I hit an issue that I'm > wondering if anyone out there could help me out with. I have the > following code that formats a table columns: > > elementFormats > "^an Array > Private" > > ^#(#left #left #left #right #right #right #right #right) > at: 1 put: self duplicateBlock; > at: 6 put: self actualVsCurrentBlock; > yourself > > When I execute this in v.7 it gives me the error Unhandled exception: > nil in > Array(Object)>>noModificationErrorFor:index:value: when sending the > first > at:put: message. > > When I execute this exact same code in v.3 no error message is issued. > I tried to debug the code in v.3 by stepping into the at:put: method > class but for an unknown reason (to me, at least) the debugger doesn't > display the called/executed class/method. Next, I added a breakpoint > to the Object class > at:put: method, but after executing the code again it didn't stop at > the breakpoint (so I am assuming that the Object class code is not > being executed in v.3.) Later on I changed the code in v.3 to the > > elementFormats > "^an Array > Private" > > |newArray| > newArray := Array new. > newArray > at:1 put: self duplicateBlock; > at: 6 put: self actualVsCurrentBlock; > yourself. > ^newArray > > When I execute this updated code the Object class breakpoint is reached. > From my very limited experience, I am guessing that there's probably a > class extension somewhere that has a different at:put: definition. Is > this a reasonable guess? The best way I know of finding this out is to > debug and check where the process is going to. But unfortunately I > can't step into the code. So, does anyone know of any way that I can > "force" the debugger to go into the method's class? maybe a special > combination of keys? By the way, the system uses ENVY and PDP debugger > in v.3. > > TIA and I apologize for the long email. > > Roberto Fonseca > Solution Center > Blue Heron Consulting > 90 Airpark Dr, Suite 200 > Rochester, NY 14624 > www.BlueHeron-Consulting.com > Office: 800.253.3449 / 585.464.8035 x 211 > Fax: 800.464.9901 / 585.464.9760 |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |