On 5 May 2013 22:19, Max Leske <maxle...@gmail.com> wrote: > 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. > err.. im not sure i understand. You either do the type check or you don't, and then get error if you pass wrong object, or crash. There is no 3rd option :) We can, however, introduce an option so you can turn strict type check on/off , or turn it off completely.
> > 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> > > -- Best regards, Igor Stasenko.
