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 - >> arrrrggggGGGGGG!!!!! :) >> >> 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 > > _______________________________________________ > 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
