Re: [Pharo-project] about ValueAdapter
On Aug 27, 2010, at 11:50 PM, Schwab,Wilhelm K wrote: Stef, Re survival, I might have been concerned about possible poor behavior of the methods you mention, or that you might soon remove then in cleaning. I really don't remember. on base classes we want have better library and we pay attention that they do not impact people. I will indeed present the adapters as part of a larger whole. focus on one and make it shine people at good at generalization when provided with a nice example. That will take time to evolve though. I think some of what we see in Squeak is the result of a failure to separate the related problems into pieces with clear responsibilities. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 3:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project
Re: [Pharo-project] about ValueAdapter
Stef, I can build adapters easily enough, but the cool examples depend on a framework of which they are a very tiny part. Again, my immediate message is: (1) date and time to/from text conversions need to be somehow format specific; Dolphin solves that using a type converter hierarchy, and I have a very crude implementation of it for Pharo (2) Squeak's coercion of strings to numbers is probably a result of a failure to recognize the need for type converters. (3) my gradually evolving MVP framework will include type converters and value adapters. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Saturday, August 28, 2010 2:45 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter On Aug 27, 2010, at 11:50 PM, Schwab,Wilhelm K wrote: Stef, Re survival, I might have been concerned about possible poor behavior of the methods you mention, or that you might soon remove then in cleaning. I really don't remember. on base classes we want have better library and we pay attention that they do not impact people. I will indeed present the adapters as part of a larger whole. focus on one and make it shine people at good at generalization when provided with a nice example. That will take time to evolve though. I think some of what we see in Squeak is the result of a failure to separate the related problems into pieces with clear responsibilities. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 3:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you
Re: [Pharo-project] about ValueAdapter
On Aug 28, 2010, at 5:57 PM, Schwab,Wilhelm K wrote: Stef, I can build adapters easily enough, but the cool examples depend on a framework of which they are a very tiny part. Again, my immediate message is: (1) date and time to/from text conversions need to be somehow format specific; Dolphin solves that using a type converter hierarchy, and I have a very crude implementation of it for Pharo (2) Squeak's coercion of strings to numbers is probably a result of a failure to recognize the need for type converters. (3) my gradually evolving MVP framework will include type converters and value adapters. I would really like to have a MVP framework. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Saturday, August 28, 2010 2:45 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter On Aug 27, 2010, at 11:50 PM, Schwab,Wilhelm K wrote: Stef, Re survival, I might have been concerned about possible poor behavior of the methods you mention, or that you might soon remove then in cleaning. I really don't remember. on base classes we want have better library and we pay attention that they do not impact people. I will indeed present the adapters as part of a larger whole. focus on one and make it shine people at good at generalization when provided with a nice example. That will take time to evolve though. I think some of what we see in Squeak is the result of a failure to separate the related problems into pieces with clear responsibilities. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 3:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place
[Pharo-project] about ValueAdapter
Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
Stef, Re survival, I might have been concerned about possible poor behavior of the methods you mention, or that you might soon remove then in cleaning. I really don't remember. I will indeed present the adapters as part of a larger whole. That will take time to evolve though. I think some of what we see in Squeak is the result of a failure to separate the related problems into pieces with clear responsibilities. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 3:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
