This seems to be working:
(class +Product +Entity)
(rel name (+Need +String))
(rel id (+Need +Number))
(rel descr (+String))
(setq Product (new '(+Product) 'name "PC" 'id 123))
(encObj> '+Json Product)
Where encObj> is simply an on the fly conversion to a paired list:
(dm encObj> (O)
(encPair> This
(make
(mapc
'((Prop)
(when (isa '+Relation (car Prop))
(let Key (cdr Prop)
(link (cons Key (get O Key))))))
(getl (car (type O)))))))
Can anyone see a scenario where the above way of getting the relations would
not work? In any case, the above generates the correct output with
{..."descr": false} at the end of the json string.
/Henrik
On Fri, Aug 22, 2008 at 9:46 AM, Henrik Sarvell <[EMAIL PROTECTED]> wrote:
>
> Thanks for the input Thomas but I think I will just go with paired lists
> instead, they are easier to manipulate with various list functions and
> should therefore be preferable to basic objects anyway. +Entity objects are
> on the list though.
>
> >> This is oversimplified version as there are lots of special cases in
> javascript to handle, e.g. you have to double-quote keys if they are
> negative numbers if I remember well:<<
>
> As far as I've been able to see any kind of key is double quoted in the
> json string (so that is what happens now), at least in the examples I've
> looked at.
>
> Now the question is, should we do basic objects when converting from json
> or paired lists. Basic objects are possible in that direction but that would
> then "break" with the rule of only accepting +Entity objects and paired
> lists for encoding.
>
> I don't know how a paired list vs a basic object compare when it comes to
> populating an +Entity object, any suggestions Alex? If an object is easier
> then that could motivate the decision to go for object when decoding and
> thus having different input and output formats.
>
> /Henrik
>
>
> On Fri, Aug 22, 2008 at 2:24 AM, Tomas Hlavaty <[EMAIL PROTECTED]> wrote:
>
>> Hi Henrik,
>>
>> >> convert all Ts to true, and NILs to false in the JSON string.
>>
>> > With the NILs we run into a problem, because a property value of NIL
>> > means that this property does not exist. So it can never be
>> > extracted from the object itself.
>>
>> maybe the js <-> picolisp mapping false <-> NIL is not the right thing
>> to do here? There are things like undefined, null, "" (empty string),
>> NaN (maybe too?) or false you could represent as NIL but then you lose
>> information during conversion and cannot rebuild the js data back
>> again exactly.
>>
>> > To solve the problem with the NILs, you'll have to keep a separate
>> > record of possible properties (as is done, for example, in the
>> > '+Entity' objects).
>>
>> Or, you could create your own unique NIL which would be treated by
>> picolisp as any other non-NIL value and interpret it yourself during
>> picolisp -> javascript conversion as false, for example.
>>
>> : (setq MyNIL (new))
>> (setq Tst (new))
>> (put Tst 'a "hello")
>> (put Tst 'b T)
>> (put Tst 'c MyNIL) # swap false, null, undefined or even NIL for MyNIL
>> (getl Tst)
>> (mapcar '((X) (or (pair X) (cons T X))) (getl Tst) )
>> (prog
>> (prin "[")
>> (for (I . X) (mapcar '((X) (or (pair X) (cons T X))) (getl Tst) )
>> (when (< 1 I)
>> (prin ", "))
>> (prin (cdr X) ": ")
>> (cond
>> ((== (car X) MyNIL) (prin "false"))
>> ((== (car X) T) (prin "true"))
>> (T (print (car X)))))
>> (prin "]"))
>> -> $519715527
>> : -> $519715537
>> : -> "hello"
>> : -> T
>> : -> $519715527
>> : -> (($519715527 . c) b ("hello" . a))
>> : -> (($519715527 . c) (T . b) ("hello" . a))
>> : [c: false, b: true, a: "hello"]-> "]"
>>
>> This is oversimplified version as there are lots of special cases in
>> javascript to handle, e.g. you have to double-quote keys if they are
>> negative numbers if I remember well:
>>
>> ["-1": "negative numbers as strings in key"]
>>
>>
>> Alex, why does getl return a list of (property-value . property-name)
>> and not a list of (property-name . property-value)?
>>
>> Cheers,
>>
>> Tomas
>> --
>> UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
>>
>
>
------=_Part_45459_577592.1219386676309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div dir="ltr">This seems to be working:<br><br>(class +Product
+Entity)<br>(rel name (+Need +String))<br>(rel id (+Need +Number))<br>(rel
descr (+String))<br><br>(setq Product (new '(+Product) 'name
"PC" 'id 123))<br>
<br>(encObj> '+Json Product)<br><br>Where encObj>
is simply an on the fly conversion to a paired list:<br><br>(dm encObj>
(O)<br> (encPair> This <br> (make
<br> (mapc
<br>
'((Prop)<br>
(when (isa '+Relation (car Prop))
<br>
(let Key (cdr Prop)
<br>
(link (cons Key (get O Key))))))
<br> (getl (car
(type O)))))))<br><br>Can anyone see a scenario where the above way of getting
the relations would not work? In any case, the above generates the correct
output with {..."descr": false} at the end of the json string.<br>
<br>/Henrik<br><br><div class="gmail_quote">On Fri, Aug 22, 2008 at 9:46 AM,
Henrik Sarvell <span dir="ltr"><<a href="mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]</a>></span> wrote:<br><blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left: 1ex;">
<div dir="ltr"><br>Thanks for the input Thomas but I think I will just go with
paired lists instead, they are easier to manipulate with various list functions
and should therefore be preferable to basic objects anyway. +Entity objects are
on the list though.<div class="Ih2E3d">
<br>
<br>>>
This is oversimplified version as there are lots of special cases in<br>
javascript to handle, e.g. you have to double-quote keys if they are<br>
negative numbers if I remember well:<<<br><br></div>As far as I've
been able to see any kind of key is double quoted in the json string (so that
is what happens now), at least in the examples I've looked at.<br>
<br>
Now the question is, should we do basic objects when converting from json or
paired lists. Basic objects are possible in that direction but that would then
"break" with the rule of only accepting +Entity objects and paired
lists for encoding. <br>
<br>I don't know how a paired list vs a basic object compare when it comes
to populating an +Entity object, any suggestions Alex? If an object is easier
then that could motivate the decision to go for object when decoding and thus
having different input and output formats.<br>
<font color="#888888">
<br>/Henrik</font><div><div></div><div class="Wj3C7c"><br><br><div
class="gmail_quote">On Fri, Aug 22, 2008 at 2:24 AM, Tomas Hlavaty <span
dir="ltr"><<a href="mailto:[EMAIL PROTECTED]" target="_blank">[EMAIL
PROTECTED]</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204,
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Henrik,<br>
<div><br>
>> convert all Ts to true, and NILs to false in the JSON string.<br>
<br>
> With the NILs we run into a problem, because a property value of NIL<br>
> means that this property does not exist. So it can never be<br>
> extracted from the object itself.<br>
<br>
</div>maybe the js <-> picolisp mapping false <-> NIL is not the
right thing<br>
to do here? There are things like undefined, null, "" (empty
string),<br>
NaN (maybe too?) or false you could represent as NIL but then you lose<br>
information during conversion and cannot rebuild the js data back<br>
again exactly.<br>
<div><br>
> To solve the problem with the NILs, you'll have to keep a separate<br>
> record of possible properties (as is done, for example, in the<br>
> '+Entity' objects).<br>
<br>
</div>Or, you could create your own unique NIL which would be treated by<br>
picolisp as any other non-NIL value and interpret it yourself during<br>
picolisp -> javascript conversion as false, for example.<br>
<br>
: (setq MyNIL (new))<br>
<div>(setq Tst (new))<br>
(put Tst 'a "hello")<br>
(put Tst 'b T)<br>
</div>(put Tst 'c MyNIL) # swap false, null, undefined or even NIL for
MyNIL<br>
(getl Tst)<br>
<div>(mapcar '((X) (or (pair X) (cons T X))) (getl Tst) )<br>
</div>(prog<br>
(prin "[")<br>
(for (I . X) (mapcar '((X) (or (pair X) (cons T X))) (getl Tst)
)<br>
(when (< 1 I)<br>
(prin ", "))<br>
(prin (cdr X) ": ")<br>
(cond<br>
((== (car X) MyNIL) (prin "false"))<br>
((== (car X) T) (prin "true"))<br>
(T (print (car X)))))<br>
(prin "]"))<br>
-> $519715527<br>
: -> $519715537<br>
: -> "hello"<br>
: -> T<br>
: -> $519715527<br>
: -> (($519715527 . c) b ("hello" . a))<br>
: -> (($519715527 . c) (T . b) ("hello" . a))<br>
: [c: false, b: true, a: "hello"]-> "]"<br>
<br>
This is oversimplified version as there are lots of special cases in<br>
javascript to handle, e.g. you have to double-quote keys if they are<br>
negative numbers if I remember well:<br>
<br>
["-1": "negative numbers as strings in key"]<br>
<br>
<br>
Alex, why does getl return a list of (property-value . property-name)<br>
and not a list of (property-name . property-value)?<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Tomas<br>
</font><div><div></div><div>--<br>
UNSUBSCRIBE: mailto:<a href="mailto:picolisp@software-lab.de";
target="_blank">picolisp@software-lab.de</a>?subject=Unsubscribe<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>
------=_Part_45459_577592.1219386676309--
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
-------
