Thanks Igor. I wonder if it would be possible instead to simply accept any object and only use type checks in case of an error? In that case, extra cycles don't matter. Or would an incompatible object crash the VM? I hope this doesn't seem like a dumb question, I'm just curious.
On 05.05.2013, at 17:43, Igor Stasenko <siguc...@gmail.com> wrote: > On 5 May 2013 12:14, Max Leske <maxle...@gmail.com> wrote: >> I have a wish for NativeBoost (which is probably on your list anyway Igor, >> just wanted to put it out there): function definitions should be able to >> understand that I want to accept any object of a hierarchy. >> >> Here's my use case: >> >> self call: #(git_return_t git_object_lookup(LGitCommitExternal * >> object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >> >> This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal >> and LGitBlobExternal. The obvious way for me to do this was to create a >> superclass LGitObjectExternal and use that superclass in the function like >> so: >> >> self call: #(git_return_t git_object_lookup(LGitObjectExternal * >> object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >> >> But that gives me an error. So for now I can either use a dummy object (like >> NBExternalObject) and then convert from that or I have to implement the same >> function thrice in the different object flavors. >> Being able to use a superclass would just be awesome! >> >> Cheers, >> Max > > As i told before, i am not using membership test, because it costs > extra cycles e.g.. > > object isKindOf: CommonSuperClass > > is much slower than > > object class == SomeSpecificClass > > if you look at NBExternalObjectType>>pushAsValue: / pushAsPointer: > it only checks that object belongs to specific class, doing > self verifyClassOf: oop is: objectClass generator: gen. > > The InterpreterProxy has > #includesBehavior:ThatOf: > method, which can be used to test if given class has some specific > ancestor in its inheritance chain. > > The main reason why i did not implemented the code that way is performance. > It is not that hard to implement this kind of test (see attached) > =========== > > Btw, we have a problem: > > - NativeBoost-Core in my 3.0 image shows that last version of it is > EstebanLorenzano.116 > there is not such package in NB repository. It is in Pharo30 repository.. > but when i open it, it shows that it has ancestor NativeBoost-Core-cb.117 > > Name: NativeBoost-Core-EstebanLorenzano.118 > Author: EstebanLorenzano > Time: 23 April 2013, 5:52:38.099 pm > UUID: d256a011-ce1f-4959-b5ed-37de2c7f3b84 > Ancestors: NativeBoost-Core-cb.117 > > which is not there. > Now i cannot merge with code which is in project repository. > > We should discuss, how we manage updates for NB.. because searching > packages located in > multiple repositories is tedious and counterproductive. > > > -- > Best regards, > Igor Stasenko. > <NBExternalType-verifyClassOfisMemberOfgenerator.st>
