On 05.05.2013, at 23:06, Igor Stasenko <siguc...@gmail.com> wrote:
> 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 :)
Yes, that was the idea. Only with the thought of doing the type check for the
user. Something like this:
[ <perform call without typecheck> ] on: Error do: [ :e | (type
isKindOf: expected)
ifTrue: [ NBCalloutFailed signal: 'expected…' ]
ifFalse: [ e pass ] ].
But that's only cool if possible without more VM crashes.
> We can, however, introduce an option so you can turn strict type check on/off
> ,
> or turn it off completely.
That's a pretty cool idea actually. What about extending that idea:
1. replace current typecheck with an #isKindOf: check
2. add option to turn typecheck on / off.
Then we'd have great feedback during development and would still be fast in
production by disabling the typecheck. What do you think?
>
>>
>> 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.
>
