Re: [swift-evolution] What about a VBA style with Statement?

2016-04-18 Thread Vladimir.S via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Brent Royal-Gordon via swift-evolution
>> 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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Brent Royal-Gordon via swift-evolution
>> * 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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Dany St-Amant via swift-evolution
> 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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Erica Sadun via swift-evolution
> 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.

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Erica Sadun via swift-evolution
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?

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Brent Royal-Gordon via swift-evolution
> 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() > } >

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Andrey Tarantsov via swift-evolution
>> 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. > >

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread L Mihalkovic via swift-evolution
> 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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Vladimir.S via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Erica Sadun via swift-evolution
> 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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Jonathan Tang via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread L. Mihalkovic via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Tino Heth via swift-evolution
> (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.

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Jonathan Tang via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Vladimir.S via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Milos Rankovic via swift-evolution
> 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() >

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-14 Thread Vladimir.S via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Michael Peternell via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Vladimir.S via swift-evolution
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.

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Erica Sadun via swift-evolution
> 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

[swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Benzi via swift-evolution
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 ___

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Kurt Werle via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Vladimir.S via swift-evolution
+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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Radosław Pietruszewski via swift-evolution
> 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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Vladimir.S via swift-evolution
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?

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Vladimir.S via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Taras Zakharko via swift-evolution
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 >

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread 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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Radosław Pietruszewski via swift-evolution
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

Re: [swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread Vladimir.S via swift-evolution
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

[swift-evolution] What about a VBA style with Statement?

2016-04-13 Thread 李海珍 via swift-evolution
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 =