<br><br><div class="gmail_quote">On Fri, Jul 15, 2011 at 8:50 AM, Mark Evenson <span dir="ltr"><<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br>
On Jul 14, 2011, at 20:42 , Erik Huelsmann wrote:<br>
><br>
> My idea would be to disambiguate the two functions by making writeToString() a java-side PRINT-OBJECT, renaming it to printObject() and documenting that's what it does. Then, probably, the lisp side function %write-to-string should be renamed to %print-object too. Probably, more adjustments are required throughout the code base, but those are probably at the 'implementation detail' level.<br>


<br>
</div>I think that the meaning of writeToString() was that the function<br>
should provide an implementation of serialization to a string able<br>
to be READ with the #S notation.  It is not really performing a<br>
PRINT-OBJECT-alike function which is a specialization of such an<br>
implementation on Lisp STANDARD-OBJECT or STRUCTURE-OBJECT.<br></blockquote><div><br></div><div>On the other hand, the clhs specifies that an implementation defines enough additional methods besides the STANDARD-OBJECT and STRUCTURE-OBJECT ones to make sure there will always be an applicable method. We seem to do that through a single T method which forwards to the internal writeToString() Java method.</div>

<div><br></div><div>Additionally, the clhs page for PRINT-OBJECT specifies that readable printing [for standard objects and structure objects] is done through the PRINT-OBJECT method rather than its MAKE-LOAD-FORM method. Many of our Java side functions try to behave this way by checking the values of the various *PRINT-xxx* special variables. One of the conclusions could be that our writeToString() functions are really trying to behave as PRINT-OBJECT implementations.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the other hand there is some justification for not calling such<br>
an implementation writeToString() as that will certainly confuse a<br>
Java user used to every object either inheriting or overrriding<br>
java.lang.Object.toString().  I might suggest then, that to clarify<br>
that this function isn't a direct implementation of CL's PRINT-OBJECT<br>
which actually takes an both arguments to specify the object it is<br>
operating on and to specify the output streamthat we rename the<br>
Java-side to writeLispObject(). The return type of this method,<br>
java.lang.String, makes something more verbose like<br>
writeLispObjectToString() superfluous.  I'd leave the Lisp<br>
%write-to-string alone, as the presence of WRITE-TO-STRING in the<br>
CL namespace makes it pretty clear that this is the primitive<br>
implementation.  Since %write-to-string has a simple implementation,<br>
looking up its behavior is rather easy.<br>
<br>
In any case, I would take advantage of the architecture I started<br>
to define in org.armedbear.lisp.protocol to create an interface<br>
which defines this contract:<br>
<br>
package org.armedbear.lisp.protocol;<br>
<br>
/** The implementing object can be serialized ala WRITE. */<br>
public interface WriteSerializable {  //  XXX not crazy about the name here<br>
  /** Serialize the implementing object instance in a manner that may be READ via #S */<br>
  public String writeLispObject();<br>
}<br>
<br>
and then make LispObject implement this interface.<br>
<br>
This provides a suitable place for encapsulation and documentation,<br>
being the natural place that a Java programmer will go to<br>
figure out what this method should do as it implements the interface.<br><br></blockquote><div><br></div><div>Given the purpose of PRINT-OBJECT as taken from the CLHS, I guess only the discussion about the naming remains? And of course the conclusion that if writeToString() actually implements the PRINT-OBJECT protocol, it's failing to do that horribly: generating unreadable presentations when *PRINT-READABLY* is bound to non-NIL values...</div>
<div><br></div><div>Right?</div><div><br></div><div><br></div><div>Bye,</div><div><br></div><div>Erik.</div></div>