[squeak-dev] FFI package hierarchy (Re: FFI: FFI-Pools-mt.19.mcz)

Marcel Taeumel marcel.taeumel at hpi.de
Wed Jun 3 07:51:39 UTC 2020


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
Am 03.06.2020 01:02:59 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jun 2, 2020, at 11:41 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



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) ...

wouldn’t it just mean moving the win32-specific FFIExternalSharedPool subclasses to FFI-Win32 and the Unix-specific ones into FFI-Unix?


Best,
Marcel
Am 02.06.2020 20:39:28 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
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
Am 02.06.2020 20:36:05 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Marcel,


> On Jun 2, 2020, at 11:17 AM, commits at source.squeak.org 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.!
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200603/b5c9304d/attachment.html>


More information about the Squeak-dev mailing list