Looks like the author posted a free copy of the paper here: http://www.hirschfeld.org/writings/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf
Thanks, Jon > On Sep 20, 2017, at 10:03 PM, Thorsten Seitz via swift-evolution > <[email protected]> wrote: > > > Am 24.08.2017 um 23:07 schrieb Eagle Offshore via swift-evolution > <[email protected] <mailto:[email protected]>>: > >> I liked the polymorphic identifiers paper presented at Dynamic Languages >> Symposium 2013. >> >> http://dl.acm.org/citation.cfm?doid=2508168.2508169 >> <http://dl.acm.org/citation.cfm?doid=2508168.2508169> >> There's a lot of power in URI's that remains largely untapped in most >> systems. >> >> There's not a great reason for this heterogeneity other than historical >> baggage. >> >> Properly done, URI's can unify keypaths, user defaults, environment >> variables, files, network stores, databases, etc. > > Would you mind summarizing the idea as the paper is not freely available? > > -Thorsten > > >>> On Aug 22, 2017, at 12:52 PM, Félix Cloutier via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Just leaving it out here that the iOS/macOS app experience with paths is >>> likely to be very different from the server (or system program) experience. >>> Most of your paths are relative to a container because the effective root >>> of your data is the container. I would tend to believe that a lot of your >>> paths, not while fully static, could be expressed with something like >>> "${DOCUMENTS}/static/part", where ${DOCUMENTS} is the only thing that >>> effectively changes. A system-level program just happens to use / as its >>> prefix. >>> >>> Most platforms already have some notion of file domains, which are really >>> just path prefixes (the user's home folder, the file system root, the >>> network root, etc). I think that some level of support for these would be >>> desirable (would it be only a set of functions that return different path >>> prefixes). It's also my humble opinion that tilde expansion should be part >>> of a larger shell expansion feature to avoid surprises. >>> >>> I think that I support the conclusion. >>> >>> Félix >>> >>> Le 22 août 2017 à 12:02, Dave DeLong <[email protected] >>> <mailto:[email protected]>> a écrit : >>> >>>> I suppose, if you squint at it weirdly. >>>> >>>> My current Path API is a “Path” protocol, with “AbsolutePath” and >>>> “RelativePath” struct versions. The protocol defines a path to be an array >>>> of path components. The only real difference between an AbsolutePath and a >>>> RelativePath is that all file system operations would only take an >>>> AbsolutePath. A URL would also only provide an AbsolutePath as its “path” >>>> bit. >>>> >>>> public enum PathComponent { >>>> case this // “." >>>> case up // “..” >>>> case item(name: String, extension: String?) >>>> } >>>> >>>> public protocol Path { >>>> var components: Array<PathComponent> { get } >>>> init(_ components: Array<PathComponent>) // used on protocol >>>> extensions that mutate paths, such as appending components >>>> } >>>> >>>> public struct AbsolutePath: Path { } >>>> public struct RelativePath: Path { } >>>> >>>> By separating out the concept of an Absolute and a Relative path, I can >>>> put additional functionality on each one to make semantic sense (you >>>> cannot concatenate two absolute paths, but you can concat any path with a >>>> relative path, for example). Or all file system operations must take an >>>> AbsolutePath. >>>> >>>> One of the key things I realized is that a “Path” type should not be >>>> ExpressibleByStringLiteral, because you cannot statically determine if a >>>> Path should be absolute or relative. However, one of the initializers for >>>> an AbsolutePath would handle things like expanding a tilde, and both types >>>> try to reduce a set of components as much as possible (by filtering out >>>> “.this” components, and handling “.up” components where possible, etc). >>>> Also in my experience, it’s fairly rare to want to deal with a >>>> known-at-compile-time, hard-coded path. Usually you’re dealing with paths >>>> relative to known “containers” that are determined at runtime (current >>>> user’s home folder, app’s sandboxed documents directory, etc). >>>> >>>> Another thing I’ve done is that no direct file system operations exist on >>>> AbsolutePath (like “.exists” or “.createDirectory(…)” or whatever); those >>>> are still on FileManager/FileHandle/etc in the form of extensions to >>>> handle the new types. In my app, a path is just a path, and it only has >>>> meaning based on the thing that is using it. An AbsolutePath for a URL is >>>> used differently than an AbsolutePath on a file system, although they are >>>> represented with the same “AbsolutePath” type. >>>> >>>> I’m not saying this is a perfect API of course, or even that a >>>> hypothetical stdlib-provided Path should mimic this. I’m just saying that >>>> for my use-case, this has vastly simplified how I deal with paths, because >>>> both URL and String smell really bad for what I’m doing. >>>> >>>> Dave >>>> >>>>> On Aug 22, 2017, at 12:37 PM, Taylor Swift <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> So are you saying we need three distinct “URI” types for local-absolute, >>>>> local-relative, and remote? That’s a lot of API surface to support. >>>>> >>>>> On Tue, Aug 22, 2017 at 12:24 PM, Dave DeLong <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> I completely agree. URL packs a lot of punch, but IMO it’s the wrong >>>>> abstraction for file system paths. >>>>> >>>>> I maintain an app that deals a lot with file system paths, and using URL >>>>> has always felt cumbersome, but String is the absolute wrong type to use. >>>>> Lately as I’ve been working on it, I’ve been experimenting with a >>>>> concrete “Path” type, similar to PathKit >>>>> (https://github.com/kylef/PathKit/ <https://github.com/kylef/PathKit/>). >>>>> Working in terms of AbsolutePath and RelativePath (what I’ve been calling >>>>> things) has been extremely refreshing, because it allows me to better >>>>> articulate the kind of data I’m dealing with. URL doesn’t handle >>>>> pure-relative paths very well, and it’s always a bit of a mystery how >>>>> resilient I need to be about checking .isFileURL or whatever. All the >>>>> extra properties (port, user, password, host) feel hugely unnecessary as >>>>> well. >>>>> >>>>> Dave >>>>> >>>>>> On Aug 20, 2017, at 11:23 PM, Félix Cloutier via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> I'm not convinced that URLs are the appropriate abstraction for a file >>>>>> system path. For the record, I'm not a fan of existing Foundation >>>>>> methods that create objects from an URL. There is a useful and >>>>>> fundamental difference between a local path and a remote path, and >>>>>> conflating the two has been a security pain point in many languages and >>>>>> frameworks that allow it. Examples include remote file inclusion in PHP >>>>>> and malicious doctypes in XML. Windows also had its share of issues with >>>>>> UNC paths. >>>>>> >>>>>> Even when loading an arbitrary URL looks innocuous, many de-anonymizing >>>>>> hacks work by causing a program to access an URL controlled by an >>>>>> attacker to make it disclose the user's IP address or some other ide >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
