I started taking a look at the `NSJSONSerialization` work that needs to be
done. I’ll send a pull-request for what I have once I get some more tests
running. Anyone interested can see the first commit here:
https://github.com/owensd/swift-corelibs-foundation/commit/29c840fa7089dd9370d8199591dbbe
I would rather go right to the end game here and just work on coding up an
implementation of JSON encoding / decoding and making it conform to the
NSJSONSerialization spec. I can set up a repo for us to work on it.
The main decision here, is do we code a small lib in C and then call it from
the
I’m not sure about performance hit of calling C from Swift either (it should be
statically linked, so I suspect there is none), but the performance is only
marginally slower than NSJSONSerialization as is, in the pure Swift version I
am making. My test character set is about 2000 characters long
What I’m not so sure about is the most efficient way of working with NSData in
this context, considering we are very much assuming the data to have come from
a String of some kind (correct me if I’m wrong). So it seems to me like taking
NSData insead of just a String is a regression into Objecti
> On Dec 5, 2015, at 9:17 AM, Geordie Jay wrote:
>
> Sorry to spam, but I’ve just run some tests re: memory usage and found that
> running NSJSONSerialization.JSONObjectWithData() repeatedly results in huge
> memory usage (unbounded into the gigabytes). The pure Swift version I’ve been
> work
Hi Geordie,
The choice of NSData instead of String was very deliberate for
NSJSONSerialization. The reason is that JSON is received from disk or the
network as a data blob, not a String. Converting it into a String requires
figuring out the encoding and doing a conversion. NSJSONSerialization l
Revisiting this again, I’d like to start gathering some options and prepare to
work on some implementation. At this point I’m leaning towards python logging
(https://docs.python.org/3.6/library/logging.html) and even structlog
(http://structlog.readthedocs.org) APIs as a starting point.
So heari
Hi Jacob,
Thanks for bringing the discussion on this topic here.
One topic I wanted to discuss was finding a comprehensive list of API that
needs the attribute. The next step after that is figuring out how to get this
attribute to be consistent across Darwin and Swift open source.
One option w
> On Dec 5, 2015, at 1:44 PM, Jacob Bandes-Storch via swift-evolution
> wrote:
>
> One option was to use the API notes feature of the compiler to annotate these
> APIs as part of the import into Swift. Another is to get the C headers
> changed (on Darwin too) to add the attribute. We may want
On Sat, Dec 5, 2015 at 1:50 PM, Pierre Habouzit wrote:
>
>
> I completely agree with that statement, and I think that this change
> should make it into Darwin and swift-corelibs-libdispatch both.
>
> -Pierre
>
Pardon my ignorance, but what is intended to be the difference between the
two? Will th
On Sat, Dec 5, 2015 at 1:40 PM, Tony Parker
wrote:
> One topic I wanted to discuss was finding a comprehensive list of API that
> needs the attribute.
>
On this subject, here are some other APIs which could use the annotation.
Again, I think these should be annotated even in the C/Objective-C he
Hello Swift Developers,
I think it's a good idea to conform NSDate to the Comparable protocol, so
instead of using:
if someDate.compare(today) == .OrderedAscending { }
Developers can easily compare using compare dates using comparison
operators:
if someDate < today { }
In my opinion, the code
> I think it's a good idea to conform NSDate to the Comparable protocol, so
> instead of using:
>
> if someDate.compare(today) == .OrderedAscending { }
>
> Developers can easily compare using compare dates using comparison operators:
>
> if someDate < today { }
I would also suggest we add Stri
In all that seems like a pretty reasonable concept. Foundation is going to be
using the same evolution template as the rest of the Swift evolution process;
could you fill out a draft of that and I can help campion your proposal to the
component owner for NSDate and we can see how this will fair
Here's a draft of the the proposal:
https://gist.github.com/chrisamanse/2ab39e31e93d5c11d0b5
On Sun, Dec 6, 2015 at 7:52 AM Philippe Hausler wrote:
> In all that seems like a pretty reasonable concept. Foundation is going to
> be using the same evolution template as the rest of the Swift evoluti
> NSDate (and dates/timestamps in general) is a poor choice for Strideable,
> because, DST.
> A Calendar using this interface for a repeating event would be broken using
> this. Or you would break anyone who really wants to iterate every fixed 86400
> seconds.
Sometimes you want to add an inter
> It is simply not the case that *all* arithmetic on NSDates is incorrect
> unless it involves NSCalendar and NSDateComponents.
But then the same logic would follow that String must have all sorts of
convenient but incorrect API on it, because it is simply not the case that all
character transfo
17 matches
Mail list logo
