FFIExternalType hooks; naming convention

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

FFIExternalType hooks; naming convention

eftomi
HI,

I have a couple of questions regarding FFI:

- If you want to create a new FFIExternalType subclass, which are the
necessary hooks that should be implemented - like #externalType,
#externalTypeSize … on the class side and #basicHandle:at:,
#basicHandle:at:put:, #stackValueParameterClass, etc. on the instance side?

- Is there anything else that should be done besides hooks - for instance
another "entries" into FFIConstants class>>#initializeTypeConstants or even
ExternalType>>#initializeAtomicTypes ?

- About naming standards: the ExternalData class has some methods that
"grab" strings from the heap, like ExternalData>>#fromCString and
ExternalData>>#readStringUTF8 - these two methods do the heavy work, however
the method ExternalData>>#readString more or less just refers to
ExternalData>>#fromCString. Is there any difference between "from..." and
"read..."?

Thanks!

Best wishes,
Tomaz



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Reply | Threaded
Open this post in threaded view
|

Re: FFIExternalType hooks; naming convention

EstebanLM
HI,

> On 21 Sep 2019, at 13:18, eftomi <[hidden email]> wrote:
>
> HI,
>
> I have a couple of questions regarding FFI:
>
> - If you want to create a new FFIExternalType subclass, which are the
> necessary hooks that should be implemented - like #externalType,
> #externalTypeSize … on the class side and #basicHandle:at:,
> #basicHandle:at:put:, #stackValueParameterClass, etc. on the instance side?

Yes, but in general you do not need to implement your type, you can derive what you need from the ones existing.
Why you need to do it?

>
> - Is there anything else that should be done besides hooks - for instance
> another "entries" into FFIConstants class>>#initializeTypeConstants or even
> ExternalType>>#initializeAtomicTypes ?

No.

>
> - About naming standards: the ExternalData class has some methods that
> "grab" strings from the heap, like ExternalData>>#fromCString and
> ExternalData>>#readStringUTF8 - these two methods do the heavy work, however
> the method ExternalData>>#readString more or less just refers to
> ExternalData>>#fromCString. Is there any difference between "from..." and
> "read…"?

At the begining, there was fromCString.
Then someone else added readStringUTF8.
Then I added readString because I like coherence :)

So readStrring is equivalent to fromCString, but I can imagine a better future where we have just one and it will be readString :P

Esteban

>
> Thanks!
>
> Best wishes,
> Tomaz
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>


Reply | Threaded
Open this post in threaded view
|

Re: FFIExternalType hooks; naming convention

eftomi
Hi,

> Yes, but in general you do not need to implement your type, you can derive what you need from the ones existing.
> Why you need to do it?

I'm just curious, I'm sorry :-) Depending on the platform, there is a huge number of various types - just on Windows there are wchar_t, char16_t and char32_t implementations of "wide char", at least that I know of, and one asks himself when and whether to go all the way "down". 

> So readStrring is equivalent to fromCString, but I can imagine a better future where we have just one and it will > be readString :P

:-)   

Thanks!

Best wishes,
Tomaz

------ Original Message ------
From: "Esteban Lorenzano" <[hidden email]>
To: "Any question about pharo is welcome" <[hidden email]>
Sent: 21. 09. 2019 17:28:34
Subject: Re: [Pharo-users] FFIExternalType hooks; naming convention

HI,
 
On 21 Sep 2019, at 13:18, eftomi <[hidden email]> wrote:
 
HI,
 
I have a couple of questions regarding FFI:
 
- If you want to create a new FFIExternalType subclass, which are the
necessary hooks that should be implemented - like #externalType,
#externalTypeSize … on the class side and #basicHandle:at:,
#basicHandle:at:put:, #stackValueParameterClass, etc. on the instance side?
 
Yes, but in general you do not need to implement your type, you can derive what you need from the ones existing.
Why you need to do it?
 
 
- Is there anything else that should be done besides hooks - for instance
another "entries" into FFIConstants class>>#initializeTypeConstants or even
ExternalType>>#initializeAtomicTypes ?
 
No.
 
 
- About naming standards: the ExternalData class has some methods that
"grab" strings from the heap, like ExternalData>>#fromCString and
ExternalData>>#readStringUTF8 - these two methods do the heavy work, however
the method ExternalData>>#readString more or less just refers to
ExternalData>>#fromCString. Is there any difference between "from..." and
"read…"?
 
At the begining, there was fromCString.
Then someone else added readStringUTF8.
Then I added readString because I like coherence :)
 
So readStrring is equivalent to fromCString, but I can imagine a better future where we have just one and it will be readString :P
 
Esteban
 
 
Thanks!
 
Best wishes,
Tomaz
 
 
 
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html