- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Anonymous subclasses support

by Ciprian Teodorov

On Mon, Dec 17, 2012 at 7:47 PM, Ciprian Teodorov < ciprian.teodorov(a)gmail.com> wrote: > Hi stef, > > I did some investigations and it seems to me that the problem comes from > the ChangesBrowser. It stores the changes in a Set which in turn changes > the order of declarations... So how can I define a method in a class that > does not exit? > The PickListModel is the culprit ;) > changing its pickedItemsHolder from Set new asValueHolder to OrderedCollection new asValueHolder fixes my issue ... but of course I don't really now where in the system the items are used as set ... Maybe we can change its name to PickSetModel or PickUnorderedListModel... by the way I find PickListModel not a good name at all It probably should be PickedListModel -> for the items pick*ed* from a list > > Bellow you will find the snippet that I have promised... > > model := RBNamespace new . > className := 'ANewClassForTheSystem' asSymbol. > model defineClass: > ('<1s> > subclass: #<2s> > instanceVariableNames: '''' > classVariableNames: '''' > poolDictionaries: '''' > category: <3p>' expandMacrosWith: 'NBExternalStructure' with: className > with: 'JustTesting'). > model compile: 'myInstanceMethod ^''Hello world'' ' in: (model > classNamed: className) classified: 'method declaration'. > > model compile: 'myClassMethod ^self new ' in: (model metaclassNamed: > className) classified: 'method declaration'. > "(ChangesBrowser changes: model changes ) openWithSpec ." > (ChangesBrowser new change: model changes ) openWithSpec . > > > Cheers > > On Mon, Dec 17, 2012 at 10:56 AM, Ciprian Teodorov < > ciprian.teodorov(a)gmail.com> wrote: > >> @Igor that's an idea ... I think I'll go with that for the initial version >> >> @stef I'll send a snippet this evening >> >> Cheers >> On Dec 17, 2012 9:39 AM, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> wrote: >> >>> could you send a snippet that generate code? >>> >>> Stef >>> >>> On Dec 16, 2012, at 11:41 PM, Ciprian Teodorov wrote: >>> >>> > >>> > >>> > On Sun, Dec 16, 2012 at 11:02 PM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> > > I'm writing a FFI generator for Pharo that uses libclang to parse >>> header files and generates nativeboost mapping as output. >>> > > The beast is almost working (I can get libclang mapping, the core.h >>> header)but there are still some small issues. So, that's why I've been >>> poking at nativeboost ;) >>> > > >>> > > At the end I expect to have something that will generate correct ffi >>> interface, and that will not bloat the image with thousand of visible >>> classes, so that the user might get a chance to understand something of >>> what I'm generating... >>> > > >>> > > The thing is this evening after 4-5 hours of looking around my >>> conclusion is. In pharo 1.4 the anonymous subclasses are breaking the >>> tools, and in the brand new pharo 2.0 the refactoring tools (RBNamespace & >>> company) are not working as they should.... so i'm stuck with 1.4 for now >>> (and still telling to myself that I do not want to bloat the image with >>> many classes) >>> > >>> > Can you tell us what is the problem you got with RBNamespace? >>> > Because if we know we can try to fix it :). >>> > >>> > When executing the refactorings that generate my code I get a DNU... >>> (see attached .png) it seem that RBAddMethodChange does not implement the >>> #includesSelector: >>> > >>> > >>> > Stef >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > Dr. Ciprian TEODOROV >>> > IngÃ©nieur DÃ©veloppement CAO >>> > >>> > tÃ©l : 06 08 54 73 48 >>> > mail : ciprian.teodorov(a)gmail.com >>> > www.teodorov.ro >>> > <PharoScreenshot.png> >>> >>> >>> > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 17, 2012

[Pharo-project] Pharo Icon Revamped

by Camillo Bruni

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

Dec. 17, 2012

Re: [Pharo-project] Anonymous subclasses support

by Ciprian Teodorov

Hi stef, I did some investigations and it seems to me that the problem comes from the ChangesBrowser. It stores the changes in a Set which in turn changes the order of declarations... So how can I define a method in a class that does not exit? The PickListModel is the culprit ;) Bellow you will find the snippet that I have promised... model := RBNamespace new . className := 'ANewClassForTheSystem' asSymbol. model defineClass: ('<1s> subclass: #<2s> instanceVariableNames: '''' classVariableNames: '''' poolDictionaries: '''' category: <3p>' expandMacrosWith: 'NBExternalStructure' with: className with: 'JustTesting'). model compile: 'myInstanceMethod ^''Hello world'' ' in: (model classNamed: className) classified: 'method declaration'. model compile: 'myClassMethod ^self new ' in: (model metaclassNamed: className) classified: 'method declaration'. "(ChangesBrowser changes: model changes ) openWithSpec ." (ChangesBrowser new change: model changes ) openWithSpec . Cheers On Mon, Dec 17, 2012 at 10:56 AM, Ciprian Teodorov < ciprian.teodorov(a)gmail.com> wrote: > @Igor that's an idea ... I think I'll go with that for the initial version > > @stef I'll send a snippet this evening > > Cheers > On Dec 17, 2012 9:39 AM, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > wrote: > >> could you send a snippet that generate code? >> >> Stef >> >> On Dec 16, 2012, at 11:41 PM, Ciprian Teodorov wrote: >> >> > >> > >> > On Sun, Dec 16, 2012 at 11:02 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> > > I'm writing a FFI generator for Pharo that uses libclang to parse >> header files and generates nativeboost mapping as output. >> > > The beast is almost working (I can get libclang mapping, the core.h >> header)but there are still some small issues. So, that's why I've been >> poking at nativeboost ;) >> > > >> > > At the end I expect to have something that will generate correct ffi >> interface, and that will not bloat the image with thousand of visible >> classes, so that the user might get a chance to understand something of >> what I'm generating... >> > > >> > > The thing is this evening after 4-5 hours of looking around my >> conclusion is. In pharo 1.4 the anonymous subclasses are breaking the >> tools, and in the brand new pharo 2.0 the refactoring tools (RBNamespace & >> company) are not working as they should.... so i'm stuck with 1.4 for now >> (and still telling to myself that I do not want to bloat the image with >> many classes) >> > >> > Can you tell us what is the problem you got with RBNamespace? >> > Because if we know we can try to fix it :). >> > >> > When executing the refactorings that generate my code I get a DNU... >> (see attached .png) it seem that RBAddMethodChange does not implement the >> #includesSelector: >> > >> > >> > Stef >> > >> > >> > >> > >> > >> > -- >> > Dr. Ciprian TEODOROV >> > IngÃ©nieur DÃ©veloppement CAO >> > >> > tÃ©l : 06 08 54 73 48 >> > mail : ciprian.teodorov(a)gmail.com >> > www.teodorov.ro >> > <PharoScreenshot.png> >> >> >> -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 17, 2012