March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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.
|
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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?
|
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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
|
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to F i L | 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
|
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to F i L | 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.
|
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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. |
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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.
|
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 |
March 19, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
Copyright © 1999-2021 by the D Language Foundation