FFI: FFI-Pools-mt.19.mcz
Locked
 
|
Marcel Taeumel uploaded a new version of FFI-Pools to project FFI:
http://source.squeak.org/FFI/FFI-Pools-mt.19.mcz ==================== Summary ==================== Name: FFI-Pools-mt.19 Author: mt Time: 2 June 2020, 8:17:16.425853 pm UUID: b602902a-6f8f-9549-adc7-d0cd5313cbf7 Ancestors: FFI-Pools-mt.18 Hmpf. Having "FFI-Kernel" and "FFI-Pools" in two separate packages is really annoying. ;-) =============== Diff against FFI-Pools-mt.18 =============== Item was changed: ----- Method: ExternalPoolReadWriter class>>initialize (in category 'class initialization') ----- initialize + "self initializeAtomicTypesExtra."! - self initializeAtomicTypesExtra.! |
|
|
Marcel,
> On Jun 2, 2020, at 11:17 AM, [hidden email] wrote: > > Marcel Taeumel uploaded a new version of FFI-Pools to project FFI: > http://source.squeak.org/FFI/FFI-Pools-mt.19.mcz > > ==================== Summary ==================== > > Name: FFI-Pools-mt.19 > Author: mt > Time: 2 June 2020, 8:17:16.425853 pm > UUID: b602902a-6f8f-9549-adc7-d0cd5313cbf7 > Ancestors: FFI-Pools-mt.18 > > Hmpf. Having "FFI-Kernel" and "FFI-Pools" in two separate packages is really annoying. ;-) So combine them. The pool functionality is essential core support for accessing external defines in a cross-platform way. I for one have no objection to you combining these for ease of development. > > =============== Diff against FFI-Pools-mt.18 =============== > > Item was changed: > ----- Method: ExternalPoolReadWriter class>>initialize (in category 'class initialization') ----- > initialize > > + "self initializeAtomicTypesExtra."! > - self initializeAtomicTypesExtra.! > > |
|
Hi Eliot. > So combine them. This would mean combining all of them. Including "FFI-Win32", "FFI-Unix", etc. Hmm... Or we add "FFIWin32" etc. (without the dash) ... Best, Marcel
|
|
|
Hi Eliot. > So combine them. This would mean combining all of them. Including "FFI-Win32", "FFI-Unix", etc. Hmm... Or we add "FFIWin32" etc. (without the dash) ... Best, Marcel
|
|
|
On Jun 2, 2020, at 11:41 AM, Marcel Taeumel <[hidden email]> wrote:
|
FFI package hierarchy (Re: FFI: FFI-Pools-mt.19.mcz)
|
|
I mean, should it be possible to load FFI-Kernel and FFI-Pools at once -- without loading FFI-Win32 etc., too? A package includes all class categories after a dash. That's why "FFI-PoolsTests" is not called "FFI-Pools-Tests": to be able to load "FFI-Pools" without loading "FFI-PoolsTests". Here is an idea for the FFI package hierarchy: FFI (incl. FFI-Kernel and FFI-Pools) FFITests (incl. FFITests-Kernel and FFITests-Pools) FFITools FFIExamples (incl. FFIExamples-Win32 and FFIExamples-Unix etc.) I suppose we could start putting important bridge classes -- the ones that are not just toy examples -- into another package, not FFI*. FFI might be important but it should rarely leak into higher-level abstractions such as by package name. Maybe we should start a "Platform" package? Looking at the primitive calls in "Files" and "Graphics" and "Kernel" (i.e. EventSensor), maybe something like this: Platform-Graphics Platform-Events Platform-Files A viable goal could be to keep the layer in the "Platform" package as thin as possible to then quickly dispatch to other, higher-level packages. Such as "Files" and "Graphics". :-) Such a distinction would render the "Kernel" package and the "Platform" package the two most basic things in the image. And "Collections", of course. :-D ...or we add "Kernel-Platform" and make that entry point for platform-specific graphics, events, files, etc. as part of the Kernel package. Not sure whether "Kernel" should (eventually) depend on the FFI package. Sounds unpleasant.
Best, Marcel
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |