Compatibilité ascendante de PB ?

[DarkVader]

Bonjour,
L'historique des versions mentionne

Bibliothèque compression/décompression entièrement retravaillée avec ZIP, BriefLZ, 7z (décompression seulement), LZMA et JCALG1 (Windows x86 et UncompressMemory()seulement). JCALG1 support abandonné. Formats archives pour BriefLZ ont été modifiés.

La doc 5.11 concernant la librairie Packer

AddPackFile
AddPackMemory
ClosePack
CompressMemory
CreatePack
ExaminePack
NextPackEntry
OpenPack
PackEntryName
PackEntrySize
PackEntryType
RemovePackFile
UncompressMemory
UncompressPackFile
UncompressPackMemory
UseBriefLZPacker
UseJCALG1Packer
UseLZMAPacker
UseZipPacker

et la doc 4.51

AddPackFile
AddPackMemory
ClosePack
CreatePack
NextPackFile
OpenPack
PackFileSize
PackMemory
PackerCallback
UnpackMemory

laissent à supposer que des fonctions ont été supprimées ne permettant pas d'assurer une compatibilité ascendante sans avoir à remanier le code ! Qu'en est-il ?

J'ai cru comprendre que CompressMemory/UncompressMemory avec #PB_Packer_JCALG1 sont les substituts pour PackMemory.
CompressMemory fonctionne-t-il avec #PB_Packer_JCALG1 (la doc ne le mentionne pas) ?

Quelles sont les autres mauvaises surprises (suppression) depuis la version 4.51 nécessitant un remaniement de code ?

[comtois]

comme je n'utilise pas cette lib, j'ai suivi de loin ces changements, mais j'ai cru comprendre que JCALG1 était conservé pour décompresser les anciens fichiers afin de pouvoir les compresser dans les nouveaux formats supportés.

[djes]

Il n'y a pas une totale compatibilité ascendante, cependant comme PB est un langage léger et portable, tu peux très facilement avoir plusieurs versions sur le même ordinateur. Il m'arrive par exemple de laisser la version utilisée pour la réalisation d'un programme avec le code source, ça ne fait que quelques Mo de plus et je suis sûr que ça va compiler tout de suite.

Si ton programme est suffisamment modulaire, tu peux compiler une partie avec une version, et une autre avec une autre version !

Enfin, les changements sont souvent minimes, souvent un simple rechercher/remplacer suffit. Fred a toujours travaillé le côté générique des fonctions. C'est en partie pour cela qu'il ne reprend pas systématiquement les fonctions offertes par telle ou telle API ou bibliothèque de fonctions, il réfléchit d'abord au contexte, puis ensuite code quelque chose qui sera multi-plateformes et durable. C'est pas toujours évident, mais au moins le langage reste "propre", les choses obsolètes disparaissent et ne viennent plus encombrer nos "mémoires". C'est un style "oldschool" qui n'est plus vraiment à la mode, mais en laquelle on reconnait les programmeurs consciencieux

[DarkVader]

comme je n'utilise pas cette lib, j'ai suivi de loin ces changements, mais j'ai cru comprendre que JCALG1 était conservé pour décompresser les anciens fichiers afin de pouvoir les compresser dans les nouveaux formats supportés.

C'est ce que j'avais compris mais je m'interrogeais si d'autres librairies avaient également disparues avant de me lancer dans des modifications

Il n'y a pas une totale compatibilité ascendante, cependant comme PB est un langage léger et portable, tu peux très facilement avoir plusieurs versions sur le même ordinateur. Il m'arrive par exemple de laisser la version utilisée pour la réalisation d'un programme avec le code source, ça ne fait que quelques Mo de plus et je suis sûr que ça va compiler tout de suite.

J'ai plutôt opté pour une compilation conditionnelle qui gère les versions et un ajout des fonctions disparues avec le même prototype.

Si ton programme est suffisamment modulaire, tu peux compiler une partie avec une version, et une autre avec une autre version !

Enfin, les changements sont souvent minimes, souvent un simple rechercher/remplacer suffit. Fred a toujours travaillé le côté générique des fonctions. C'est en partie pour cela qu'il ne reprend pas systématiquement les fonctions offertes par telle ou telle API ou bibliothèque de fonctions, il réfléchit d'abord au contexte, puis ensuite code quelque chose qui sera multi-plateformes et durable. C'est pas toujours évident, mais au moins le langage reste "propre", les choses obsolètes disparaissent et ne viennent plus encombrer nos "mémoires". C'est un style "oldschool" qui n'est plus vraiment à la mode, mais en laquelle on reconnait les programmeurs consciencieux

Tout à fait d'accord, toutefois :
1/ il ne serait pas inutile de gérer un historique de nos chères disparues
2/ et accessoirement mettre à disposition un module wrapper recensant l'ensemble des fonctions «obsolètes»
(par exemple sous la forme que je viens d'exposer : compilerif #PB_Compiler_Version =511 : UseJCALG1Packer() : Procedure PackMemory()etc. )
ce qui permettrait de conserver une compatibilité ascendante totale à peu de frais.

[djes]

1/ il ne serait pas inutile de gérer un historique de nos chères disparues
2/ et accessoirement mettre à disposition un module wrapper recensant l'ensemble des fonctions «obsolètes»
(par exemple sous la forme que je viens d'exposer : compilerif #PB_Compiler_Version =511 : UseJCALG1Packer() : Procedure PackMemory()etc. )
ce qui permettrait de conserver une compatibilité ascendante totale à peu de frais.

1-> Il y a une historique dans l'aide
2-> c'est une bonne idée, seulement faut s'y coller