<br><br><div class="gmail_quote">On Wed, May 25, 2011 at 10:51 AM, Runar Jordahl <span dir="ltr"><<a href="mailto:runar.jordahl@gmail.com">runar.jordahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I see three main uses for serializers:<br>
<br>
- Storing objects in databases and files.<br>
- Deep copy without manually having to implement copy methods.<br>
- Comparing objects.<br>
<br></blockquote><div><br>We took note, thanks :)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The last use is complex: Given two (possibly complex) object graphs,<br>
you could serialize both to a (separate) byte array, and then compare<br>
the two byte arrays to implement #=. In theory this could be a lot<br>
easier than manually implementing the comparison. However, depending<br>
on the serializer and the contents being serialized, the byte arrays<br>
could represent two “equal” objects, but still have different byte<br>
contents:<br>
<br>
- “Equal” objects, represented by unequal objects: One graph has<br>
Integer 0, the other one has Float 0.0<br>
- Objects stored in different order: A Smalltalk Set being equal in<br>
the two graphs can have the element stored using different ordering.<br>
- Object IDs which should not be part of the comparison, would make<br>
the two byte arrays different.<br></blockquote><div><br>yep<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I am sure there are cases where a serializer could be used to<br>
implement #=, but I have so far not seen it used.<br>
<br>
I am looking at using Riak ( <a href="http://wiki.basho.com/" target="_blank">http://wiki.basho.com/</a> ) with Pharo. When<br>
storing a “business object” you have two choices:<br>
<br>
- Store a binary BLOB representing your object graph.<br>
- Store the object graph as JSON data.<br>
<br>
The last option essentially means you must do something similar to OR<br>
mapping, so I would prefer the first option. With Riak, you will soon<br>
be able to store additional indexed properties, which you later will<br>
be able to query. So you store your whole business object as a BLOB,<br>
together with those properties you need to query.<br></blockquote><div><br>Ok, I understand. So, we can provide something like this API:<br><br>byteArray := FLSerializer serializeInMemory: myObject<br><br>And<br><br>myRecoveredObject := FLMaterializer materializeFromByteArray: aByteArray<br>
<br>would something like that help ?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I never tested SIXX with anything large. Saving space and time is of<br>
course a valid reason to make a new serializer. </blockquote><div><br>Sorry, I didn't want to look rude with my answer. But the two times we sent something about Fuel to the mailing list, the answers we received were "stop reiveinting the wheele". And this is completly the opposite. Why I am doing Fuel ? for fun? no. For fun I have other projects. I do it because I NEED it for my PhD. I would like not to spend time of Fuel and directly concentrate on my topic. But I need a fast serializer that could serialize ANY kind of object in the image: MethodContext, Continuations, BlockClosure, CompiledMethos (with all kind of trailers and types), MethodDictionaries, full Classes and Traits, Set and Dictionaries without problems. Don't have problems with global references, support class re-shape, etc. In addition, I need to be able to understand the serializer, extend it and make sure it works. Fuel is really OOP, I can understand it, extend it for my own use, and very well tested/benchmarked. <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">If you use SIXX you<br>
might need to compress the XML before storing it, adding even more<br>
overhead.<br>
<br>
I really look forward to improvements in Fuel. Good luck!<br></blockquote><div><br>THanks!<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><br>
Runar<br>
_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>