On 3/19/12, Jacob Carlborg <doob@me.com> wrote:
> * Can be repeated on several fields (with the mixin you can only mixin
> "NonSerialized" once)

When I implemented NonSerialized for Vladimir's json library he made a suggestion to simply create enums of each field that is not to be serialized and encode it as "fieldname_nonSerialized". That would enable using a NonSerialized mixin multiple times.

I've yet to implement it in that way, I ran into some odd bugs but I'll have a look at this soon. My implementation used a hash lookup table for the fields, but using enums would make the code even simpler. Basically:

struct Foo
{
    int x;
    string name;
    mixin(NonSerialized!name);
    string lastName;
    mixin(NonSerialized!lastName);
}

and this would expand to:
struct Foo
{
    int x;
    string name;
    enum name_nonSerialized;
    string lastName;
    enum lastName_nonSerialized;
}

So all you'd have to do is use compile-time introspection and a little bit of string processing to figure out if a field should be serialized or not.

On Monday, 19 March 2012 at 20:44:43 UTC, Andrej Mitrovic wrote:
> On 3/19/12, Jacob Carlborg <doob@me.com> wrote:
>> * Can be repeated on several fields (with the mixin you can only mixin
>> "NonSerialized" once)
>
> When I implemented NonSerialized for Vladimir's json library he made a
> suggestion to simply create enums of each field that is not to be
> serialized and encode it as "fieldname_nonSerialized". That would
> enable using a NonSerialized mixin multiple times.
>
> I've yet to implement it in that way, I ran into some odd bugs but
> I'll have a look at this soon. My implementation used a hash lookup
> table for the fields, but using enums would make the code even
> simpler. Basically:
>
> struct Foo
> {
>     int x;
>     string name;
>     mixin(NonSerialized!name);
>     string lastName;
>     mixin(NonSerialized!lastName);
> }
>
> and this would expand to:
> struct Foo
> {
>     int x;
>     string name;
>     enum name_nonSerialized;
>     string lastName;
>     enum lastName_nonSerialized;
> }
>
> So all you'd have to do is use compile-time introspection and a little
> bit of string processing to figure out if a field should be serialized
> or not.


I think this could get tricky for the compiler to confidently use given that the mixed in enums can collide with existing members (although not likely). Also, if objects are not identified as being unique marked (in the compilers eyes), what specific attribute post-fixes will it be searching for on enums members?

On 3/19/12 3:44 PM, Andrej Mitrovic wrote:
> On 3/19/12, Jacob Carlborg<doob@me.com>  wrote:
>> * Can be repeated on several fields (with the mixin you can only mixin
>> "NonSerialized" once)
>
> When I implemented NonSerialized for Vladimir's json library he made a
> suggestion to simply create enums of each field that is not to be
> serialized and encode it as "fieldname_nonSerialized". That would
> enable using a NonSerialized mixin multiple times.
>
> I've yet to implement it in that way, I ran into some odd bugs but
> I'll have a look at this soon. My implementation used a hash lookup
> table for the fields, but using enums would make the code even
> simpler. Basically:
>
> struct Foo
> {
>      int x;
>      string name;
>      mixin(NonSerialized!name);
>      string lastName;
>      mixin(NonSerialized!lastName);
> }
>
> and this would expand to:
> struct Foo
> {
>      int x;
>      string name;
>      enum name_nonSerialized;
>      string lastName;
>      enum lastName_nonSerialized;
> }
>
> So all you'd have to do is use compile-time introspection and a little
> bit of string processing to figure out if a field should be serialized
> or not.

I salute creative uses of the language over defining new features.

Andrei

On 3/19/12 3:55 PM, F i L wrote:
> I think this could get tricky for the compiler to confidently use given
> that the mixed in enums can collide with existing members (although not
> likely). Also, if objects are not identified as being unique marked (in
> the compilers eyes), what specific attribute post-fixes will it be
> searching for on enums members?

Not a big issue, the name could always contain a uuid which makes collision practically impossibile.

Andrei

On 3/19/12, F i L <witte2008@gmail.com> wrote:
> Also, if objects are not identified as
> being unique marked (in the compilers eyes), what specific
> attribute post-fixes will it be searching for on enums members?

I'm really not talking about general-purpose attributes, I was commenting on a specific serialization example. :) Also I've no idea what "objects being unique marked" means.

On Monday, 19 March 2012 at 21:00:32 UTC, Andrei Alexandrescu wrote:
> On 3/19/12 3:55 PM, F i L wrote:
>> I think this could get tricky for the compiler to confidently use given
>> that the mixed in enums can collide with existing members (although not
>> likely). Also, if objects are not identified as being unique marked (in
>> the compilers eyes), what specific attribute post-fixes will it be
>> searching for on enums members?
>
> Not a big issue, the name could always contain a uuid which makes collision practically impossibile.
>
> Andrei

So the compiler would always search for enums with a specific "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx" signature? Guess that could work.

Andrej Mitrovic wrote:
> Also I've no idea what "objects being unique marked" means.

I meant that Attribute metadata is distinct data in the compilers eyes, ie, no name magic, just attribute lookup.

On Mon, Mar 19, 2012 at 04:00:00PM -0500, Andrei Alexandrescu wrote:
> On 3/19/12 3:44 PM, Andrej Mitrovic wrote:
[...]
> >So all you'd have to do is use compile-time introspection and a little bit of string processing to figure out if a field should be serialized or not.
> 
> I salute creative uses of the language over defining new features.

+1.


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee

On 2012-03-19 21:44, Andrej Mitrovic wrote:

> When I implemented NonSerialized for Vladimir's json library he made a
> suggestion to simply create enums of each field that is not to be
> serialized and encode it as "fieldname_nonSerialized". That would
> enable using a NonSerialized mixin multiple times.
>
> I've yet to implement it in that way, I ran into some odd bugs but
> I'll have a look at this soon. My implementation used a hash lookup
> table for the fields, but using enums would make the code even
> simpler. Basically:
>
> struct Foo
> {
>      int x;
>      string name;
>      mixin(NonSerialized!name);
>      string lastName;
>      mixin(NonSerialized!lastName);
> }
>
> and this would expand to:
> struct Foo
> {
>      int x;
>      string name;
>      enum name_nonSerialized;
>      string lastName;
>      enum lastName_nonSerialized;
> }
>
> So all you'd have to do is use compile-time introspection and a little
> bit of string processing to figure out if a field should be serialized
> or not.

Yeah, but that will complicate the retrieval of the information.

-- 
/Jacob Carlborg

On 2012-03-19 22:00, Andrei Alexandrescu wrote:

> I salute creative uses of the language over defining new features.
>
> Andrei

Sure, just as well as you can do object oriented programming in C, but it is a mess. So is this.

-- 
/Jacob Carlborg