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

Re: [Pharo-project] Anonymous subclasses support

by Igor Stasenko

On 16 December 2012 22:38, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > > On Sun, Dec 16, 2012 at 9:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 16 December 2012 19:42, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> wrote: >> > Hi guys, >> > >> > Can somebody tell what is the correct way of creating anonymous classes >> > in >> > Pharo? >> > When I say correct way I mean something that does not break the image or >> > the >> > tools. >> > >> > The thing is that we can use them in NativeBoost and I cannot stop >> > running >> > into errors because of these anonymous classes. >> > Is it just me or maybe we should do something about it... >> > >> > I am really frustrated about this thing because everybody knows that we >> > can >> > do it... but at the end of the day it is not working properly, >> > and has bizzare side effects. >> > >> >> Depends what you wanna do. >> >> > What about an official API for doing this? Or at least a way to check if >> > your class is anonymous so that we can refactor the tools to ignore them >> > or >> > something... >> > >> Using anonymous classes with tools which written to work with public ones >> will never work. >> There are too many places on different levels of system with strong >> assumptions about how things are organized. >> Perhaps if you tell, what you trying to do, we can see how to deal >> with problems. >> > > > 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... > indirection is your savior :) You can implement similar functionality as in ExternalArray, but instead of generating a pair of methods per class, make a class which holds following information: data type getter setter where getter and setter is generated functions for converting external value back and forth.. then in at: at:put: primitives should call these functions. With this setup you will need only single class, which instances responsible for holding rest of information about type & handling conversion of values. I know , this will make code a bit more complicated, but at the end you will not need to deal with anonymous classes anymore. Also, since you need only single getter/setter per value type, you can share them via cache controlled by class side. So, instead of climbing the wall, you can walk around it ;) > 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) > > Well that's about it for now... > -- Best regards, Igor Stasenko.

Dec. 16, 2012

Re: [Pharo-project] Anonymous subclasses support

by Ciprian Teodorov

On Sun, Dec 16, 2012 at 11:41 PM, Ciprian Teodorov < ciprian.teodorov(a)gmail.com> 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: > > actually no the #classChange selector gives me a nil ? I don't know... > >> 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 > -- 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. 16, 2012

Re: [Pharo-project] Anonymous subclasses support

by Ciprian Teodorov

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

Dec. 16, 2012

[Pharo-project] Apparently the new version of spec broke a bit the changeBrowser.

by stephane ducasse

So I'm in contact with ben to see. Else I will try to fix it tomorrow. Stef

Dec. 16, 2012

[Pharo-project] [update 2.0] #20438

by stephane ducasse

20438 ----- Issue 7123: Failing Test: BehaviorTest.testIsAbstractClass http://code.google.com/p/pharo/issues/detail?id=7123 Diff information: http://ss3.gemstone.com/ss/Pharo20/KernelTests-StephaneDucasse.459.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-StephaneDucasse.1270.diff

Dec. 16, 2012

Re: [Pharo-project] about isAbstractClass

by StÃ©phane Ducasse

Good suggestion I will change it to hasAbstractMethods it looks much better. Tx for the suggestion. Stef > > Better phrasing is: #definesAbstractMethods (note the define-'s'). > > The "defines" wording seems not quite right either. > How about: > #hasAbstractMethods > #declaresAbstractMethods > > >

Dec. 16, 2012

Re: [Pharo-project] Anonymous subclasses support

by StÃ©phane Ducasse

> 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 :). Stef

Dec. 16, 2012

Re: [Pharo-project] about isAbstractClass

by Yanni Chiu

On 16/12/12 4:34 PM, StÃ©phane Ducasse wrote: > > On Dec 16, 2012, at 7:29 PM, Igor Stasenko wrote: > >> On 16 December 2012 16:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> I will deprecate isAbstractClass and introduce defineAbstractMethods. >>> why? because as soon as we have an abstract method in Object nearly all the classes becomes abstract >>> and this does not make sense. >>> Now I can understand that we want to know if a class defineAbstractMethods and sometimes taking into account inheritance. >>> http://code.google.com/p/pharo/issues/detail?id=7123 >>> >> >> well, since in smalltalk you can make everything extremely late bound, >> i wonder, if it makes any sense to apply such terminology to classes at all. >> these terms coming from static languages in their attempt to add OO.. > > Because some people need that. Now defineAbstractMethods is much better than isAstractClass because > it just describes a real situation. Does a class has any subclassResponsibility method. > So this is a good compromise and encapsulation sendLiteralâ¦. in a nice little method is nice. Better phrasing is: #definesAbstractMethods (note the define-'s'). The "defines" wording seems not quite right either. How about: #hasAbstractMethods #declaresAbstractMethods

Dec. 16, 2012

Re: [Pharo-project] about isAbstractClass

by Ciprian Teodorov

On Sun, Dec 16, 2012 at 10:34 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Dec 16, 2012, at 7:29 PM, Igor Stasenko wrote: > > > On 16 December 2012 16:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> Hi guys > >> > >> I will deprecate isAbstractClass and introduce defineAbstractMethods. > >> why? because as soon as we have an abstract method in Object nearly > all the classes becomes abstract > >> and this does not make sense. > >> Now I can understand that we want to know if a class > defineAbstractMethods and sometimes taking into account inheritance. > >> http://code.google.com/p/pharo/issues/detail?id=7123 > >> > > > > well, since in smalltalk you can make everything extremely late bound, > > i wonder, if it makes any sense to apply such terminology to classes at > all. > > these terms coming from static languages in their attempt to add OO.. > > Because some people need that. Now defineAbstractMethods is much better > than isAstractClass because > it just describes a real situation. Does a class has any > subclassResponsibility method. > So this is a good compromise and encapsulation sendLiteralâ¦. in a nice > little method is nice. > > what about hasAbstractMethods ? or at least definesAbstractMethods (do this class defines abstract methods?) > 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

Dec. 16, 2012

Re: [Pharo-project] Anonymous subclasses support

by Ciprian Teodorov

On Sun, Dec 16, 2012 at 10:36 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Behavior new > I fixed it to work long time ago. > > Now you have to pay attention because depending on what you want to do you > will have to compile in these anonymous classes > some methods. > > Now I would avoid them. > > For now I was just pocking around, trying to use the nativeboost arrays and use them as a base for defining static arrays but well... we'll see where I get in the next episode ;) > Stef > > > Hi guys, > > > > Can somebody tell what is the correct way of creating anonymous classes > in Pharo? > > When I say correct way I mean something that does not break the image or > the tools. > > > > The thing is that we can use them in NativeBoost and I cannot stop > running into errors because of these anonymous classes. > > Is it just me or maybe we should do something about it... > > > > I am really frustrated about this thing because everybody knows that we > can do it... but at the end of the day it is not working properly, > > and has bizzare side effects. > > > > What about an official API for doing this? Or at least a way to check if > your class is anonymous so that we can refactor the tools to ignore them or > something... > > > > -- > > 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. 16, 2012