August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Poll: missing libraries to support business

by Esteban Lorenzano

Yes, I would like to know why you think aqueakdbx is not business suitable... this is not in self-defese! we want to improve and your opinion matters :) On 2010-08-29 12:47:15 -0300, Mariano Martinez Peck <marianopeck(a)gmail.com> said: > > > 2010/8/29 Sudhakar Krishnamachari > <skrishnamachari(a)gmail.com> > >> My two cents long time in my blog on exactly the same subject: >> >> Its great to see a free version of Smalltalk at last measuring up to the >> needs of using it in an business sense and showing it to non-Smalltalker= > =92s >> and the =93IT managers=94 and not put them off. I am sure this is going t= > o make >> it difficult for VA and Cincom to create new small-medium shop sales goin= > g >> forward especially with Seaside, Magritte and raft of other frameworks >> actually being born in Squeak. There obviously is the crying need for >> >> High Priority: >> Enusure very high reliability of the base Pharo. No bugs that are not >> fixable by the average developer with a bit of google and sending a few >> emails. If it needs that one expert in one other end.. business continuit= > y >> is hugely impacted >> >> Primary: >> * better-faster VM aka Cog mainstream >> * Highly performant DBMS connectivity natively > > > Hi and thanks for the notes. > There is NO way to have native Smalltlak driver for propietary databases. > Even if I would love to have the database driver implemented in Smalltalk > rather than calling a C library, this is not possible with propiertary > databases. If you don't have a public protocol or API there is no way to > build the driver. Do you think Oracle or Microsoft would do a Smalltalk > driver? I doubt it. So....for propietary databases....you have to somehow, > use of the the existing database drivers. > > ALL databases have a driver in C, usually called Database Client Library. C > is fast, and we have FFI. That's why SqueakDBX choosed OpenDBX. > > >> akin to JDBC through to all DBs no DB specific stuff like now, the Squeak >> DBX is not business friendly. >> > > Are you talking about SqueakDBX project ? (http://www.squeakdbx.org/) > If so, I would like you say it is not businness friendly. > > > >> * Comprehensive Web Services + XMLRPC >> * Pharo-Groovy bridge and / or Pharo-Ruby bridge ( or can we make Pharo >> work in tandem with a JVM..! this will help leverage the tons of framewo= > rks >> in existence even if they are tad slower than native Java) >> * Configuration Management System plugin for SVN >> > > There is SqueakSVN project. And I think in SCM they are doing to GIT. > > >> * Acceleration of easy docs and plugins/ web development related framewor= > k >> interfaces from Seaside viz flex/ silverlight: many that are possible as = > of >> now, but needs a Smalltalk expert to cobble it up >> * Have not really gone deeper with Webclient/ FTPClient/ SMTPClient et al= > s. >> they need to be really simple/ highly reliable/ dumbed down for the avera= > ge >> coder to pick snippets and make it work >> >> May be lots more.. I can bring in lot more thought this in terms of >> Generic/ Sectoral or Domain/ Type of Apps preferences viz: >> Banking/Insurance/Utilities/Technical/ Web vs GUI etc ...So first we shou= > ld >> think hard on the segment you want to hit harder.. >> >> Secondary: >> * Better tools for GUI Dev and more standard GUI development capabilities >> * Make Pharo easily usable for a team of 100+ developers together in >> one/multiple locations with code synch issues, change / version control , >> performance ( a host of other stuff included) taken care of. >> > > Agree. Torch project seems that could help here. Altoguht Monticello 2 or > similar would be needed. > > >> * Pluggable to industry standard tools for development: Rational/ Togethe= > r >> Soft viz for UML creation and conversion to code / reverse engineer code = > to >> UML >> > > > Carla worked on UML for this year GSoC project. It would probably be > integrated soon in Pharo. > > >> >> Follow through with: >> * Pluggable with QTP/ Testing Automation tools.. Actually this is very >> important in the standard large volume development. Makes a huge differen= > ce >> for the risk mitigation for the company. really inexpensive , kind of not= > so >> highly technical staff runs this show in comparison to Unit Tests/ test >> automation through ST code is a more riskier investment and I have not se= > en >> in JAva/ .Net / or even Smalltalk large legacy projects unit test done an= > d >> maintained well enough >> >> >> -Skrish >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > <br><br><div class=3D"gmail_quote">2010/8/29 Sudhakar Krishnamachari <span = > dir=3D"ltr"><<a > href=3D"mailto:skrishnamachari@gmail.com">skrishnamachar= i(a)gmail.com</a>></span><br><blockquote > > class=3D"gmail_quote" style=3D"ma= > rgin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding= > -left: 1ex;"> > My two cents long time in my blog on exactly the same subject:<br><br>Its g= > reat to see a free version of Smalltalk at last measuring up to > the needs of using it in an business sense and showing it to > non-Smalltalker=92s and the =93IT managers=94 and not put them off. I am su= > re > this is going to make it difficult for VA and Cincom to create new > small-medium shop sales going forward especially with Seaside, Magritte > and raft of other frameworks actually being born in Squeak. There > obviously is the crying need for<br><br>High Priority:<br>Enusure very high= > reliability of the base Pharo. No bugs that are not fixable by the average= > developer with a bit of google and sending a few emails. If it needs that = > one expert in one other end.. business continuity is hugely impacted<br> > > <br>Primary:<br>* better-faster VM aka Cog mainstream<br>* Highly performan= > t DBMS connectivity > natively</blockquote><div><br>Hi and thanks for the notes. <br>There is NO = > way to have native Smalltlak driver for propietary databases. Even if I wou= > ld love to have the database driver implemented in Smalltalk rather than ca= > lling a C library, this is not possible with propiertary databases. If you = > don't have a public protocol or API there is no way to build the driver= > . Do you think Oracle or Microsoft would do a Smalltalk driver? I doubt it.= > =A0 So....for propietary databases....you have to somehow, use of the the e= > xisting database drivers. <br> > <br>ALL databases have a driver in C, usually called Database Client Librar= > y. C is fast, and we have FFI. That's why SqueakDBX choosed OpenDBX. <b= > r>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0= > .8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> > akin to JDBC through to all DBs no DB specific stuff like now, the Squeak = > DBX is not business friendly.<br></blockquote><div><br>Are you talking abou= > t SqueakDBX project ?=A0 (<a href=3D"http://www.squeakdbx.org/">http://www.= > squeakdbx.org/</a>)<br> > If so, I would like you say it is not businness friendly. <br><br>=A0</div>= > <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= > r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">* Comprehensive W= > eb Services + XMLRPC<br> > * Pharo-Groovy bridge and / or Pharo-Ruby bridge ( or can we make Pharo wor= > k in tandem with a JVM..!=A0 this will help leverage the tons of frameworks= > in existence even if they are tad slower than native Java)<br> > * Configuration Management System plugin for SVN<br></blockquote><div><br>T= > here is SqueakSVN project. And I think in SCM they are doing to GIT. <br>= > =A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8= > ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> > * Acceleration of easy docs and plugins/ web development related framework = > interfaces from Seaside viz flex/ silverlight: many that are possible as of= > now, but needs a Smalltalk expert to cobble it up<br> > * Have not really gone deeper with Webclient/ FTPClient/ SMTPClient et als.= > they need to be really simple/ highly reliable/ dumbed down for the averag= > e coder to pick snippets and make it work<br><br>May be lots more.. I can b= > ring in lot more thought this in terms of Generic/ Sectoral or Domain/ Type= > of Apps preferences viz: Banking/Insurance/Utilities/Technical/ Web vs GUI= > etc ...So first we should think hard on the segment you want to hit harder= > .. <br> > > <br>Secondary:<br>* Better tools for GUI Dev and more standard GUI developm= > ent capabilities<br>* Make Pharo easily usable for a team of 100+ developer= > s together in one/multiple locations with code synch issues, change / versi= > on control , performance ( a host of other stuff included) taken care of. <= > br> > </blockquote><div><br>Agree. Torch project seems that could help here. Alto= > guht Monticello 2 or similar would be needed.<br>=A0</div><blockquote class= > =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= > rgb(204, 204, 204); padding-left: 1ex;"> > > * Pluggable to industry standard tools for development: Rational/ Together = > Soft viz for UML creation and conversion to code / reverse engineer code to= > UML<br></blockquote><div><br><br>Carla worked on UML for this year GSoC pr= > oject. It would probably be integrated soon in Pharo.<br> > =A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8= > ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>Foll= > ow through with:<br>* Pluggable with QTP/ Testing Automation tools.. Actual= > ly this is very important in the standard large volume development. Makes a= > huge difference for the risk mitigation for the company. really inexpensiv= > e , kind of not so highly technical staff runs this show in comparison to U= > nit Tests/ test automation through ST code is a more riskier investment and= > I have not seen in JAva/ .Net / or even Smalltalk large legacy projects un= > it test done and maintained well enough<br> > > <br><br>-Skrish<br><br><br> > <br>_______________________________________________<br> > Pharo-project mailing list<br> > <a > href=3D"mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project(a)lists.= gforge.inria.fr</a><br> <a > > href=3D"http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proj= > ect" target=3D"_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinf= > o/pharo-project</a><br></blockquote></div><br> > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by Mariano Martinez Peck

2010/8/29 Sudhakar Krishnamachari <skrishnamachari(a)gmail.com> > My two cents long time in my blog on exactly the same subject: > > Its great to see a free version of Smalltalk at last measuring up to the > needs of using it in an business sense and showing it to non-Smalltalkerâs > and the âIT managersâ and not put them off. I am sure this is going to make > it difficult for VA and Cincom to create new small-medium shop sales going > forward especially with Seaside, Magritte and raft of other frameworks > actually being born in Squeak. There obviously is the crying need for > > High Priority: > Enusure very high reliability of the base Pharo. No bugs that are not > fixable by the average developer with a bit of google and sending a few > emails. If it needs that one expert in one other end.. business continuity > is hugely impacted > > Primary: > * better-faster VM aka Cog mainstream > * Highly performant DBMS connectivity natively Hi and thanks for the notes. There is NO way to have native Smalltlak driver for propietary databases. Even if I would love to have the database driver implemented in Smalltalk rather than calling a C library, this is not possible with propiertary databases. If you don't have a public protocol or API there is no way to build the driver. Do you think Oracle or Microsoft would do a Smalltalk driver? I doubt it. So....for propietary databases....you have to somehow, use of the the existing database drivers. ALL databases have a driver in C, usually called Database Client Library. C is fast, and we have FFI. That's why SqueakDBX choosed OpenDBX. > akin to JDBC through to all DBs no DB specific stuff like now, the Squeak > DBX is not business friendly. > Are you talking about SqueakDBX project ? (http://www.squeakdbx.org/) If so, I would like you say it is not businness friendly. > * Comprehensive Web Services + XMLRPC > * Pharo-Groovy bridge and / or Pharo-Ruby bridge ( or can we make Pharo > work in tandem with a JVM..! this will help leverage the tons of frameworks > in existence even if they are tad slower than native Java) > * Configuration Management System plugin for SVN > There is SqueakSVN project. And I think in SCM they are doing to GIT. > * Acceleration of easy docs and plugins/ web development related framework > interfaces from Seaside viz flex/ silverlight: many that are possible as of > now, but needs a Smalltalk expert to cobble it up > * Have not really gone deeper with Webclient/ FTPClient/ SMTPClient et als. > they need to be really simple/ highly reliable/ dumbed down for the average > coder to pick snippets and make it work > > May be lots more.. I can bring in lot more thought this in terms of > Generic/ Sectoral or Domain/ Type of Apps preferences viz: > Banking/Insurance/Utilities/Technical/ Web vs GUI etc ...So first we should > think hard on the segment you want to hit harder.. > > Secondary: > * Better tools for GUI Dev and more standard GUI development capabilities > * Make Pharo easily usable for a team of 100+ developers together in > one/multiple locations with code synch issues, change / version control , > performance ( a host of other stuff included) taken care of. > Agree. Torch project seems that could help here. Altoguht Monticello 2 or similar would be needed. > * Pluggable to industry standard tools for development: Rational/ Together > Soft viz for UML creation and conversion to code / reverse engineer code to > UML > Carla worked on UML for this year GSoC project. It would probably be integrated soon in Pharo. > > Follow through with: > * Pluggable with QTP/ Testing Automation tools.. Actually this is very > important in the standard large volume development. Makes a huge difference > for the risk mitigation for the company. really inexpensive , kind of not so > highly technical staff runs this show in comparison to Unit Tests/ test > automation through ST code is a more riskier investment and I have not seen > in JAva/ .Net / or even Smalltalk large legacy projects unit test done and > maintained well enough > > > -Skrish > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 29, 2010

[Pharo-project] OSProcess - can it pipe 1 MB?

by Schwab,Wilhelm K

I am trying to pipe roughly 1 MB of data into a program on Linux; I know it can handle the load, because I have tested it with by cat-ing a script and the data. I do not yet promise that my Pharo code is correct; if the program did not respond or returned junk, I would look to myself. But I am getting errors suggesting that AttachableFileStream is failing on writing to the pipe, and it's very suspicious that it simply can't handle the size of the string. Any ideas? Bill

Aug. 29, 2010

[Pharo-project] Poll: missing libraries to support business

by Sudhakar Krishnamachari

My two cents long time in my blog on exactly the same subject: Its great to see a free version of Smalltalk at last measuring up to the needs of using it in an business sense and showing it to non-Smalltalkerâs and the âIT managersâ and not put them off. I am sure this is going to make it difficult for VA and Cincom to create new small-medium shop sales going forward especially with Seaside, Magritte and raft of other frameworks actually being born in Squeak. There obviously is the crying need for High Priority: Enusure very high reliability of the base Pharo. No bugs that are not fixable by the average developer with a bit of google and sending a few emails. If it needs that one expert in one other end.. business continuity is hugely impacted Primary: * better-faster VM aka Cog mainstream * Highly performant DBMS connectivity natively akin to JDBC through to all DBs no DB specific stuff like now, the Squeak DBX is not business friendly. * Comprehensive Web Services + XMLRPC * Pharo-Groovy bridge and / or Pharo-Ruby bridge ( or can we make Pharo work in tandem with a JVM..! this will help leverage the tons of frameworks in existence even if they are tad slower than native Java) * Configuration Management System plugin for SVN * Acceleration of easy docs and plugins/ web development related framework interfaces from Seaside viz flex/ silverlight: many that are possible as of now, but needs a Smalltalk expert to cobble it up * Have not really gone deeper with Webclient/ FTPClient/ SMTPClient et als. they need to be really simple/ highly reliable/ dumbed down for the average coder to pick snippets and make it work May be lots more.. I can bring in lot more thought this in terms of Generic/ Sectoral or Domain/ Type of Apps preferences viz: Banking/Insurance/Utilities/Technical/ Web vs GUI etc ...So first we should think hard on the segment you want to hit harder.. Secondary: * Better tools for GUI Dev and more standard GUI development capabilities * Make Pharo easily usable for a team of 100+ developers together in one/multiple locations with code synch issues, change / version control , performance ( a host of other stuff included) taken care of. * Pluggable to industry standard tools for development: Rational/ Together Soft viz for UML creation and conversion to code / reverse engineer code to UML Follow through with: * Pluggable with QTP/ Testing Automation tools.. Actually this is very important in the standard large volume development. Makes a huge difference for the risk mitigation for the company. really inexpensive , kind of not so highly technical staff runs this show in comparison to Unit Tests/ test automation through ST code is a more riskier investment and I have not seen in JAva/ .Net / or even Smalltalk large legacy projects unit test done and maintained well enough -Skrish

Aug. 29, 2010

Re: [Pharo-project] Magnitude should be reimplemented as a Trait

by Nicolas Cellier

I'm not comfortable with English, but to me Magnitude is about ordering rather than just comparing. I expect a TOrderable to describe a fully or partially ordered set. If you define this, then it is a fully ordered set: <= aMagnitude ^(self > aMagnitude) not Beware, due to introduction of NaN, Float is not fully ordered, this require overriding above message in Number. Nicolas 2010/8/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks this is cool :) > > Ideally I would like to have a deep look at the trait implementation and understand also how we can make it more pluggable > but I do not have the time for that. > > Stef > > On Aug 29, 2010, at 7:21 AM, jaayer wrote: > >> I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another. >> >> Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well. >> >> Additionally, I discovered that this message: >> isMetacelloConfig >> Â Â Â ^ false >> >> needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).<TComparable.st>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Tudor Girba

Hi, On 29 Aug 2010, at 12:31, Mariano Martinez Peck wrote: > On Sun, Aug 29, 2010 at 2:39 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com > > wrote: > I've stuck a version (5.8b4) of the cocoa based os-x squeak cog JIT > based VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b4.app.zip > > I spent the last two days becoming very familiar with Open/GL and > rewrote the display logic to use > Open/GL. I am still doing some further optimization, but people > should test this version and let > me know what they find. What are the implications of these optimizations? By the sound of it they should influence the rendering. Is that correct? Are there any tests we could do to see the improvements? > Other Fixes. > I think the control-arrow keys should work now, someone test this > and let me know. > > > Yes, it works! Thanks John. Hmm, the control-arrow and control-shift-arrow keys do not work for me. Is there anything in particular I should do to get them working? Cheers, Doru > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Some battles are better lost than fought."

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Mariano Martinez Peck

On Sun, Aug 29, 2010 at 2:39 AM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > I've stuck a version (5.8b4) of the cocoa based os-x squeak cog JIT based > VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b4.app.zip > > I spent the last two days becoming very familiar with Open/GL and rewrote > the display logic to use > Open/GL. I am still doing some further optimization, but people should > test this version and let > me know what they find. > > Other Fixes. > I think the control-arrow keys should work now, someone test this and let > me know. > > Yes, it works! Thanks John. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > >

Aug. 29, 2010

Re: [Pharo-project] OmniBrowser chapter for PBE 2 is now available

by Lukas Renggli

Some comments: - The term "Widget" is not used in the architecture of the OB framework anywhere. Maybe it would be better to replace it with the term "Panel" that is used in the framework. - Figure 1.1 depicts a bug of the un-themed scroll-bar that has been fixed a long time ago when Polymorph was introduced. - p. 9 at the bottom there is a comma disconnected from the previous word. - p. 12 "This enables a smooth gathering of independently realized commands." -> "..., and allows one to cleanly extend existing browsers without having to patch the system (e.g. refactoring browser)." - p. 13 The definition has nothing to do with editable text. By overriding the right methods in the OBNode a node is directly editable as well. The reason to have a separate OBDefintion is only to be able have multiple different definitions for a single node (e.g. to provide different views on source code from an OBMethodNode: source code, byte code, decompiled code, pretty-printed code). - p. 14 "Each of this method should return the class of the command (and not an instance of it)." This is not true. The requirement is that the returned object responds to #on:for:. There are examples where factory objects or OBCommand instances are returned. - p. 15 "These actions enable interaction with the domain model, however they do not allow further navigation in the metagraph." This is not true. There are various ways to navigate and update the metagraph, e.g. aNode signalSelection (see p.20 "Widget notification"). - Figure 1.5 does depict O2, not the "OmniBrowser System Browser" that is described in the text in Section 1.4. - p. 24: The acknowledgements fit to O2, but they seem distorted in the context of OmniBrowser. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2010

Re: [Pharo-project] Magnitude should be reimplemented as a Trait

by StÃ©phane Ducasse

thanks this is cool :) Ideally I would like to have a deep look at the trait implementation and understand also how we can make it more pluggable but I do not have the time for that. Stef On Aug 29, 2010, at 7:21 AM, jaayer wrote: > I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another. > > Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well. > > Additionally, I discovered that this message: > isMetacelloConfig > ^ false > > needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).<TComparable.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2010

[Pharo-project] Magnitude should be reimplemented as a Trait

by jaayer

I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another. Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well. Additionally, I discovered that this message: isMetacelloConfig ^ false needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).

Aug. 29, 2010