MemberVar umbenennen

[Werner_Bayern]

Werner,

ich brauch ja nicht :next, sondern :next:href. Geht denn das auch über getNoIVar?

Jan

Ja:

Code: Alles auswählen

procedure main
local oData := dataobject():new()

oData:name := "Sepp"
oData:setNoIVar("next:href", "Josef")
? oData:getNoIVar("next:href")

wait
return

Sieht hier eigentlich jemand meinen geposteten Code?

[Werner_Bayern]

Nochmal, Wener: „next“ existiert. Irgendwas mit NoIVar geht da nicht.

Tom, schau mein Beispiel genauer an...
Ich setze mit setNoIVar die MemberVar, somit simuliere ich Jans JSON-String.

Dann kann ich die ganz normal mit getNoIVar ansprechen.

[HaPe]

Hallo Jan !

Der Fehler tritt beim kompilieren auf.

Und zwar an dem von dir geschrieben Code "oDoRueckgabe:links:next:href"
Den musst du so mit "next" schreiben weil next ein Element/Knoten im JSON-Objekt mit den Daten ist und du darauf zugreifen möchtest.

[Jan]

Hans-Peter,

so ist das korrekt. Und im Moment umgehe ich das dadurch, das ich wie ich das an anderer Stelle schon früher gemacht habe, und wie Tom das hier auch vorgeschlagen hat, direkt im von der Onlinedatenbank empfangenen JSON-String umschreibe. Und erst danach in das DataObject überführe.

Der Vorschlag von Werner hat aber auch was für sich. Muß ich mal in mich gehen, ob das nicht doch der bessere Weg wäre.

Jan

[brandelh]

Das Problem ist eindeutig eine Frage des SYNTAX PARSERS !

NEXT ist ein reserviertes Wort und das ist insoweit richtig, dass es geblockt wird und keine Variable so heißen darf.

ABER eine Member Var einer Klasse dürfte dieser Beschränkung nicht unterliegen insbesondere wenn es ein Feld eines Datenobjektes ist.
Alaska muss endlich hingehen und seinen Complier dahin gehend verbessern, dass er erkennt dass ...

oVar:next eben KEIN BEFEHL ist

Aber wir kennen Sie ja was sie von dieser Meinung halten, natürlich habe ich da völlig unrecht

[Jan]

Hubert,

da stimme ich Dir absolut zu. Der Support hat mir ja auch bestätigt, das der Bug bei denen bekannt ist. Hat aber, wie im Treffpunkt geschrieben, in absehbarer zeit keinen "Fixing-Zyklus" eingeplant. Das bleibt also erstmal offen. Leider.

Jan

[Tom]

Aber Werner hat recht. Mit GetNoIVar() kann man auf das "next" zugreifen, ohne einen Syntaxfehler zu riskieren:

Code: Alles auswählen

FUNCTION Main()
LOCAL cJsonText, oData

TEXT INTO cJsonText WRAP
{
  "Herausgeber": "Xema",
  "Nummer": "1234-5678-9012-3456",
  "Deckung": 10000,
  "Waehrung": "EURO",
  "next": 17,
  "Inhaber":
  {
    "Name": "Mustermann",
    "Vorname": "Max",
    "maennlich": true,
    "Hobbys": ["Reiten", "Golfen", "Lesen"],
    "Alter": 42,
    "Kinder": [],
    "Partner": null
  }
}
ENDTEXT

oData := Json2Var(cJsonText)

? oData:GetNoIvar("next") // Ergebnis: 17
oData:_next := oData:GetNoIvar("next")
? oData:_next // Ergebnis: 17

return NIL

Edit: Umkopieren in "_next" noch hinzugefügt.

[Jan]

Tom,

das ist ja schon fast das, was ich gesucht hatte. Zwar nicht die next direkt umbenennen, aber die einfach in einen anderen Namen rüber kopieren.

Werden denn dabei die Werte und nachgegliederten Memvars damit ebenfalls mit kopiert? Ansonsten würde das für mich ja keinen Sinn machen. ich habe ja die Abfrage auf :next:href. Wenn ich das wie von Dir aufgezeigt nach _next kopiere, brauche ich dann natürlich den (dann erlaubten) Zugruiff auf :_next:href.

Jan

[Tom]

Hallo, Jan.

Dann wäre "next" selbst ein Objekt, oder? Insofern sollte "href" auch in "_next" verfügbar sein. Probier's doch einfach aus.

[Tom]

Hab's gerade probiert, funzt. "_next" erbt die Instanzen von "next":

Code: Alles auswählen

FUNCTION Main()
LOCAL cJsonText, oData

TEXT INTO cJsonText WRAP
{
  "Herausgeber": "Xema",
  "Nummer": "1234-5678-9012-3456",
  "Deckung": 10000,
  "Waehrung": "EURO",
  "next":
  { "one": 1,
    "two": 2 },
  "Inhaber":
  {
    "Name": "Mustermann",
    "Vorname": "Max",
    "maennlich": true,
    "Hobbys": ["Reiten", "Golfen", "Lesen"],
    "Alter": 42,
    "Kinder": [],
    "Partner": null
  }
}
ENDTEXT

oData := Json2Var(cJsonText)

? oData:GetNoIvar("next") // Ergebnis: Data Object
oData:_next := oData:GetNoIvar("next")
? oData:_next:one // Ergebnis: 1

return NIL

[Jan]

Jan

[Tom]

Der Dank gebührt Werner.

[Werner_Bayern]

Gern geschehen

[AUGE_OHR]

ABER eine Member Var einer Klasse dürfte dieser Beschränkung nicht unterliegen insbesondere wenn es ein Feld eines Datenobjektes ist.

man kann doch auch kein Feld in einer DBF "NEXT" nennen.

---

in Daten Source werden KEYWORDs genutzt was der Hersteller der Datei wohl nicht weiss Man muss es ihnen sagen
das selbe Problem ist doch auch mit CSV Datei z.b. aus Excel wo Leute UMLAUTE oder chinesische Zeichen als Überschriften verwenden ...

Ich würde die Datei an dem Absender zurück schicken mit der Bemerkung das die "so" nicht zu gebrauchen ist und derjenige der die Datei erstellt hat wohl kein Ahnung von Schnittstellen hat. zudem würde ich eine KEYWORD Datei mitschicken von allen KEYWORDs die nicht erlaubt sind ... also alle xBase Befehle.

[Jan]

Ach Jimmy....

nur weil ich mit Xbase++ programmiere darf eine weltweite Onlinedatenbank mit Millionen Nutzern und Millarden von Einträgen kein next mehr einbauen? Die werden mir was husten wenn ich mit der IDee ankomme.

Abgesehen davon hat Alaska doch (wie schon mehrfach oben aufgeführt) anerkannt, daß das ein bekannter Bug ist.

Und wie ebenfalls oben schon von mehreer Diskutanten erwähnt gibt es einen Unterschied zwischen einer Variablen und einer MemVar oder Methode.

Jan

[brandelh]

Seit wann können WIR Kunden und Lieferanten vorschreiben wie sie ihre Schnittstellen zu kreieren haben ?

[AUGE_OHR]

erstaunt musste ich feststellen das man doch ein Feld mit dem Namen "NEXT" anlegen kann

wenn man dann mittels des Formdesigner XppFD Class Code generieren lässt und den compiliert :

File: TNEXT.prg Line: 85
_TNEXT.PRG(34:0): error XBT0223: NEXT does not match FOR
_TNEXT.PRG(45:0): warning XBT0112: Implicit method declaration, using class:
NewForm
_TNEXT.PRG(45:0): warning XBT0107: Method NEWFORM:INIT() does not end with RETURN
_TNEXT.PRG(46:0): warning XBT0112: Implicit method declaration, using class:
NewForm
_TNEXT.PRG(46:0): warning XBT0107: Method NEWFORM:CREATE() does not end with RETURN
_TNEXT.PRG(47:0): error XBT0251: Reserved keyword
_TNEXT.PRG(51:0): warning XBT0107: Method MAIN() does not end with RETURN
_TNEXT.PRG(103:0): error XBT0223: NEXT does not match FOR
_TNEXT.PRG(104:0): error XBT0223: NEXT does not match FOR
_TNEXT.PRG(105:0): error XBT0223: NEXT does not match FOR
_TNEXT.PRG(106:0): error XBT0223: NEXT does not match FOR
_TNEXT.PRG(159:0): error XBT0223: NEXT does not match FOR
7 error(s) found in file TNEXT.prg!

Der Befehl NEXT existiert ja nicht nur unter xBase. auch unter SQL gibt es NEXT.
ich weiss jetzt nicht wie es in anderen Programmier-Sprachen ist aber NEXT als Variabel wird wohl auch da nicht funktionieren.

es ist ein KEYWORD was jeder (gute) Datenbank Designer wissen müsste

---
@Jan
schon mal einen Gegentest mit Pablos JSON Functionen gemacht wie die an der Stelle "reagiert"

kannst uns einen Link zur der Onlinedatenbank verraten ... kann ja nicht Geheim sein bei so vielen Nutzern

[AUGE_OHR]

Seit wann können WIR Kunden und Lieferanten vorschreiben wie sie ihre Schnittstellen zu kreieren haben ?

je nachdem in welcher Phase des Projekts man betreiligt wird.
üblicherweise stellt man solche Problem schon bei der Planung fest und nicht erst in der Test Phase und da hat man Ansprechpartner.

[AUGE_OHR]

wenn Jan nun eine Datenbank anzapft die so viele Nutzer hat dann gehe ich davon aus das es wohl eine API dazu gibt.

angenommen man hätte diesen Code

Code: Alles auswählen

   Obj.Next.Number

und macht daraus

Code: Alles auswählen

   Obj:Next:Number

dann knallt es

es würde aber wohl (in vielen Fällen) gehen mit

Code: Alles auswählen

   Obj:Next(Number)

wie ich schon bat soll Jan mal mehr Fakten liefern damit man das IMHO eigentliche Problem erkennt.
Jan wird aber sicherlich nicht der erste sein, na ja mit Xbase++ ... , und alle anderen Sprachen sollen damit keine Probleme haben ...

[Jan]

Jimmy,

noch einmal: Alaska hat zugegeben, daß das bei denen ein Bug ist. Sobald die den behoben haben, kann man auch eine MemVar ode rMethode namens next nutzen. Punkt. Ende dieser Diskussion.

Die Datenbank findest Du unter www.familysearch.org. Da wirst Du aber nichts mit anfangen können. Man muß mit FamilySearch einen Vertrag schließen, um die API nutzen zu können. Der ist mehrstufug: Eine einfache Vereinbarung läßt Dich die Sandbox zum Testen und Entwickeln nutzen. Wenn man dann seine Software zertifizieren läßt, kann man auch die produktive nutzen. In Deutschland gibt es nur zwei zertifizierte Programme: Eines für den Mac, und meines. In den USA sieht das ganz anders aus, da gibt es dutzende. Über die Website kann natürlich jeder die Datenbanken nutzen. Da kommen auch die vielen Nutzerzahlen her. FamilySearch gehört neben 9 Pornoseiten zu den Top 10 der zugriffsstärksten Seietn der Welt. Was für ein Kontrast ...

Jan

[AUGE_OHR]

"das" ein KEYWORD wie NEXT nicht als Variabel oder CLASS Var verwendet werden kann ist klar, Punkt.
"das" es mit deiner Syntax dann nicht klappt ist auch klar denn ist steckt ja die iVar NEXT drin, Punkt.

Code: Alles auswählen

   oDoRueckgabe:links:next:href

---

warum ich nach Link und API frage : weil ich sehen möchte wie die Syntax wirklich aussieht.
im Beispiel

Code: Alles auswählen

   Obj.Next.Number

ist das NEXT IMHO keine Property sondern eine Method

---

wie ich schon fragte : hast du mal eine Gegen Probe mit Pablos JSON Version gemacht

da es ja das Data-Object ist was bei NEXT "versagt", weil es keine iVar mit dem Namen anlegen kann, würde ich ein Array nehmen um zu prüfen ob der Code überhaupt durchläuft und das erwartete Resultat liefert.

alternative gibt es die von Werner gezeigte Möglichkeit mit NoiVar ... und einem eigenen Data-Object.

[Tom]

Jimmy, Du schreibst Blödsinn. Lies einfach noch einmal in Ruhe den ganzen Thread. Es gibt kein Problem damit, iVars anzulegen, die „next“ heißen. Oder Objekte. Es gibt nur Syntaxprobleme. Die längst gelöst sind.

[Tom]

ist das NEXT IMHO keine Property sondern eine Method

Och, Jimmy.

Bei "Obj.Next.Number" ist "next" ein Objekt, das Instanz eines Objekts ist.

Das Problem träte auch auf, wenn Instanzen eines per Json (oder per Char2Var oder ähnlich) erzeugte Objektinstanzen "while" oder "endif" oder wie vergleichbare Schlüsselworte hießen. Auch dieser Code erzeugt Syntaxfehler beim Kompilieren:

Code: Alles auswählen

o := Json2Var(<cString>)
? o:while
? o:endif
* usw.

[AUGE_OHR]

hi Tom,

es ist ein Problem mit einer Syntax aufgetreten wo "next" drin ist.
Jan ist es "aufgefallen" als er mit DataObject die JSON Daten bearbeiten wollte.
nun wollte Jan die Ivar umbenennen ...

ich wette das es KEIN Probleme gäbe wenn man ein Array statt DataObject nehmen würde
also "was" ist das Problem das DataObject nicht klar kommt

---

also mal paar Test machen wie z.b. eine Variable oder IVar "next" zu benennen was ein KEYWORD ist

-> NEXT does not match FOR / Reserved keyword

es geht auch keine Function oder Method mit KEYWORD als Namen unter Xbase++ ... auch nicht mit NoIVar

---

der Windows Media Player ist ja allen bekannt. Die "Abspiel-Tasten" sind folgende METHODEn

WMP_NEXT.jpg (107.07 KiB) 9673 mal betrachtet

Die Syntax

Code: Alles auswählen

   object.next

steht also für eine Method

eine Windows App kann also durchaus eine Method "next" haben.
dito eine Windows Schnittstelle wie das JSON Format

---

das die Xbase++ Syntax von Jan nicht funktioniert wissen wir.
eine Property (= Ivar) "next" halt ich aus genannten Gründen für unwahrscheinlich aber die Method "next" gibt es oft

man kann also bei einem ".next" nicht sagen ob es eine Property oder Method sein soll.

---

wie ich schon sagte würde "ich" andere Wege versuchen das Problem zu lösen was vor 5 Tagen bemerkt wurde.

[Jan]

Jimmy,

kann es sein das Du auf Biegen und Brechen Recht haben möchtest?

Da das Problem in einem Xbase++-Bug liegt, würde auch Pablos JSON-Klasse scheitern. Die ja auch mit MemberVars arbeitet bei der Überführung des JSON-Strings in seine Klasse (ich habe Pablos Klasse benutzt, bis Alaska seine offiziell rausgebracht hat). Und noch einmal auch für Dich, der Du anscheinend noch immer nicht verstanden hast, wo eigentlich das Problem liegt (ganz einfach, weil Du viel zu kompliziert denkst, und weil Du partout Recht haben willst): Sobald im Code irgendwo ein":next" auftaucht, meckert der Compiler. Egal woher das kommt, egal wer das so geschrieben hat. Und ebenfalls noch einmal für Dich: Alaska hat diesen Bug anerkannt. Das Problem mit meinen Code nicht auf meine Programmierung oder den Lieferanten der Daten geschoben.

So, und können wir bitte diesen Punkt der Diskussion jetzt endgültig beenden? Es ist schon viel zu viel dazu geschrieben worden. zu einem Punkt, der absolut ausdiskutiert ist, der absolut klar ist, dessen Ursache vollkommen klar ist.

Jan