On 16 December 2012 22:38, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
On Sun, Dec 16, 2012 at 9:41 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 16 December 2012 19:42, Ciprian Teodorov <ciprian.teodorov@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.