Jan Kiszka wrote:
> Jamie Lokier wrote:
> > Anthony Liguori wrote:
> >> Instead of encoding just as a string, it would be a good idea to encode
> >> it as something like:
> >>
> >> {'__class__': 'base64', 'data': ...}
> >
> > Is there a benefit to the class indirection, over simply a keyword?:
> >
> > {'__base64__': ...}
> >
> > __class__ seems to suggest much more than it's being used for here.
> >
>
> Depending on how sophisticated your parser is, you could directly push
> the result into an object of the proper type. And we can add more
> complex objects in the future that do not only consists of a single data
> key. Note that this extension is not just about encoding, it is about
> typecasting (dict -> custom type).
Sure, if that's the plan.
Does it make sense to combine encoding and custom types in this way?
It looks like mixing syntax and semantics, which has consequences for
code using generic parsers with separate semantic layer, but I realise
there's no "correct" answer.
Back to the syntax: I'm under the impression from earlier discussion
that the '__*__' keyspace reserved, so even types could use the
compact syntax?
Or is there something Javascript-ish (and not merely JSON-ish) about
'__class__' in particular which makes it appropriate?
-- Jamie
