You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pldes and related utilities currently perform plist dumps by using the description family of properties on the parsed object. Doing so causes information loss for NSValue and NSDate entries, a scenario that NSPropertyListGNUstepFormat was exactly invented for. It is my opinion that if a utility is described as a tool for "format conversion", they should get an option for trying to not lose too much data.
The text was updated successfully, but these errors were encountered:
Historically this would be because these utilities pre-date the possibility of storing NSValue and NSDate (these were later additions to the original property lists); the original property list format simply cannot represent those types of data (other than as strings).
I can see the point about wanting more options, but I think your idea of having a plutil program deal with such complexities makes sense, in which case there's probably no point enhancing pldes/plser (people could just use plutil)
I find this property to be misnamed as it was not defined in any version of OPENSTEP or Cocoa. Since it is GNUstep specific it should be GSPropertyListFormat regardless of which utility it is in.
Closing this since the tools already read all formats, the plser tool already has an option to select the write format, and there is now a plutil tool.
pldes and related utilities currently perform plist dumps by using the
description
family of properties on the parsed object. Doing so causes information loss for NSValue and NSDate entries, a scenario that NSPropertyListGNUstepFormat was exactly invented for. It is my opinion that if a utility is described as a tool for "format conversion", they should get an option for trying to not lose too much data.The text was updated successfully, but these errors were encountered: