Re: [swift-users] Coding style for internal/private variables

[Adrian Zubarev via swift-users]

A little bit off-topic: Is there any way to create autocompletion shortcuts in 
Xcode that will show only private, internal or both values of an instance?

class Foo {
private var integer: Int = 0
internal var string: String = "foo"
internal func boo() {}
}

let instance = Foo()

instance.@p  
 
|[V] Int integer |
||
 
// where @p is an autocompletion shortcut for Xcode that will filter private 
vars, functions etc.
// when you choose one `@p` will be replaced

// or @i for internal
instance.@i  
 __
|[M] Void   boo()  |
|[V] String string |
|__|
Something like this would be handy.



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 18:23:46, Tino Heth (2...@gmx.de) schrieb:

I never liked the underscores (so for me, they have been the best choice to 
mark stuff I should not know of in Cocoa ;-).  
For several years, I prefixed instance variables with "m", but stopped doing so 
after a talk about bad habits in writing Java code:  
It is like Hungarian notation, which also puts redundant information into names 
— and if even Java-folks think it's anachronistic… ;-)  

Objective-C lacked some features that Swift has, so workarounds had been 
created; but those shouldn't be carried over (by the way: It's similar with 
file names and those extensions, and a modern file system for OS X is years 
overdue ;-)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] UnsafeMutablePointer vs. UnsafeMutablePointer

[Austin Zheng via swift-users]

This shouldn't be something you need to worry about. The mechanism the OS uses 
to handle memory per process is different from the mechanism your process uses 
to allocate memory, and the OS should reclaim all the memory that your app used 
(whether it was 'leaked' or not).

More info: 
http://stackoverflow.com/questions/2975831/is-leaked-memory-freed-up-when-the-program-exits
 


Best,
Austin

> On Jun 1, 2016, at 9:13 AM, Adrian Zubarev via swift-users 
>  wrote:
> 
> I’ve got one more question that bothers me.
> 
> Lets say I’ve got a class that might look something like this:
> 
> class Reference {
>  
> var pointer: UnsafeMutablePointer
>  
> init(integer: Int) {
> self.pointer = UnsafeMutablePointer.alloc(1)
> self.pointer.initialize(integer)
> }
>  
> deinit {
> self.pointer.destroy(1)
> self.pointer.dealloc(1)
> }
> }
> Let talk about ARC here. If I use optionals here and release manually the 
> reference deinit will be called and we’re happy here:
> 
> var reference: Reference? = Reference(integer: 123456789)
> reference = nil
> If I don’t use optionals because I want my value to exist while the 
> application is running, deinit will never be called but my application 
> terminates just fine (SIGKILL?):
> 
> let reference = Reference(integer: 123456789)
> Doesn’t this create a memory leak?
> 
> How do I solve this problem, especially if don’t know whats inside the 
> Reference type (assume I’m a different developer who only has access to the 
> framework but not its implementation)?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 23. Mai 2016 um 18:31:43, Jordan Rose (jordan_r...@apple.com 
> ) schrieb:
> 
>> 
>>> On May 21, 2016, at 01:48, Adrian Zubarev via swift-users 
>>> > wrote:
>>> 
>>> I played around with UnsafeMutablePointer and realized one behavior:
>>> 
>>> let pString = UnsafeMutablePointer.alloc(1)
>>> pString.initialize("test")
>>> pString.predecessor().memory // will crash ax expected
>>> pString.predecessor() == pString.advancedBy(-1) // true
>>> pString.destroy()
>>> pString.dealloc(1)
>>> 
>>> where
>>> 
>>> let iInt = UnsafeMutablePointer.alloc(1)
>>> iInt.initialize("test")
>>> iInt.predecessor().memory // will not crash
>>> iInt.predecessor() == iInt.advancedBy(-1) // true
>>> iInt.predecessor().memory = 42 // did I just modified some memory I don't 
>>> own?
>>> iInt.destroy()
>>> iInt.dealloc(1)
>>> 
>>> Is this intended? This is really the case where its unsafe.
>>> 
>> 
>> Dmitri’s answers are all better for this specific discussion, but in 
>> general, “unsafe” in Swift means “if you don’t follow the rules, this may 
>> crash, may silently corrupt memory or do other bad things, may cause other 
>> code to be optimized out or miscompiled, may be harmless”. In this 
>> particular case, it’d be hard to check for the validity of the pointer while 
>> also being fast and binary-compatible with C.
>> 
>> Jordan
>> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Coding style for internal/private variables

[Tino Heth via swift-users]

I never liked the underscores (so for me, they have been the best choice to 
mark stuff I should not know of in Cocoa ;-).
For several years, I prefixed instance variables with "m", but stopped doing so 
after a talk about bad habits in writing Java code:
It is like Hungarian notation, which also puts redundant information into names 
— and if even Java-folks think it's anachronistic… ;-)

Objective-C lacked some features that Swift has, so workarounds had been 
created; but those shouldn't be carried over (by the way: It's similar with 
file names and those extensions, and a modern file system for OS X is years 
overdue ;-)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] UnsafeMutablePointer vs. UnsafeMutablePointer

[Adrian Zubarev via swift-users]

I’ve got one more question that bothers me.

Lets say I’ve got a class that might look something like this:

class Reference {
 
var pointer: UnsafeMutablePointer
 
init(integer: Int) {
self.pointer = UnsafeMutablePointer.alloc(1)
self.pointer.initialize(integer)
}
 
deinit {
self.pointer.destroy(1)
self.pointer.dealloc(1)
}
}
Let talk about ARC here. If I use optionals here and release manually the 
reference deinit will be called and we’re happy here:

var reference: Reference? = Reference(integer: 123456789)
reference = nil
If I don’t use optionals because I want my value to exist while the application 
is running, deinit will never be called but my application terminates just fine 
(SIGKILL?):

let reference = Reference(integer: 123456789)
Doesn’t this create a memory leak?

How do I solve this problem, especially if don’t know whats inside the 
Reference type (assume I’m a different developer who only has access to the 
framework but not its implementation)?



-- 
Adrian Zubarev
Sent with Airmail

Am 23. Mai 2016 um 18:31:43, Jordan Rose (jordan_r...@apple.com) schrieb:


On May 21, 2016, at 01:48, Adrian Zubarev via swift-users 
 wrote:

I played around with UnsafeMutablePointer and realized one behavior:

let pString = UnsafeMutablePointer.alloc(1)
pString.initialize("test")
pString.predecessor().memory // will crash ax expected
pString.predecessor() == pString.advancedBy(-1) // true
pString.destroy()
pString.dealloc(1)

where

let iInt = UnsafeMutablePointer.alloc(1)
iInt.initialize("test")
iInt.predecessor().memory // will not crash
iInt.predecessor() == iInt.advancedBy(-1) // true
iInt.predecessor().memory = 42 // did I just modified some memory I don't own?
iInt.destroy()
iInt.dealloc(1)

Is this intended? This is really the case where its unsafe.


Dmitri’s answers are all better for this specific discussion, but in general, 
“unsafe” in Swift means “if you don’t follow the rules, this may crash, may 
silently corrupt memory or do other bad things, may cause other code to be 
optimized out or miscompiled, may be harmless”. In this particular case, it’d 
be hard to check for the validity of the pointer while also being fast and 
binary-compatible with C.

Jordan

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Coding style for internal/private variables

[Adrian Zubarev via swift-users]

I’d like to talk about your personal coding styles in swift for its access 
control.

Remember these variable names like __magic or _spell or even garbage_?

Sure swift solves the synthesize problem but there might be old habits that let 
us write such code.

Here are some examples:

internal _name
internal i_name
private __name
private p_name

// not sure where `garbage_` would fit
I’d love to see your responses and opinions what and why the style you choose 
suits you.



-- 
Adrian Zubarev
Sent with Airmail
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Can't get Error pattern matching to work cross framework and command line tool

[Joe Groff via swift-users]

Thank you!

-Joe

> On May 31, 2016, at 9:49 PM, Joakim Hassila  wrote:
> 
> Hi Joe,
> 
> Absolutely, I just filed rdar://26569913 (used Radar according to community 
> guidelines of putting projects requiring Xcode to reproduce there).
> 
> I hope I captured the dependencies / reproduction steps properly in the 
> report, let me know if anything else is needed.
> 
> Cheers,
> 
> Joakim
> 
>> On 31 maj 2016, at 23:23, Joe Groff  wrote:
>> 
>> 
>>> On May 31, 2016, at 8:50 AM, Joakim Hassila via swift-users 
>>>  wrote:
>>> 
>>> Hi Ian,
>>> 
>>> Nope, it is the only definition - I also actually have tried to fully 
>>> qualify it as Z.Transaction.Error.NotFound without any difference both at 
>>> the throw and catch sides.
>>> 
>>> I do believe the compiler would have warned if the enum was ambigious 
>>> also...
>> 
>> Would you be able to file a bug with the project that displays this behavior?
>> 
>> -Joe
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users