Re: [swift-evolution] [Pitch] Collection Type Element Property Observers
John,
Sure, that is the pattern most commonly adopted for these cases but it does in
fact create a considerable amount of boilerplate code. My hope was to reduce
the amount of boilerplate and the burden to create such a common pattern of
functionality.
I do understand that the implementation would be complex. I am imagining that
these observers would get magically called when someone adds or removes the
collection. The wrinkle I think you’re referring to is the fact that there are
a variety of ways in which a collection can be 'added to' and 'removed from’.
Is that the complexity you are referring to?
Sean
> On Mar 30, 2017, at 2:58 PM, John McCall <rjmcc...@apple.com> wrote:
>
>> On Mar 30, 2017, at 2:37 PM, Sean Alling via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> PROPOSAL:
>>
>> I propose the addition of the following new property observers applicable to
>> all Collection types (Dictionary, Set, and Array):
>>
>> – willAdd(newValue) { … }
>> – didAdd(newValue) { … }
>>
>> – willRemove(oldValue) { … }
>> – didRemove(oldValue) { … }
>>
>> where, `newValue` and `oldValue` are immutable.
>>
>> This would allow one to perform additional work or observer logic to values
>> added and removed from collections. This model is consistent with Swift
>> syntax and may perhaps minimize the use of NSNotifications in some
>> situations.
>>
>> Currently, in order to perform this functionality some filtering and
>> comparison logic would have to be performed from within a `willSet { … }`
>> and `didSet { …}` call. This change would not only ease that burden but
>> promote a more visible and explicit expression that can further improve
>> readability and traceability of functionality.
>
> Figuring out that an arbitrary change to a collection is an "add" or a
> "remove" of a specific element is, well, let's just say it's complex. If
> you're imagining that these observers would just get magically called when
> someone called the add or remove method on the property, that's not really
> how these language features work together.
>
> The property behaviors proposal would let you do things like automatically
> computing differences and calling these observers, if you really want to do
> that. But the better solution is almost certainly to (1) make the collection
> property private(set) and (2) just declare addToList and removeFromList
> methods that do whatever you would want to do in the observer.
>
> John.
>
>>
>>
>> EXAMPLE USAGE:
>>
>> var list = [objects]() {
>> willAdd(newValue) {
>> …
>> }
>> didAdd(newValue) {
>> …
>> }
>> }
>>
>> var list = [key : object]() {
>> willRemove(oldValue) {
>> …
>> }
>> didRemove(oldValue) {
>> …
>> }
>> }
>>
>>
>> -
>> Sean Alling
>> alli...@icloud.com
>> <mailto:alli...@icloud.com>___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] [Pitch] Collection Type Element Property Observers
PROPOSAL:
I propose the addition of the following new property observers applicable to
all Collection types (Dictionary, Set, and Array):
– willAdd(newValue) { … }
– didAdd(newValue) { … }
– willRemove(oldValue) { … }
– didRemove(oldValue) { … }
where, `newValue` and `oldValue` are immutable.
This would allow one to perform additional work or observer logic to values
added and removed from collections. This model is consistent with Swift syntax
and may perhaps minimize the use of NSNotifications in some situations.
Currently, in order to perform this functionality some filtering and comparison
logic would have to be performed from within a `willSet { … }` and `didSet {
…}` call. This change would not only ease that burden but promote a more
visible and explicit expression that can further improve readability and
traceability of functionality.
EXAMPLE USAGE:
var list = [objects]() {
willAdd(newValue) {
…
}
didAdd(newValue) {
…
}
}
var list = [key : object]() {
willRemove(oldValue) {
…
}
didRemove(oldValue) {
…
}
}
-
Sean Alling
alli...@icloud.com ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Import Conditionals
Yeah I saw that thread. I think (a) this is a better solution and (b) this is applicable for use cases other than specifically Glibc/Darwin. -Sean Sent from my iPhone > On Oct 17, 2016, at 19:01, Saagar Jha <saa...@saagarjha.com> wrote: > > I believe there was a draft to merge all the "Libc" modules; let me see if I > can find that. > >> On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution >> <swift-evolution@swift.org> wrote: >> Description >> >> In an effort to both (1) reduce boilerplate code, and (2) promote >> cross-platform reusability I propose that we implement the following Import >> Conditional Operators: >> >> `||` and `&&` >> >> Currently, import conditionals must be implemented like so: >> >> ``` >> #if os(Linux) || os(FreeBSD) >> import Glibc >> #else >> import Darwin >> #endif >> ``` >> >> With import conditional operators this would be condensed to: >> >> ``` >> import Glibc || Darwin >> ``` >> >> The first library/framework (Glibc) would be imported if found and the the >> second (Darwin) only in the event the first should fail. >> >> Other Caveats: >> >> (A) — we could limit this to one conditional operator per import line OR we >> could implement order of operations. Obviously, there are tradeoffs of both >> that we should discuss. >> >> (B) — if-conditional statements currently explicitly show the import >> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to >> this new feature. I would argue that the reduction of boilerplate code would >> in itself be worth this abstraction. >> >> >> -- >> Sean Alling >> >> ___ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] Import Conditionals
Description In an effort to both (1) reduce boilerplate code, and (2) promote cross-platform reusability I propose that we implement the following Import Conditional Operators: `||` and `&&` Currently, import conditionals must be implemented like so: ``` #if os(Linux) || os(FreeBSD) import Glibc #else import Darwin #endif ``` With import conditional operators this would be condensed to: ``` import Glibc || Darwin ``` The first library/framework (Glibc) would be imported if found and the the second (Darwin) only in the event the first should fail. Other Caveats: (A) — we could limit this to one conditional operator per import line OR we could implement order of operations. Obviously, there are tradeoffs of both that we should discuss. (B) — if-conditional statements currently explicitly show the import conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to this new feature. I would argue that the reduction of boilerplate code would in itself be worth this abstraction. -- Sean Alling ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"
Hey guys and girls and everything in between, I was discussing this on Twitter. Perhaps the first step to easing this import system is to allow import conditional operators: && || would be the two of most use (mostly ||). We could perform the Darwin or Glibc import based on order of operations. Should the first import library fail than try the second, third, etc. elements until one has either been found or none. This avoids creating a whole pure swift library, although that may be a longer term goal to create a ecosystem of architecture independent libraries for pure swift use cross platform. Import statements for Darwin/Glibc would end up looking like this: ``` import Darwin || Glibc ``` I feel this would be well within line with Swift syntax. - Sean - Sean Alling Nuclear Engineer > > It looks like there are 2 views being discussed > > > > Import System : just masks the difference in platform specific names > > Import Libc : a true attempt at a swift specific view of credible c runtime > > equivalent > > > > The first one would be easy to do now and would alleviate all the mindless > > #if...#endif we have today. > > > > Regards > > LM > > (From mobile) > > > > > On Jul 6, 2016, at 1:13 AM, Chris Lattner via > > > swift-evolutionwrote: > > > > > > > > > > On Jul 5, 2016, at 2:59 PM, Brian Gesiak via > > > > swift-evolutionwrote: > > > > > > > > Sorry to resurrect such an old thread! I understand getting this in > > > > Swift 3.0 might not be realistic anymore, but this is still something > > > > I’d love to see added to Swift. Could someone advise on whether it > > > > still makes sense to spend time on this proposal? Or is this part of > > > > Swift too solidified to change at this point? > > > It is definitely beyond Swift 3.0, but I’d love to see this happen at > > > some point, we really need someone to drive the (surely to be > > > contentious) design process. > > > > > > -Chris > > > > > > > > > > How much would Libc include? The standard C library? POSIX? > > > > > > > > Yes, I had originally anticipated this as including module C and module > > > > POSIX. I see that module CUUID was recently added as well, but I don’t > > > > think that should be included. > > > > > > > > there are differences (minor, but still) between Glibc and Darwin. > > > > Those should be either unified (if possible) or re-arranged so that the > > > > unified library shares unified functionality and then each separate one > > > > can have its own set of caveats. > > > > > > > > I don’t think the unified import C module should do anything besides > > > > obviate the need to write the following: > > > > > > > > #if os(Linux) || os(FreeBSD) > > > > import Glibc > > > > #else > > > > import Darwin > > > > #endif > > > > If people feel strongly about unifying the overlay, perhaps we should > > > > discuss that in future swift-evolution proposals. > > > > > > > > Personally, I like “import C”, but at the end of the day I’m happy to > > > > call it whatever as long as it solves the problem. > > > > > > > > I couldn’t have said it better myself! > > > > > > > > /cc Saleem, since he may have Windows opinions. > > > > > > > > - Brian Gesiak > > > > > > > > > > > > > On Wed, Mar 9, 2016 at 6:35 AM, Honza Dvorsky > > > > gmail.com>wrote: > > > > > A huge +1 on the proposal, I even have a code snippet to import the > > > > > platform-appropriate C library. I try to write every new Swift > > > > > library cross-platform-by-default now and this would definitely > > > > > remove some friction. Not to mention it would future-proof many > > > > > libraries which won't need to be updated when a new Swift platform is > > > > > added. > > > > > > > > > > Personally, I like "import C", but at the end of the day I'm happy to > > > > > call it whatever as long as it solves the problem. I agree with Brian > > > > > that with Swift scaling up to 4 or so platforms soon-ish, it's > > > > > preferable to not put any extra burden on Swift users if there is an > > > > > almost-uniform C API which can be used everywhere. > > > > > > > > > > On Wed, Mar 9, 2016 at 2:03 AM Jordan Rose via > > > > > swift-evolutionwrote: > > > > > > One of the reasons we haven't picked this particular name is if the > > > > > > C or C++ committees ever adopted modules. Given that they just got > > > > > > punted from C++17, though, maybe that shouldn't hold us back. > > > > > > > > > > > > Jordan > > > > > > > > > > > > > > > > > > > On Mar 8, 2016, at 11:13, Brian Gesiak via > > > > > > > swift-evolutionwrote: > > > > > > > > > > > > > > # Introduction > > > > > > > > > > > > > > Currently, cross-platform Swift programs that rely on symbols > > > > > > > defined in libc (`fputs`, `stderr`, etc.) must all write the same > > > > > > > five lines of boilerplate code: > > > > > > > > > > > > > > #if os(Linux) || os(FreeBSD) > > > > > > > import Glibc > > > > > > > #else > > > > > > >
[swift-evolution] [Swift4] Mailing list vs. Forum
+1 I think this is a great idea! The use of a mailing list is manageable for a small (2-10) groups but doesn’t scale to the size and frequency of comments/replies that the Swift Open Source project has seen thus far. Not to mention, it reeks of 1996. I’m not sure if we should authenticate users via AppleID, because we want the Swift community to remain cross-platform going forward. A Slack would be a great idea, for banter but may get crazy. We would want the slack channels to remain subject pure (i.e., no shenanigans). Email is good in this regard in that a reply is expensive and therefore on-topic, whereas slack replies are cheap and therefore easily off topic. Anyone have any idea to combat that? Code of Conduct? I think in making this decision we should separate the determination that the mailing lists are posing too great a burden at our scale from the selection of what we should use in its stead. - Sean > I think this thread should focus on the mailing list vs forum, Slack is > not a forum. It could be nice to have it as an extra if we need it. > > It looks to me that all benefits of a mailing list can be achieved by a > forum system with excellent support to read and reply using emails. But > the opposite is not true, one single simple example: we can't even link > related thread using email (as Tino mentioned on the Gmane thread). > > > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
