View mode: basic / threaded / horizontal-split · Log in · Help
March 19, 2012
Re: Proposal: user defined attributes
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
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
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
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
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
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
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
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
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
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
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home