Agree. Such construction is also very useful. +1 to implement it.
From one side we know, that we should name variables with meaningful
names. From other side, the longer the name of variable - the more noise
you see in code and in some cases this noise,copy-paste,ide completion
suggestions
>> I really think this settles the discussion, because methods cascades are
>> *the* way to implement this kind of thing. (And for the record, I would
>> prefer a SmallTalk/Dart-like syntax to a "with" statement.)
>
> It's been quite a while since the original discussion and I'm going to go all
>> * The ability to name a closure parameter `self`, which would make bare
>> method calls be directed to that parameter.
>
> Could this would this tie into the weak-strong dance? And if so, how?
Actually, one of my motivations for wanting `self` parameters is the
block-based undo registration
> Le 14 avr. 2016 à 09:49, Vladimir.S via swift-evolution
> a écrit :
>
> Agree, that we can already use some hacks(IMO) to have some kind of what we
> need.
> Actually, we already discussed some variants : method "with" in extension to
> type and global generic
> On Apr 14, 2016, at 12:30 PM, Andrey Tarantsov wrote:
>
>>> I also like the idea of a dedicated method-cascading operator, like what
>>> Dart has. It eliminates the need for a programmer to explicitly remember
>>> to 'return self' at the end of a chainable method.
On Apr 14, 2016, at 2:55 PM, Brent Royal-Gordon via swift-evolution
wrote:
> * The ability to name a closure parameter `self`, which would make bare
> method calls be directed to that parameter.
Could this would this tie into the weak-strong dance? And if so, how?
> As a plus, it makes code easier to write, sometimes; or at least it seems so.
> On the other hand, I think it makes code harder to comprehend. A `with`
> statement introduces a new scope in which it is not obvious what exactly
> happens. For example:
>
> with(someObject) {
>foo()
> }
>
>> I also like the idea of a dedicated method-cascading operator, like what
>> Dart has. It eliminates the need for a programmer to explicitly remember to
>> 'return self' at the end of a chainable method. Not sure how well it'd
>> integrate with SE-0047 (@discardableResult) though.
>
>
> On Apr 14, 2016, at 7:39 PM, Vladimir.S via swift-evolution
> wrote:
>
>
> Can't agree with you.
>
> As you see from this topic, many of us use the "with" feature by
> using workarounds/hacks.
>
> Those, who don't use such "with" feature - can
> produce even
Can't agree with you.
As you see from this topic, many of us use the "with" feature by
using workarounds/hacks.
Those, who don't use such "with" feature - can
produce even more bugging code(copy-paste,wrong editor's code completion
suggestion).
So, I think this is "good" feature, not just
> On Apr 14, 2016, at 10:42 AM, Jonathan Tang via swift-evolution
> wrote:
>
> On Thu, Apr 14, 2016 at 8:23 AM, Tino Heth via swift-evolution
> > wrote:
>
> > (in Smalltalk, like in Swift?, if i remember
On Thu, Apr 14, 2016 at 8:23 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:
>
> > (in Smalltalk, like in Swift?, if i remember correctly, ‘self’ is
> implicitly
> > returned in absence of a return value and can be ignored.
> I'm a big fan of returning self — its much more
For what it's worth, I left vba behind a long time ago and I have some bad
memories of what I saw in these with blocks: people writing a page worth of
code where only a couple line were actually referencing .x. In the end,
they thought it made their code look cool when I just saw it as a
> (in Smalltalk, like in Swift?, if i remember correctly, ‘self’ is implicitly
> returned in absence of a return value and can be ignored.
I'm a big fan of returning self — its much more useful than void…
But it seems the Swift-community doesn't like method chaining.
Very strong -1 to implicit 'with'. Javascript tried this and it was a
disaster, and eventually banned in strict mode. It tends to make
compilation and optimization of a variable within a 'with' block
impossible, as it could refer to the fields of any object, or even a method
call behind protocol
Agree, that we can already use some hacks(IMO) to have some kind of what we
need.
Actually, we already discussed some variants : method "with" in extension
to type and global generic function "with". Each of them has disadvantages
in compare to "with" language construction. In your example you
> On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution
> wrote:
>
> The biggest advantage of the with pattern IMO is Cocoa initializers. It
> provides a more unified
> initialization scope. Instead of:
>
> let questionLabel = UILabel()
>
Yes, I agree, that "implicit" "with", where we can't say if method belongs
to the target instance or not, is very bad idea. I strongly agains it.
But the proposal is for "explicit" "with", where it is clear what
method/property belongs to target instance, and which don't. So most of
your
I think the idea is good, but I think it would be bad for the language overall.
-1
As a plus, it makes code easier to write, sometimes; or at least it seems so.
On the other hand, I think it makes code harder to comprehend. A `with`
statement introduces a new scope in which it is not obvious
But in case of struct instance constant - we have a problem:
struct A {
var x = 1
var y = 2
}
let a1 = A()
with (a1) {
print($0.x)
$0.y = 10
}
- this will be compiled without errors/warnings, but yes - there will be
runtime error. I'm sure this is not what we need from Swift.
> On Apr 13, 2016, at 9:34 AM, Kurt Werle via swift-evolution
> wrote:
>
> I've always thought that the with construct is not a good idea. It seems to
> me that the moment you want to use with it indicates that you are getting too
> much into some other classes
The closest right now you can achieve would be:
func with(item:T, apply:(T)->Void) {
apply(item)
}
let label = UILabel()
label.highlighted // defaults to false
with(label) {
$0.highlighted = true
}
label.highlighted // is now true
___
I've always thought that the with construct is not a good idea. It seems
to me that the moment you want to use with it indicates that you are
getting too much into some other classes business; shouldn't that class
deal with this? Why are you exposing/integrating so much of some other
class's
+1 on statement vs lexical scope. additionally { $0.something ... } is more
explicit than just .something.
On 13.04.2016 17:36, Taras Zakharko via swift-evolution wrote:
We had this kind of proposal earlier, didn’t seem to be very well received. I
still think it would be a useful thing, but
> On 13 Apr 2016, at 16:47, Vladimir.S wrote:
>
> Than you for sharing this method. So, do you suggest to not have this "with"
> construction in Swift just because we *can* implement the same behavior by
> using some workarounds/hacks?
>
> I.e. do you support this proposal
Yes, it really looks like language construction, and I like this approach.
with (some) {
$0... = ...
}
But should many of us copy-paste these functions in each module/project or
this is very handful feature that we want to have in our language? What do
you think about the proposal?
Than you for sharing this method. So, do you suggest to not have this
"with" construction in Swift just because we *can* implement the same
behavior by using some workarounds/hacks?
I.e. do you support this proposal or don't?
Do you agree that such built-in feature will be very useful and make
We had this kind of proposal earlier, didn’t seem to be very well received. I
still think it would be a useful thing, but I’d do it as a statement (extension
of do) that introduces new lexical scope (similar to self)
— Taras
> On 13 Apr 2016, at 16:25, Sean Heber via swift-evolution
>
This pair works pretty well, too, if you don’t mind free functions:
func with(inout this: T, @noescape using: inout T->Void) { using() }
func with(this: T, @noescape using: T->Void) { using(this) }
It works either with classes or mutable structs if you call it correctly and
the type doesn’t
It can be (more-or-less) solved in library code today:
extension NSObjectProtocol {
public func with(@noescape fn: Self -> Void) -> Self {
fn(self)
return self
}
}
This way, you can do, on NSObjects:
textLabel.with {
$0.textAlignment = .Left
$0.textColor
I like this idea.
In Delphi(Pascal) there is also such construction
with someVar do
begin
end;
And it is very handy and is used a lot (usually if you need to set/read a
lot of properties of some object).
Additionally, I believe such construction prevents some possible mistakes
with used
I recently learned some VBA and I found a very conveniently `with`
statement.
`with` statement can be helpful to set property for UIKit instance.
for instance a UILabel instance `textLabel` ,with `with` statement we can
set UILabel property like this
```swift
with textLabel{
.textAlignment =
32 matches
Mail list logo