Indice de chaine et notation à point

J’ai un objet qui comporte une propriété chaine (un chemin d’accès) dont je veux lire le dernier caractère.
[]32698437;“Your comment here…”[/]
Je mets aussi le code en texte, si quelqu’un s’y intéresse…

$posixPath:=Convert path system to POSIX(System folder(Desktop))
$caractereFin:=$posixPath[Length($posixPath)]
ASSERT($caractereFin="/")
$obj:=New object()
$obj.path:=$posixPath
$indiceFin:=Length($obj.path)
$caractereFin:=$obj.path[$indiceFin]
$caractereFin:=$obj.path[Length($obj.path)]
ASSERT($caractereFin="/")
ASSERT($obj.path[$indiceFin]="/")
ASSERT($obj.path[Length($obj.path)]="/") //Il manque une expression booléenne
ASSERT(($obj.path[Length($obj.path)])="/") //Il manque une expression booléenne

Dans le code ci-dessus, tout passe, sauf lignes 25 et 26 qui déclenchent l’erreur “Il manque une expression booléenne”. Si je regarde les :warning: en marge des lignes 22, 25, 26, le texte affiché au survol est toujours le même, “Délimiteur droit de chaine manquant”. Comme la ligne 22 ne pose aucun problème d’exécution, je ne sais que penser de cet avertissement. Est-ce un bug de 4D qui devrait accepter cette syntaxe, ou est-ce moi qui fait des choses tellement olé olé qu’il a le droit de me jeter ?

Moi je testerai:

$longueur:= Length($obj.path)
$caractereFin:=$obj.path[$longueur]

juste pour voir; si ça fonctionne, c’est que l’expression entre [] n’est pas évaluée. :mrgreen:

Après la conclusion :?:

Bonjour Gilbert,
dans la copie texte, le forum fait sauter les crochets doubles. Du coup je ne sais pas si ce que tu proposes de tester est identique à ce que je fais, voir ligne 21 de la copie écran ?

Désolé si j’ai lu trop vite mais j’ai l’impression qu’il y a mélange de 2 syntaxes et je vois pas bien comment il pourrait s’en sortir. J’essaierais bien un truc du type :

$caractereFin:=String($obj.path)[$indiceFin]

Bonsoir

Dans les tests fous :mrgreen:

Je mettrai en commentaire la ligne 21 pour voir ce que retourne la ligne 22 :wink:

et aussi

J’aurais aussi fait une ligne 27 avec des parenthèses ajoutées comme la 26 mais autour de l’expression à l’intérieur des doubles crochets.

Salut Arnaud,

je pense que 4D évalue la chaine entre crochet et retourne un texte. En modifiant comme cela, non seulement cela fonctionne, mais en plus c’est compilable.

<code 4D>
C_OBJECT($obj)
C_LONGINT($indiceFin)
C_TEXT($posixPath;$caractereFin)
$posixPath:=Convert path system to POSIX(System folder(Desktop))
$caractereFin:=$posixPath[Length($posixPath)]
ASSERT($caractereFin="/")
$obj:=New object(“path”;$posixPath)
$indiceFin:=Length($obj.path)
$caractereFin:=$obj.path[$indiceFin]
$caractereFin:=$obj.path[num(Length($obj.path))]
ASSERT($caractereFin="/")
ASSERT($obj.path[$indiceFin]="/")
ASSERT($obj.path[num(Length($obj.path))]="/") //Il manque une expression booléenne
ASSERT(($obj.path[num(Length($obj.path))]="/")) //Il manque une expression booléenne

</code 4D>

je remets aussi le code en texte ici:
C_OBJECT($obj)
C_LONGINT($indiceFin)
C_TEXT($posixPath;$caractereFin)
$posixPath:=Convert path system to POSIX(System folder(Desktop))
$caractereFin:=$posixPath[Length($posixPath)]
ASSERT($caractereFin="/")
$obj:=New object(“path”;$posixPath)
$indiceFin:=Length($obj.path)
$caractereFin:=$obj.path[$indiceFin]
$caractereFin:=$obj.path[num(Length($obj.path))]
ASSERT($caractereFin="/")
ASSERT($obj.path[$indiceFin]="/")
ASSERT($obj.path[num(Length($obj.path))]="/") //Il manque une expression booléenne
ASSERT(($obj.path[num(Length($obj.path))]="/")) //Il manque une expression booléenne

Pour encore plus de sûreté, je remplacerais partout où vous utilisez $obj.path par String($obj.path)…

Sauf que quand il n’y a pas le ‘Num’, il y a une erreur de compilation d’où mon interprétation que ce que l’on obtient en retour de ‘length’ est interprété comme étant un texte et non un numérique :wink:
Je ne dis pas que cela est normal, mais c’est ce que j’ai constaté

Justement en utilisant String (en plus, l’un n’empêche pas l’autre) sur la propriété de l’objet tu renforces le typage et tu gères le cas où si jamais la propriété n’existait pas(plus)…

dslé, je ne suis pas. Le mot ‘string’, tu le places où (je m’attends au pire vu que l’on est vendredi :wink: )

Et pour conclure et pour optimiser le code de calcul de l’indice, je passerais par une variable locale intermédiaire pour éviter de refaire les mêmes opérations à chaque itération/utilisation (si jamais on l’utilise dans une boucle par exemple).

Ouhlala, tu pars sur une pente glissante là… :lol:

voilà ce que je propose:
<code 4D>
C_LONGINT ($indice)
$indice:=num(Length(String($obj.path)))
$caractereFin:=$obj.path[$indice]

</code 4D>

ok.

Oui pourquoi pas, ceinture brettelles et parachute :wink:

Je peux encore faire mieux (ou pire :mrgreen:):
<code 4D>
C_TEXT($0)

C_TEXT($Toto)
$Toto:=String($obj.path)
C_LONGINT($indice)
$indice:=num(Length($Toto))
IF($indice>0)
$caractereFin:=$Toto[$indice]
ELSE
$caractereFin:=""
END IF

$0:=$caractereFin

</code 4D>

Effectivement :wink:

Dans tout ca, Arnaud nous a lâché. Il ne surenchéri pas

Il est parti faire le Black Friday :lol:

Le fourbe, il nous a refilé de quoi nous occuper et pendant ce temps là, il fait ses emplettes.

Merci Patrick, piste intéressante. Ne trouves-tu pas surprenant, quand Length retourne déjà un nombre, qu’il faille remettre une couche de conversion avec Num !?

De mon coté, comme je ne comprenais pas la réaction du assert qui dit “il manque une expression booléenne”, j’ai inversé le sens de la comparaison et comparé les comparaisons (sic) dans la zone expression. On voit que la première n’est pas considéré comme expression booléenne par 4D (il voit un texte), alors que la seconde l’est :
[]32724979;“Your comment here…”[/]
Si je colle des parenthèses, ça rentre dans l’ordre :
[]32725386;“Your comment here…”[/]

Du coup je continue de penser à une faiblesse de l’analyseur syntaxique, je ne vois pas pourquoi ça fonctionne dans un sens et pas dans l’autre, ni le besoin de parenthèses. J’ai bel et bien l’impression qu’il se prend les pieds entre les doubles crochets d’indice de chaine et les simples crochets de la notation à point, comme Éric l’évoquait.

PS : si je fais le choix de poster des copies écran, c’est qu’il est chouia compliqué de discuter d’un problème comme ça avec un forum qui charcute le code :frowning:

Je parle pas avec des individus qui nomment une variable toto ; même un vendredi, il y a des limites à la décence.

Effectivement c’est surprenant.
J’en suis arrivé à ajouter Num après avoir essayé aussi avec le parenthésage qui ne donnait rien.
Cela fait penser, comme tu le soulignes, à une faiblesse de l’analyseur syntaxique qui est lié à la notation à point, enfin la combinaison du . et []. J’utilise le double crochet que dans des cas extrême

Patrick

PS: Je t’ai répondu initialement depuis le train avec une connexion plus que moyenne, d’où l’absence de copie écran :wink: