[swift-evolution] [Review] SE-0026 Abstract classes and methods

[Wallacy]

This should be resolved when PwS
<http://article.gmane.org/gmane.comp.lang.swift.evolution/3082>(Protocol
with Storage) get alive:

  // Framework land
        public protocol DatabaseRecord {
                var persistedRow: DatabaseRow { get }
                static func databaseTableName() -> String
                init(row: DatabaseRow)
        }
      internal extension DatabaseRecord {
*                var referenceRow: DatabaseRow*
                // or other storage. Syntax and place of declarations is
not defined.
       }
       public  extension DatabaseRecord {
                var hasChanges: Bool {
                        // return complex computation based on referenceRow
and persistedRow
                }
        }


This is another proposal, but the idea is improve the current protocol
model instead to create another type just because a single skill.

Em sex, 4 de mar de 2016 às 16:28, Gwendal Roué <swift-evolution at swift.org>
escreveu:

>
> > Le 4 mars 2016 à 20:24, Gwendal Roué <gwendal.roue at gmail.com> a écrit :
> >
> >
> >> Le 4 mars 2016 à 08:45, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> a écrit :
> >>
> >>> For modeling subtype requirements we would need the ability to declare
> protocol members with reduced access scope like private or internal and
> hopefully protected, as subtype requirements most often are not public.
> >>
> >> I've spoken about this elsewhere, but:
> >>
> >> - For both abstract classes and protocols, all required/abstract
> members need to be visible everywhere you're permitted to conform/inherit.
> >> - There is currently no way in Swift to decouple a protocol's/class's
> visibility from the ability to conform to/inherit from it, so neither
> construct can currently offer this feature.
> >> - However, this feature is likely to come at least for classes as part
> of resiliency. I think it's a good idea for protocols, too.
> >
> > Brent, please consider the sample code below:
>
> I just wanted to put focus on the visibility issues, which you could not
> see (it seems). Your general arguments about ways to improve protocols so
> that not only classes could be enhanced remain quite valid and inspiring.
>
> Gwendal
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160304/a09d25ce/attachment.html>