<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi Christian.<div><br></div><div>Thanks for the info! :-)</div><div><br></div><div>I suppose that the platform name 'unix' can only be a starting point for any platform-specific code. There is already #platformSubtype.</div><div><br></div><div>You are right. If bridge classes tend to duplicate such specialization logic, it makes sense to move it back to a generic platform object for other bridge classes to re-use. At best, one can generalize any subtlety to something that can be answered for all operating systems. Then, the question of subclassing vs. (state) composition is just a matter of taste.</div><div><br></div><div>Thinking about which layer moves faster than another, I prefer looking for #wordSize etc. over looking for #isUnix etc. If operating systems follow some standards (such as POSIX), this approach might lead to cleaner in-image code. :-) Not sure.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 27.05.2020 10:17:03 schrieb Christian Kellermann <ckeen@pestilenz.org>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hey Marcel,<br><br>* Marcel Taeumel <marcel.taeumel@hpi.de> [200527 08:37]:<br>> Hi Jacob,<br>> <br>> I just briefly looked at OSPlatform (and subclasses) in Pharo 7. I think those classes try to hold too much information from too many domains, which is sparkling a need for those platform subclasses.<br><br>If I may chime in, I did a port of Pharo to OpenBSD once, got it barely running<br>with all its ancient deps at the time...<br><br>But what has bitten me a lot in the FFI interface has been the assumption that<br>'unix' means linux and there has been no easy way to further distinguish the<br>subtle differences. Such as the architecture name for the 64bit platform, which<br>is 'amd64' for OpenBSD as an easy example. That has lead to ugly code which would<br>have been resolvable with more refactoring and fiddling apart the unix class into<br>more subclasses but I was a beginning smalltalker and fiddling with an integral<br>part of the Pharo image seemed daunting.<br><br>So I guess my summary is: If you settle for something called 'unix' don't make<br>assumptions that it's linux like, instead make it easy to subclass it further.<br><br>Thanks!<br><br>Christian<br><br>-- <br>May you be peaceful, may you live in safety, may you be free from<br>suffering, and may you live with ease.<br><br></marcel.taeumel@hpi.de></div></blockquote></div>