December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo Icon Revamped

by Esteban Lorenzano

I'm sorry, I don't like it at all :S On Dec 17, 2012, at 7:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > I like it. > Just make beam to go from the middle of the tower, > because right now it looks like beam comes from left side of it :) > > On 17 December 2012 19:48, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I spent my days reactivating my Illustrator skills and tried my luck > on the Pharo logo. I still lack the water and some perspective mismatches > with the stripes :) but for me this looks better than the current one :) > (as usual a highly subjective opinion). > > <pharo6.jpeg> > > cheers > cami > > > > -- > Best regards, > Igor Stasenko.

Dec. 17, 2012

Re: [Pharo-project] Persistence Options

by James Foster

http://www.seaside.st/documentation/persistence#180087651 might be a good start as a place to collect these comments. James On Dec 17, 2012, at 10:08 AM, Torsten Bergmann wrote: > Persisting data is crucial for any application and there > are many ways to do it. Be it RDBMS, NoSQL stuff or in-image > persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ... > > From time to time I ask the question here on the list > to see how it evolves and what people actually use in > their Pharo applications: > > 1. What persistence option do we currently have > 2. What persistence is used in your Pharo application today > 3. Which persistence solution you want to use/would you > like to see in Pharo's future > 4. What would you recommend. > > Comments as ever appreciated ... > > Bye > T. > >

Dec. 17, 2012

Re: [Pharo-project] Pharo Icon Revamped

by Igor Stasenko

I like it. Just make beam to go from the middle of the tower, because right now it looks like beam comes from left side of it :) On 17 December 2012 19:48, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I spent my days reactivating my Illustrator skills and tried my luck > on the Pharo logo. I still lack the water and some perspective mismatches > with the stripes :) but for me this looks better than the current one :) > (as usual a highly subjective opinion). > > > cheers > cami > -- Best regards, Igor Stasenko.

Dec. 17, 2012

Re: [Pharo-project] about isAbstractClass

by Igor Stasenko

On 17 December 2012 21:49, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Why not just add an instance variable in Class if the feature is that > important ? yes, i'd like to know why it is important. Because for me this is not obvious. The only thing which comes to my mind is: to please Java guys? :) > Of course, then it's better to add class creation messages to > initialize the variable... (and adapt various tools) > > Nicolas -- Best regards, Igor Stasenko.

Dec. 17, 2012

Re: [Pharo-project] about isAbstractClass

by Igor Stasenko

On 17 December 2012 21:41, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > > Eliot Miranda wrote: >> >> >> >> >> On Mon, Dec 17, 2012 at 10:41 AM, Andrew P. Black <black(a)cs.pdx.edu >> <mailto:black@cs.pdx.edu>> wrote: >> >> Two things make a class abstract. >> >> One is that it has methods that a subclass /must/ override â that is >> >> captured by #hasAbstractMethods. >> >> The other is that the class cannot be instantiated â normally >> because it has overridden new. >> It can be the case that an abstract class defines only CONCRETE >> methods for its subclasses, but still is abstract. So, it seems to >> me that #isAbstractClass is not subsumed by #hasAbstractMethods. >> >> A trait "AbstactClassT" could define #new to be "self error: 'Class >> ' , self name , ' is abstract and cannot be instantiated'" and >> #isAbstractClass to be ^ true. >> >> >> +3. > > > Is it really such a good idea? Unless I have missed something, the poor > subclass will have lot of trouble with `super new`, not to mention the need > to override #isAbstractClass. > +1 > For this to work, Behavior >> new would need to be overridden to throw this > error is `self isAbstractClass` is true. And isAbstractClass itself, to > leave the burden off of subclasses, would probably need to be generated as > `isAbstractClass ^ Foo == self` so trait could not help here (unless I am > able to find out the method definition class by some `thisContext method > homeClass`-like magic. > The magic is: self class == thisContext method methodClass .. and yes. i don't like that. Which just underlines my previous comment, that "abstract" concept in smalltalk applicable only on per-method basis.. but not per-class (like in other languages). -- Best regards, Igor Stasenko.

Dec. 17, 2012

Re: [Pharo-project] about isAbstractClass

by Nicolas Cellier

Why not just add an instance variable in Class if the feature is that important ? Of course, then it's better to add class creation messages to initialize the variable... (and adapt various tools) Nicolas 2012/12/17 Herby VojÄÃk <herby(a)mailbox.sk>: > > > Eliot Miranda wrote: >> >> >> >> >> On Mon, Dec 17, 2012 at 10:41 AM, Andrew P. Black <black(a)cs.pdx.edu >> <mailto:black@cs.pdx.edu>> wrote: >> >> Two things make a class abstract. >> >> One is that it has methods that a subclass /must/ override â that is >> captured by #hasAbstractMethods. >> >> The other is that the class cannot be instantiated â normally >> because it has overridden new. >> It can be the case that an abstract class defines only CONCRETE >> methods for its subclasses, but still is abstract. So, it seems to >> me that #isAbstractClass is not subsumed by #hasAbstractMethods. >> >> A trait "AbstactClassT" could define #new to be "self error: 'Class >> ' , self name , ' is abstract and cannot be instantiated'" and >> #isAbstractClass to be ^ true. >> >> >> +3. > > > Is it really such a good idea? Unless I have missed something, the poor > subclass will have lot of trouble with `super new`, not to mention the need > to override #isAbstractClass. > > For this to work, Behavior >> new would need to be overridden to throw this > error is `self isAbstractClass` is true. And isAbstractClass itself, to > leave the burden off of subclasses, would probably need to be generated as > `isAbstractClass ^ Foo == self` so trait could not help here (unless I am > able to find out the method definition class by some `thisContext method > homeClass`-like magic. > >> Andrew >> -- >> best, >> Eliot > > > Herby >

Dec. 17, 2012

Re: [Pharo-project] about isAbstractClass

by Herby VojÄÃk

Eliot Miranda wrote: > > > > On Mon, Dec 17, 2012 at 10:41 AM, Andrew P. Black <black(a)cs.pdx.edu > <mailto:black@cs.pdx.edu>> wrote: > > Two things make a class abstract. > > One is that it has methods that a subclass /must/ override â that is > captured by #hasAbstractMethods. > > The other is that the class cannot be instantiated â normally > because it has overridden new. > It can be the case that an abstract class defines only CONCRETE > methods for its subclasses, but still is abstract. So, it seems to > me that #isAbstractClass is not subsumed by #hasAbstractMethods. > > A trait "AbstactClassT" could define #new to be "self error: 'Class > ' , self name , ' is abstract and cannot be instantiated'" and > #isAbstractClass to be ^ true. > > > +3. Is it really such a good idea? Unless I have missed something, the poor subclass will have lot of trouble with `super new`, not to mention the need to override #isAbstractClass. For this to work, Behavior >> new would need to be overridden to throw this error is `self isAbstractClass` is true. And isAbstractClass itself, to leave the burden off of subclasses, would probably need to be generated as `isAbstractClass ^ Foo == self` so trait could not help here (unless I am able to find out the method definition class by some `thisContext method homeClass`-like magic. > Andrew > -- > best, > Eliot Herby

Dec. 17, 2012

Re: [Pharo-project] Interval protocol

by Nicolas Cellier

Hmm, the problem with MathMorph is that there are several concurrent implementations... Here is one possible, apparently not the one used in AlgebraicNumber... Maybe there is a version in http://www.squeaksource.com/MathMorphsRevival/ Nicolas 2012/12/17 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > It's from pre-Monticello era, http://www.dm.uba.ar/MathMorphs/ > If you follow the links, you'll have news from late 90s ;) > > 2012/12/17 Camillo Bruni <camillobruni(a)gmail.com>: >> >> On 2012-12-17, at 15:23, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Good. there is one in MathMorph too for years >> >> >> repository please? :)

Dec. 17, 2012

Re: [Pharo-project] about isAbstractClass

by Eliot Miranda

On Mon, Dec 17, 2012 at 10:41 AM, Andrew P. Black <black(a)cs.pdx.edu> wrote: > Two things make a class abstract. > > One is that it has methods that a subclass *must* override â that is > captured by #hasAbstractMethods. > > The other is that the class cannot be instantiated â normally because it > has overridden new. > It can be the case that an abstract class defines only CONCRETE methods > for its subclasses, but still is abstract. So, it seems to me that > #isAbstractClass is not subsumed by #hasAbstractMethods. > > A trait "AbstactClassT" could define #new to be "self error: 'Class ' , > self name , ' is abstract and cannot be instantiated'" and #isAbstractClass > to be ^ true. > +3. > > Andrew > > > On Sun, Dec 16, 2012 at 11:03 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > Good suggestion I will change it to hasAbstractMethods it looks much > better. > > Tx for the suggestion. > > > what about 'additionalAbstractMethods' that would return the list of > new abstract methods the class defines. > > > -- best, Eliot

Dec. 17, 2012

Re: [Pharo-project] Interval protocol

by Nicolas Cellier

It's from pre-Monticello era, http://www.dm.uba.ar/MathMorphs/ If you follow the links, you'll have news from late 90s ;) 2012/12/17 Camillo Bruni <camillobruni(a)gmail.com>: > > On 2012-12-17, at 15:23, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Good. there is one in MathMorph too for years > > > repository please? :)

Dec. 17, 2012