Re: int | missing | absent
On Wednesday, 22 June 2022 at 01:09:22 UTC, Steven Schveighoffer
wrote:
On 6/2/22 9:24 AM, bauss wrote:
I feel it's too loose to make a best effort, and leave the rest
up to initial values, or just ignore possibly important
information during parsing.
-Steve
May be for your case Steve.
I need to represent in a "typed" way complex structures where
some properties can be "undefined" (not present in json) and
where null value is a valid value (and not the same that
"undefined" ones)... basically, the algebraic type Undefined |
Null | T
It isinefficient in memory terms (because D offers only
"structs", not the Typescript object equivalent where properties
accepts to be not present nativelly as part of the type
definition)
But it is, in my opinion, a needed feature: What if you want to
"patch" an entity or query an entity requiring only some of the
properties?... I don't want to build results using Json
objects... D is typed language and results should be built in a
rich typed structure (like: {id:"1324123", name:"peter",
age:18} or {id:"1234123", age:18 } **validated by compiler**.
When implementing rich REST services (with some complexity),
undefined native management is a must (and not the same than null
management).
I am currently using vibe-d json and the way it manages @optional
forces me to write custom serialization for all entities (to
properly manage undefined vs null)... it is anoying!!!
Re: Fetching licensing info for all dependencies of a DUB project
On 2020-05-12 15:23, Paul Backus wrote: On Tuesday, 12 May 2020 at 13:08:01 UTC, Joseph Rushton Wakeling wrote: On Tuesday, 12 May 2020 at 12:59:14 UTC, Paul Backus wrote: You should be able to get this information from the JSON output of `dub describe`. Cool, thanks. Much appreciated :-) Has anyone created any tools to condense that into a licensing report? No worries if not, just curious. Not that I know of. If you end up making one yourself, it might be worth posting in the Announce forum. Hi all, I played around with the idea and came up with a small dub package, that is not (yet) uploaded to the dub registry. Source is available at https://github.com/gizmomogwai/packageinfo, feedback very welcome. Kind regards, Christian
Re: int | missing | absent
On 6/27/22 9:03 AM, Antonio wrote:
On Wednesday, 22 June 2022 at 01:09:22 UTC, Steven Schveighoffer wrote:
On 6/2/22 9:24 AM, bauss wrote:
I feel it's too loose to make a best effort, and leave the rest up to
initial values, or just ignore possibly important information during
parsing.
May be for your case Steve.
I need to represent in a "typed" way complex structures where some
properties can be "undefined" (not present in json) and where null value
is a valid value (and not the same that "undefined" ones)... basically,
the algebraic type Undefined | Null | T
I see what you are saying. What needs to happen is first, you need a
type wrapper that does this, which defaults to undefined. Then mark it
optional so it's OK if it doesn't appear. Then only if the field is not
present will it be marked as undefined.
It may even be useful to make the type wrapper itself always optional,
rather than having to mark it optional.
It isinefficient in memory terms (because D offers only "structs", not
the Typescript object equivalent where properties accepts to be not
present nativelly as part of the type definition)
Well, in D you need reserve a place to hold it if present, or provide a
bucket to put it in (i.e. a JSON type).
But it is, in my opinion, a needed feature: What if you want to "patch"
an entity or query an entity requiring only some of the properties?... I
don't want to build results using Json objects... D is typed language
and results should be built in a rich typed structure (like:
{id:"1324123", name:"peter", age:18} or {id:"1234123", age:18 }
**validated by compiler**.
This is, in fact, the JSON algebraic type, which is present in most JSON
libraries.
When implementing rich REST services (with some complexity), undefined
native management is a must (and not the same than null management).
Yes, `null` in the stream is different than missing. But again, most
people would rather deal with concrete types rather than a dynamic JSON
type.
The iopipejson library does not really have a type for this, but it
would be a useful addition.
I am currently using vibe-d json and the way it manages @optional forces
me to write custom serialization for all entities (to properly manage
undefined vs null)... it is anoying!!!
Yeah, I can see that you would have to make a custom serialized option.
Though, doing this via a type is possible, without having to write
custom serialization for all entities.
Maybe you can provide an example, and there may be a solution that you
haven't thought of.
-Steve
Re: int | missing | absent
On Monday, 27 June 2022 at 23:05:46 UTC, Steven Schveighoffer wrote: ... Maybe you can provide an example, and there may be a solution that you haven't thought of. -Steve I first posted this "issue" to vibe-d: https://github.com/vibe-d/vibe.d/issues/2673
Re: int | missing | absent
On Monday, 27 June 2022 at 23:05:46 UTC, Steven Schveighoffer wrote: On 6/27/22 9:03 AM, Antonio wrote: On Wednesday, 22 June 2022 at 01:09:22 UTC, Steven Schveighoffer wrote: On 6/2/22 9:24 AM, bauss wrote: I feel it's too loose to make a best effort, and leave the rest up to initial values, or just ignore possibly important information during parsing. May be for your case Steve. I need to represent in a "typed" way complex structures where some properties can be "undefined" (not present in json) and where null value is a valid value (and not the same that "undefined" ones)... basically, the algebraic type Undefined | Null | T I see what you are saying. What needs to happen is first, you need a type wrapper that does this, which defaults to undefined. Then mark it optional so it's OK if it doesn't appear. Then only if the field is not present will it be marked as undefined. It may even be useful to make the type wrapper itself always optional, rather than having to mark it optional. Exactly. This issue/example in vibe-d treats about this solution and the annoying change of behavior treating "null" when @optional attribute is present: https://github.com/vibe-d/vibe.d/issues/2673 The code is a "simplification" of something more complex (Special wrappers for **Null | T**, **Undefined | T** and **Undefined | Null | T** with some functional stuff for match! and null-safe access (well, trying to: It's really complex and I'm not enought experienced). I Tried to base my solution in SumType, but I didn't know how to add the required fromRepresentation/toRepresentation methods for custom serialization/deserialization...
