🚀 go-pugleaf

In article <3c766feb$0$4593$e4fe514c@dreader3.news.xs4all.nl>, Frans Bouma wrote:
> "Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> wrote in message news:3C7657FD.F7B825F7@wanadoo.nl...
>> Frans Bouma wrote:
> 
>> We zijn het dus eens dat alleen bij I/O (inclusief aanroep andere code)
>> het noodzakelijk is om het formaat vast te leggen. Mijn oplossing is om
>> het formaat van I/O vast te leggen en te converteren tijdens I/O, jouw
>> oplossing is om voor het hele programma de little/big endian vast te leggen.
> 
>     klopt. wellicht is in situatie A jouw oplossing beter en in situatie
>     B de 'mijne' (ivm het ontbreken van conversies)

Er is nog een D, die wij voor de typelibraries (unit files) toepassen:

Endianness in de header vastleggen, beide versies kunnen beide formaten
lezen, maar eigen gegenereerde zijn native, en lezen vlugger. Deze zullen
in de praktijk meer voorkomen.

Kanttekening is wel dat onze unit structuren redelijk simpel zijn, dus
dubbel uitvoeren kost niet veel extra code. Dit is natuurlijk niet altijd
zo.
 
>> Beide oplossingen zijn mogelijk (alhoewel misschien niet optimaal),
>> ik hoop dat we dat eens zijn.
> 
>     ok.

Endianness vastleggen voor gewoon gebruik (itt tot interfaces naar mogelijk
foreign entities (netwerk/mogelijk foreign files lezen etc) lijkt me niet
verstandig omdat dat altijd suboptimaal is voor een architectuur.
 
>> We wegen de voor- en nadelen verschillend, waardoor we op een verschillende
>> voorkeur uitkomen.
>> Dus: let's agree to disagree.
> 
>     ja, ik denk dat ik het belangrijk vind dat bij data manipulatie binnen
>     een systeem men niet aan conversies vast zit. 
> Bij communicatie tussen
>     systemen dmv webservices is men daarvan verlost ivm XML. Maar je
>     streaming voorbeeld is idd andere koek en is jouw oplossing te prefereren.

Hmm, agree fully. Maar dat betekent ook native op andere systemen, niet op "een"
systeem waarmee de byteorder toevallig overeenkomt.