On Sunday, 16 February 2014 at 20:57:28 UTC, Andrej Mitrovic
wrote:
On 2/16/14, Nordlöw per.nord...@gmail.com wrote:
I'm however not sure how serialization of base and superclasses
should be implemented in the most convenient way. Maybe somehow
has a good suggestion for this.
One way to do
On Monday, 17 February 2014 at 07:24:11 UTC, Jacob Carlborg wrote:
On Monday, 17 February 2014 at 06:09:35 UTC, Rory McGuire wrote:
A base class reference is: from your example an A which
actually contains a
C or B.
Honestly I haven't tried this I would have assumed that D
still gives you
Interesting, do you have to run though all registered classes that are
sub-classes of the base class and cast them checking for null?
On Mon, Feb 17, 2014 at 9:24 AM, Jacob Carlborg d...@me.com wrote:
On Monday, 17 February 2014 at 06:09:35 UTC, Rory McGuire wrote:
A base class reference
On 2014-02-17 13:20, Rory McGuire wrote:
Interesting, do you have to run though all registered classes that are
sub-classes of the base class and cast them checking for null?
No, that's not required. When a subclass is registered I'm storing a
templated delegate which performs the downcast.
On Mon, Feb 17, 2014 at 10:10 PM, Jacob Carlborg d...@me.com wrote:
No, that's not required. When a subclass is registered I'm storing a
templated delegate which performs the downcast. Have a look at these two
methods:
What features does it support? How does it handle:
* Arrays
* Slices
* Pointers
* Reference types
* Support for events
* Custom serialization
* Serialization of third party types
Slices are handled as arrays, because of the fact that they need
to be handled in such a way that many different
On 2014-02-16 18:52, Orvid King wrote:
Slices are handled as arrays, because of the fact that they need to be
handled in such a way that many different types of serialization formats
can support them, and be inter-operable with implementations in
languages other than D.
Pointers are not
I believe it's worth the try to get Python-style serialization
simplicity to D by default. We use Python cpickle at work and its
fantastically simple and fast. It handles just about everthing
you need by default as long as you have imported the modules that
contain the types involved in the
On 2/16/14, Nordlöw per.nord...@gmail.com wrote:
I'm however not sure how serialization of base and superclasses
should be implemented in the most convenient way. Maybe somehow
has a good suggestion for this.
One way to do it:
On 2014-02-16 21:45, Nordlöw wrote:
I believe it's worth the try to get Python-style serialization
simplicity to D by default. We use Python cpickle at work and its
fantastically simple and fast. It handles just about everthing you need
by default as long as you have imported the modules that
I already have all this in Orange [1], which I'm in progress of adapting
to a package for Phobos.
...
This requires registering the subclass in some way. In my implementation
one needs to call:
Serializer.register!(Sub);
For full example see [2].
[1]
Why not? Think of languages like C and C++, they only support pointers.
Pointers to basic types are not so interesting but pointers to structs
are.
Because, by serializing a pointer, you are implying that mechanism that
will be deserializing the value both exists on the same machine, and
On Sunday, 16 February 2014 at 22:41:59 UTC, Orvid King wrote:
Why not? Think of languages like C and C++, they only support
pointers. Pointers to basic types are not so interesting but
pointers to structs are.
Because, by serializing a pointer, you are implying that
mechanism that will be
On 2/16/14, Dicebot pub...@dicebot.lv wrote:
No, it should just serialize the pointed value and make the same
difference upon deserialization - if it is a value, write to it,
otherwise allocate new instance on heap and assign its address.
Speaking of related things like pointers and cyclic
On Sunday, 16 February 2014 at 22:48:51 UTC, Andrej Mitrovic
wrote:
On 2/16/14, Dicebot pub...@dicebot.lv wrote:
No, it should just serialize the pointed value and make the
same
difference upon deserialization - if it is a value, write to
it,
otherwise allocate new instance on heap and assign
A base class reference is: from your example an A which actually contains a
C or B.
Honestly I haven't tried this I would have assumed that D still gives you
the real type when using reflection but have you tried it?
On Mon, Feb 17, 2014 at 12:18 AM, Orvid King blah38...@gmail.com wrote:
Why
Do you have a JSON driver for Orange yet? Would be interesting to benchmark
Orange against a purpose designed JSON serialization library.
If your design is mostly compile time the experiment would be very
interesting (I think).
On Mon, Feb 17, 2014 at 12:03 AM, Jacob Carlborg d...@me.com
On Sunday, 16 February 2014 at 22:33:07 UTC, Orvid King wrote:
The problem with the way your doing it though is that it
requires that the library doing the deserialization is fully
aware of the semantics used in the serialization
implementation, rather than just the syntax and semantics of
On Sunday, 16 February 2014 at 22:41:59 UTC, Orvid King wrote:
Because, by serializing a pointer, you are implying that
mechanism that will be deserializing the value both exists on
the same machine, and lies within the same address space,
otherwise it will be referencing incorrect data.
On Monday, 17 February 2014 at 06:09:35 UTC, Rory McGuire wrote:
A base class reference is: from your example an A which
actually contains a
C or B.
Honestly I haven't tried this I would have assumed that D still
gives you
the real type when using reflection but have you tried it?
On Monday, 17 February 2014 at 06:14:51 UTC, Rory McGuire wrote:
Do you have a JSON driver for Orange yet? Would be interesting
to benchmark
Orange against a purpose designed JSON serialization library.
If your design is mostly compile time the experiment would be
very
interesting (I think).
Nice, hope the code is prettier than your speech. :D
On Fri, Feb 14, 2014 at 12:56 AM, Orvid King blah38...@gmail.com wrote:
Well, I wrote the code for this a while back, and although it was
originally intended as a replacement for just std.json (thus the repo
name), it does have the
On Thursday, 13 February 2014 at 22:56:38 UTC, Orvid King wrote:
so I'm releasing it as std.serialization.
What does that even mean? I'm pretty sure you should NEVER call a
library std.something if it hasn't been approved for inclusion
into standard library.
Other than that, nice work.
Orvid King wrote in message news:ntpjdeutsxqicjywt...@forum.dlang.org...
(except for float-string
conversion, which I don't understand the algorithms enough to
implement myself) even going so far as to create an output range
based version of to!string(int/uint/long/ulong/etc.).
On Thursday, 13 February 2014 at 22:56:38 UTC, Orvid King wrote:
Wow, that went a bit more towards a salesman-like description
than I as aiming for, so I'll just end this here and give you
the link, before this ends up looking like a massive, badly
written, sales pitch :D
On Friday, 14 February 2014 at 11:22:22 UTC, Daniel Murphy wrote:
Orvid King wrote in message
news:ntpjdeutsxqicjywt...@forum.dlang.org...
(except for float-string conversion, which I don't understand
the algorithms enough to implement myself) even going so far
as to create an output range
On Friday, 14 February 2014 at 10:41:54 UTC, Francesco Cattoglio
wrote:
On Thursday, 13 February 2014 at 22:56:38 UTC, Orvid King wrote:
so I'm releasing it as std.serialization.
What does that even mean? I'm pretty sure you should NEVER call
a library std.something if it hasn't been approved
On 2014-02-13 23:56, Orvid King wrote:
Well, I wrote the code for this a while back, and although it was
originally intended as a replacement for just std.json (thus the repo
name), it does have the framework in place to be a generalized
serialization framework, and there is the start of xml,
28 matches
Mail list logo
