A minor thing, but a fix is probably easy...

I have...

FFIExternalStructure subclass: #CXSourceLocation
instanceVariableNames: ''
classVariableNames: 'VoidPointer2'
package: 'Libclang'

initialize
�� �� "self initialize"
�� �� VoidPointer2 := FFITypeArray ofType: 'void*' size: 2.

fieldsDesc
�� �� "self rebuildFieldAccessors"
^#(
VoidPointer2 ptr_data;
uint int_data;
)


Now when I debug into "self rebuildFieldAccessors"
into #compileFields:withAccessors:
through�� "fieldSpec fieldsAndTypesDo: [ :fieldName :type |�� "
the [Variables] tab shows...��

�� �� �� type�� ����"FFITypeArrayType(a subclass of FFITypeArray)"

and my perception is that this is wrong��
since FFITypeArrayType is not a subclass FFITypeArray.
Intuitively I'm reading the text in the round brackets as a commentary on FFITypeArrayType.


But debugging into "type printString"
bring me to FFITypeArrayType(FFIExternalReferenceType) >> printOn: aStream

�� �� �� aStream << self className << '(' << objectClass name << ')'

where objectClass is an instance variable, so the commentary is about composition rather than inheritance.����

Now I properly understand the truth, I still have trouble with perceiving the printString the wrong way, so I'd like to add a visual cue that this is composition.��
Do we have such a standard convention?
Options...

1. Square brackets�� ��
a.�� �� �� FFITypeArrayType[a subclass of FFITypeArray]��
b.�� �� �� FFITypeArrayType([a subclass of FFITypeArray])

2. Curly brackets
a.�� �� ��FFITypeArrayType{a subclass of FFITypeArray}��
b.�� �� ��FFITypeArrayType({a subclass of FFITypeArray})��

3. Array-ish
a.�� �� ��FFITypeArrayType#(a subclass of FFITypeArray)��
b.�� �� ��FFITypeArrayType(#(a subclass of FFITypeArray))��

4. Text
a.�� �� ��FFITypeArrayType(holding a subclass of FFITypeArray)�� �� ��

I'm tending towards [2a] or [2b] since two brackets together seem more distinct.
It may be easy to overlook a difference in a single bracket,
and also it feels more like holding something inside the object.

cheers -ben


P.S. Regarding the existing Libclang bindings.�� I'm not trying to compete but more along the line... "its worthwhile reinventing the wheel when you want to learn more about how a wheel works."�� ��I'll switch over to existing bindings in a while.