--- a/ExternalAddress.st Thu Mar 31 17:31:13 2016 +0200
+++ b/ExternalAddress.st Thu Mar 31 17:31:32 2016 +0200
@@ -40,23 +40,24 @@
documentation
"
- Instances of this class represent external (non-Smalltalk) addresses.
- They are only useful to represent handles as returned by C functions
- as smalltalk objects.
- For example, Window- or WidgetIDs (which are actually 32 bit pointers) could be represented this way
- (better create a handle-subclass for it, to care for proper finalization).
+ Instances of this class represent external (non-Smalltalk) memory addresses.
+ They are only useful to represent handles as returned by C functions,
+ or to pass them to C functions.
+ For example, Window- or WidgetIDs (which are actually 32 bit pointers) can be represented this way,
+ but better create a handle-subclass for it, to care for proper finalization.
(you should not use SmallIntegers for this, since they can only represent 31
bits; LargeIntegers could be used in theory, but it is not a very good style
to do so, since it makes things a bit cryptic - having ExternalAddresses
around makes things pretty clear in inspectors etc.).
- There is not much you can do with ExternalAddresses on the smalltalk level;
+ There is not much you can do with ExternalAddresses on the Smalltalk level;
creation/use should be done in primitive C-code via
__MKEXTERNALADDRESS(voidPtr) and __ExternalAddressVal(obj).
- ExternallAddresses are much like ExternalBytes - however, the latter
- allow you to access bytes via indexed at:/at:put: messages.
- ExternalAddresses do not allow such accesses (they are meant to remain anonymous, opaque handles).
+ ExternalAddresses are much like ExternalBytes - however, ExternalAddresses do not know
+ the size of the memory block and therefore do not allow you to access bytes via indexed at:/at:put: messages
+ (which ExternalBytes do).
+ ExternalAddresses are meant to remain anonymous, opaque handles.
Also, memory blocks which are freeable should be represented as ExternalBytes.
[author:]