James,
I think you misunderstood the proposal. The main goal is to allow protocols
define non-computed properties.
Functions inside protocol body will work different than functions in the
extension, more like functions in classes.
···
2016-02-27 19:27 GMT+03:00 James Campbell <james@supmenow.com>:
I think the easier solution is to allow for a default implementation to be
written for a protocol inside of the protocol itself.*___________________________________*
*James⎥Head of Trolls*
*james@supmenow.com <james@supmenow.com>⎥supmenow.com
<http://supmenow.com>**Sup*
*Runway East *
*10 Finsbury Square*
*London*
* EC2A 1AF *
On Sat, Feb 27, 2016 at 4:26 PM, Radosław Pietruszewski < > swift-evolution@swift.org> wrote:
Makes sense to me, and mixins are different enough conceptually from most
protocols that having a separate keyword (or, more practically, a modifier
keyword, like `mixin protocol`) might be desirable anyway.The fact that protocols already come in two flavors — those that can act
as types, and those that have associated types and therefore can only be
used as generic constraints — sometimes feels confusing to me. Adding a
third kind without any differentiation might not be a good idea.— Radek
On 27 Feb 2016, at 17:17, Trent Nadeau <tanadeau@gmail.com> wrote:
One limitation for "mixin" protocols would be that they can't be
retroactively modeled, e.g. by having an extension for that protocol on a
type outside of its file of definition. Allowing this would make the size
of structs and classes unknowable to the compiler as an extension in
another library could change the size of all instances.That limitation is restrictive enough that having a special type of
protocol and an associated keyword ("mixin") would probably be beneficial.
The compiler could then easily check the intent of the protocol and ensure
that a library doesn't break existing extensions just by adding a stored
property. Only mixin protocols would have this capability.On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski < >> swift-evolution@swift.org> wrote:
This is compelling to me.
I haven’t put enough thought into it to make up my mind about it, but a
mixin system would solve a problem I’m currently struggling with.I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m
trying to reduce duplication between the codebases. The problem is, there
are things that aren’t easy to completely encapsulate into a separate,
universal class — things that have bits and pieces in common, but different
overall shape.Perhaps I should encapsulate them anyway, add a level of indirection,
inject dependencies… But a mixin is an abstraction that would allow me to
extract common parts in an easier way.— Radek
On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution < >>> swift-evolution@swift.org> wrote:
Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHubP.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
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--
Trent Nadeau_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution