<div dir="ltr"><div>Hi all,</div><div>following the question of Marcel about usage of ExternalTypeAlias:</div><div><br></div><div>Type alias are subclasses of ExternalStructure.<br></div><div>I used them in HDF5 because there was no other means to define an alias at the time.</div><div>Now we have another mean by adding a class side method in ExternalType (I would have rather imagined the usage of some annotation to get a declarative style)</div><div><br></div><div>This has one advantage: type safety. You cannot pass a Foo to a function expecting a Bar, even if they both alias int...</div><div><br></div><div>But this has one major drawback: with current FFI, you cannot pass a Smalltalk Integer, to a method expecting a Bar, even if Bar is an alias for an integer type...</div><div><br></div><div>Thus, you have to wrap every Bar argument into a Bar instance...<br></div><div>Gasp, this is going too far...</div><div><br></div><div>What about functions returning such alias?</div><div>Function returning struct by value allocate a struct, but it's not the case here, FFI plugin is clever enough to recognize an atomic type alias and simply return a Smalltalk Integer...</div><div>So it's not Bar all the way down, I have to manually wrap Bar...</div><div>This is not consistent.</div><div>If we return an int, we must accept an int, otherwise, we cannot chain FFI calls...</div><div><br></div><div>I could use the lightweight alias instead, but there was another usage where it was convenient to use ExternalTypeAlias: enum.</div><div>Indeed, I simply defined all enum symbols as class side method. For example for enum bar { beg=0, mid=1, end=2 }; I simply create a type Bar aliasing int and having class side methods beg ^0, mid ^1, end ^2.</div><div>This way, I normally can pass a Bar mid to an external function.</div><div>(currently, we must defne mid ^Bar new value: 1; yourself)<br></div><div><br></div><div>If I use a simpler alias, where are those ids going to?</div><div><br></div><div><div>IMO we cannot keep statu quo in the plugin, we gotta to make the inputs/outputs behave consistently.</div></div> The choice is this one:<br><div>- should a function expecting an ExternalTypeAlias of atomic type accept an immediate value of compatible type? (the permissive implementation)<br></div><div>- should a function returning an ExternalTypeAlias of atomic type instantiate the Alias? (the typesafe implementation, with higher runtime cost due to pressure on GC)<br></div><div><br></div><div><br></div></div>