Intentional? I guess it could be argued either way, but “magnify-to-fit” seems like one phrase.
I prefer the change; to me “magnify” is the operation, the rectangle
just happens to be what controls the result. It makes sense IMO that
there could be other magnify operations with different requirements.
Another case where `with` doesn’t add anything IMHO and in fact
makes things slightly confusing. The description isn’t somehow made
*with* the locale, it’s just a variant of the `description` property
that takes a locale as an setting.
I suppose in this case withLocale might be clearer as forLocale or
withinLocale or something along those lines?
Yes, "for" would be better than "with." Whether it's enough-better than
no label at all is unclear to me.
Similar case as “magnify to fit”. the scroll view has nothing to do with “toTop”. It should be:
I think in this case it’s less clear than magnify, as it’s a bit of a
weird pattern to begin with. It depends really on whether you feel
that scrollViewShouldScroll is a discrete event that could potentially
have different parameters (e.g- toBottom etc.) in which case it’s a
good distinction to have. Not nearly as clear to me as magnify though,
it’s not a style of callback that I like at all =)
Yeah, delegates are weird.
···
on Sat Feb 13 2016, Haravikk <swift-evolution-AT-haravikk.me> wrote:
On 13 Feb 2016, at 10:51, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:
Did you ever see this suggestion of mine in the delegate method thread? <http://article.gmane.org/gmane.comp.lang.swift.evolution/5777> It seems like you'd already concluded that there was no good solution and moved on to other topics, so I'm not sure if you did.
(If you *did* see it and dismissed it, sorry to bother you!)
I saw it. I don't think it's a foregone conclusion that there's no good
solution to delegate methods, but I do think the problem is a big hairy
one that deserves its own proposal. Having a whole separate set of
guidelines to cover delegates would be unfortunate so I hope the
eventual solution is something we can do entirely in the importer and
brings these APIs into line with the rest of the frameworks.
···
on Sat Feb 13 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:
Yeah, delegates are weird.
Did you ever see this suggestion of mine in the delegate method
thread?
<http://article.gmane.org/gmane.comp.lang.swift.evolution/5777> It
seems like you'd already concluded that there was no good solution and
moved on to other topics, so I'm not sure if you did.
I saw it. I don't think it's a foregone conclusion that there's no good
solution to delegate methods, but I do think the problem is a big hairy
one that deserves its own proposal. Having a whole separate set of
guidelines to cover delegates would be unfortunate so I hope the
eventual solution is something we can do entirely in the importer and
brings these APIs into line with the rest of the frameworks.
Okay, if the plan is to punt on delegates and think about them later, I think we can just decide not to fuss over them right now.
Intentional? I guess it could be argued either way, but “magnify-to-fit” seems like one phrase.
I prefer the change; to me “magnify” is the operation, the rectangle just happens to be what controls the result. It makes sense IMO that there could be other magnify operations with different requirements.
Another case where `with` doesn’t add anything IMHO and in fact makes things slightly confusing. The description isn’t somehow made *with* the locale, it’s just a variant of the `description` property that takes a locale as an setting.
I suppose in this case withLocale might be clearer as forLocale or withinLocale or something along those lines?
I’d be cool with just ‘locale’, but `forLocale` definitely works far better than `withLocale`.
Similar case as “magnify to fit”. the scroll view has nothing to do with “toTop”. It should be:
I think in this case it’s less clear than magnify, as it’s a bit of a weird pattern to begin with. It depends really on whether you feel that scrollViewShouldScroll is a discrete event that could potentially have different parameters (e.g- toBottom etc.) in which case it’s a good distinction to have. Not nearly as clear to me as magnify though, it’s not a style of callback that I like at all =)
Yeah I'm not a huge fan of the standard ObjC delegate style either, but I’m not debating that. But `toTop` as a argument label for the UIScrollView makes no sense.
···
On 13 Feb 2016, at 17:44, Haravikk <swift-evolution@haravikk.me> wrote:
On 13 Feb 2016, at 10:51, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:
Doug and I reviewed these, and we don't think they work. The right
criterion for cocoa seems to be “pull ‘of’ into the base name unless—as
Jordan suggested—it means “having.”
Fortunately that seems to be easily determined. After looking at all
the APIs in Cocoa, “of” in the base name means “having” exactly when it
is followed by one of the following words: “type,” “types,” “kind,”
“size,” “length,” and maybe “stage” (we're trying to analyze
removeModifiersOfStage
<SCNParticleSystem | Apple Developer Documentation
<SCNParticleSystem | Apple Developer Documentation;
to figure out how “of”is being used—assistance welcome).
As usual, I object to hardcoded supposedly-exhaustive lists. I'd
rather have people fix these up manually with NS_SWIFT_NAME and such.
We could “automatically fix them up manually” with NS_SWIFT_NAME and let
the framework owners review the patches, but since we know exactly which
ones work it would be a huge waste to ask each framework owner to find
them on their own.
Given that the parallel to -removeModifiersOfStage: is
-addModifierForProperties:atStage:withBlock:, I think the stage is not
being treated as part of the modifier.
I don't think I understand what you wrote above, sorry.
···
on Thu Feb 11 2016, Jordan Rose <swift-evolution@swift.org> wrote:
On Feb 11, 2016, at 16:00, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:
Doug and I reviewed these, and we don't think they work. The right
criterion for cocoa seems to be “pull ‘of’ into the base name unless—as
Jordan suggested—it means “having.”
Fortunately that seems to be easily determined. After looking at all
the APIs in Cocoa, “of” in the base name means “having” exactly when it
is followed by one of the following words: “type,” “types,” “kind,”
“size,” “length,” and maybe “stage” (we're trying to analyze
removeModifiersOfStage
<SCNParticleSystem | Apple Developer Documentation
<SCNParticleSystem | Apple Developer Documentation;
to figure out how “of”is being used—assistance welcome).
As usual, I object to hardcoded supposedly-exhaustive lists. I'd
rather have people fix these up manually with NS_SWIFT_NAME and such.
We could “automatically fix them up manually” with NS_SWIFT_NAME and let
the framework owners review the patches, but since we know exactly which
ones work it would be a huge waste to ask each framework owner to find
them on their own.
Yes, I'm fine with that. My point is I don't want it added to the automatic translation rules. (I expect to be overruled, again.)
Given that the parallel to -removeModifiersOfStage: is
-addModifierForProperties:atStage:withBlock:, I think the stage is not
being treated as part of the modifier.
I don't think I understand what you wrote above, sorry.
This is in reference to "we're trying to analyze -removeModifiersOfStage: to figure out how 'of' is being used—assistance welcome". My reading is that it is not an "of" that really means "having".
Jordan
···
On Feb 11, 2016, at 17:41, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Feb 11 2016, Jordan Rose <swift-evolution@swift.org> wrote:
On Feb 11, 2016, at 16:00, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org> wrote:
That's nice, then. It means 3 fewer NS_SWIFT_NAMEs or one fewer
automatic import rules (if you're overruled).
···
on Thu Feb 11 2016, Jordan Rose <swift-evolution@swift.org> wrote:
On Feb 11, 2016, at 17:41, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Feb 11 2016, Jordan Rose <swift-evolution@swift.org> wrote:
On Feb 11, 2016, at 16:00, Dave Abrahams via swift-evolution >>>> <swift-evolution@swift.org> wrote:
Doug and I reviewed these, and we don't think they work. The right
criterion for cocoa seems to be “pull ‘of’ into the base name unless—as
Jordan suggested—it means “having.”
Fortunately that seems to be easily determined. After looking at all
the APIs in Cocoa, “of” in the base name means “having” exactly when it
is followed by one of the following words: “type,” “types,” “kind,”
“size,” “length,” and maybe “stage” (we're trying to analyze
removeModifiersOfStage
<SCNParticleSystem | Apple Developer Documentation
<SCNParticleSystem | Apple Developer Documentation;
to figure out how “of”is being used—assistance welcome).
As usual, I object to hardcoded supposedly-exhaustive lists. I'd
rather have people fix these up manually with NS_SWIFT_NAME and such.
We could “automatically fix them up manually” with NS_SWIFT_NAME and let
the framework owners review the patches, but since we know exactly which
ones work it would be a huge waste to ask each framework owner to find
them on their own.
Yes, I'm fine with that. My point is I don't want it added to the
automatic translation rules. (I expect to be overruled, again.)
Given that the parallel to -removeModifiersOfStage: is
-addModifierForProperties:atStage:withBlock:, I think the stage is not
being treated as part of the modifier.
I don't think I understand what you wrote above, sorry.
This is in reference to "we're trying to analyze
-removeModifiersOfStage: to figure out how 'of' is being
used—assistance welcome". My reading is that it is not an "of" that
really means "having".