I was trying to make a simple 2D array of this struct:
struct Color {
var r : Float = 0
var g : Float = 0
var b : Float = 0
}
As I was reading up on arrays in Swift, I came across this example
initialization:
var threeDoubles = [Double](count: 3, repeatedValue: 0.0)
And there was
On Dec 11, 2014, at 3:24 PM, Daniel Blakemore dblakem...@pixio.com wrote:
If I do this, however, it breaks:
var arr2 = [Array](count:6, repeatedValue:[Color](count:8, repeatedValue:
Color()))
[Array] is syntactic sugar for ArrayArray. It is not a complete type.
It is an array of arrays of
Sweet! That does totally work.
Why did it compile if it's an incomplete type? Shouldn't that be something
that you catch at compile time in a type-safe language?
I'm always hesitant about type inference in Swift because you have a 50-50
chance of the compiler not understanding at all and
Why did it compile if it's an incomplete type? Shouldn't that be something
that you catch at compile time in a type-safe language?
Don't know. It failed on my machine. I copied/pasted your code to a
playground and got a red exclamation point due to a fault. Then I looked
closer at the
It's not that I don't trust that it works, I don't trust that what I try
will work. It's like in those long hours of debugging some
non-deterministic, impossible-to-find error where you start to doubt things
like the order of operations so you add more parens just to be sure.
And I indicated it
Duhh! I have created dictionaries already—there’s a sample one for
testing in my app already—but the syntax of that prototype went right over my
head. I’m accustomed to JSON and Python’s use of braces to declare
dictionaries, and I was so fully convinced the variable was an array that I
Now on to the next thing that doesn’t seem to work according to the
documentation…
These are the first few lines of my function which will save my document data:
override func fileWrapperOfType(
typeName: String!,
error outError: NSErrorPointer
) - NSFileWrapper!
{
if
On 15 Sep 2014, at 10:47 am, Charles Jenkins cejw...@gmail.com wrote:
Now on to the next thing that doesn’t seem to work according to the
documentation…
These are the first few lines of my function which will save my document data:
override func fileWrapperOfType(
typeName:
On Sep 14, 2014, at 19:47 , Charles Jenkins cejw...@gmail.com wrote:
let noWrappers: [AnyObject] = []
self.theFileWrapper = NSFileWrapper( directoryWithFileWrappers:
noWrappers )
When I start typing “directoryWithFileWrappers,” Xcode displays its
suggestion list showing the
On Mac OS X 10.5.8, Xcode 3.1.3,
I ran into some very strange behavior today trying to get at the
extended attributes of files. In summary, for particular NSDictionary
object, the behavior of -objectForKey: is different, depending on what
other code runs.
I have distilled the weirdness
NSDictionary* attrs = [[NSFileManager defaultManager]
attributesOfItemAtPath:
@/some/file/with/finder/comment
error:NULL];
NSLog(@extAttrs:%@, [attrs objectForKey:@NSFileExtendedAttributes]);
NSLog(@attrs:%@, attrs);
On Jul 13, 2010, at 2:44 PM, Murat Konar wrote:
NSLog(@extAttrs:%@, [attrs objectForKey:@NSFileExtendedAttributes]);
NSLog(@attrs:%@, attrs);
NSLog(@extAttrs:%@, [attrs objectForKey:@NSFileExtendedAttributes]);
2010-07-13 13:14:30.648 FileManagerBug[9323:813] extAttrs:(null)
On Tue, Jul 13, 2010 at 3:44 PM, Murat Konar mu...@pixar.com wrote:
WTF?
For those interested, you can download my test project from
http://bugs.muratnkonar.com/FileManagerBug.zip
If you NSLog(@class = %@, [attrs class]) you'll see what the problem
is! The NSFileManager function doesn't
Wow. That possibility seemed too outlandish to consider, but there it
is.
Curious though that asking the dictionary poser object to describe
itself triggers the fetch (as does asking for all its keys, BTW), but
actually asking for a value in the object doesn't.
Thanks everybody. And be
On Wed, Oct 15, 2008 at 6:50 AM, Jonathan del Strother
[EMAIL PROTECTED] wrote:
Presumably you could override +(id)alloc to be +(MyClass)alloc on
classes that you knew implemented ambiguous init methods?
You could, but then every subclass of your class which defines its own
init methods is then
On Wed, Oct 15, 2008 at 9:03 PM, John Engelhart
[EMAIL PROTECTED] wrote:
On Oct 14, 2008, at 7:11 AM, Chris Suter wrote:
You can't override the type for existing methods. For example,
initWithString: always returns an id. You can define them as returning
something different but the compiler
On Wed, Oct 15, 2008 at 11:36 AM, Chris Suter [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2008 at 9:03 PM, John Engelhart
[EMAIL PROTECTED] wrote:
On Oct 14, 2008, at 7:11 AM, Chris Suter wrote:
You can't override the type for existing methods. For example,
initWithString: always returns an
On Oct 14, 2008, at 7:11 AM, Chris Suter wrote:
You can't override the type for existing methods. For example,
initWithString: always returns an id. You can define them as returning
something different but the compiler will ignore it.
Just a clarification on this particular point- it is
In my project I have two different, totally unrelated classes.
@interface ClassA : NSObject{}
-(id)initWithContext:(ContextA*)context;
@end
@interface ClassB : NSObject{}
-(id)initWithContext:(ContextB*)context;
@end
The problem is that when I call
ContextA* context = ...;
[[ClassA alloc]
On Tue, Oct 14, 2008 at 9:13 PM, Graham Cox [EMAIL PROTECTED] wrote:
Isn't the problem here with the init method, rather than alloc?
It's a problem with both.
NSString et. al. return id because they are class clusters (and because it's
the
established convention),
I believe the fact that
You are right, casting from alloc worked, thank you.
Is it the recommended practice to always cast after alloc?
I still have a question in this regard.
If the alloc returns id, then, from the compiler's perspective, there
can be two solutions: 1) assume that the id type can have each and any
On Oct 14, 2008, at 02:17, Oleg Krupnov wrote:
If the alloc returns id, then, from the compiler's perspective, there
can be two solutions: 1) assume that the id type can have each and any
method and let it be resolved at run time without any compiler warning
or 2) assume that the id does not
On Tue, Oct 14, 2008 at 8:17 PM, Oleg Krupnov [EMAIL PROTECTED] wrote:
You are right, casting from alloc worked, thank you.
Is it the recommended practice to always cast after alloc?
I still have a question in this regard.
If the alloc returns id, then, from the compiler's perspective,
Oleg Krupnov wrote:
You are right, casting from alloc worked, thank you.
Is it the recommended practice to always cast after alloc?
Not really - the recommended practice is to have method names which have
unique parameter types. Remember that Objective-C's notion of a selector
is
On 14 Oct 2008, at 8:17 pm, Oleg Krupnov wrote:
You are right, casting from alloc worked, thank you.
Is it the recommended practice to always cast after alloc?
No, I never do it. I never see code that routinely does it either.
I still have a question in this regard.
If the alloc returns
On 14 Oct 2008, at 8:58 pm, Chris Suter wrote:
The proper way to solve this, in my opinion, is to allow a way of
specifying that the return type varies depending on the class it's
implemented on i.e. define the alloc method in such a way so that the
compiler knows that -[class alloc] returns
On Tue, Oct 14, 2008 at 7:43 PM, Oleg Krupnov [EMAIL PROTECTED] wrote:
In my project I have two different, totally unrelated classes.
@interface ClassA : NSObject{}
-(id)initWithContext:(ContextA*)context;
@end
@interface ClassB : NSObject{}
-(id)initWithContext:(ContextB*)context;
On 14 Oct 2008, at 10:11 pm, Chris Suter wrote:
I believe the fact that they are class clusters is irrelevant; it's an
implementation detail. The objects returned still conform to the
interfaces defined by NSString and NSMutableString. They return id,
rather than NSString say, because
Chris Suter wrote:
The proper way to solve this, in my opinion, is to allow a way of
specifying that the return type varies depending on the class it's
implemented on i.e. define the alloc method in such a way so that
the compiler knows that -[class alloc] returns an object of type
class.
29 matches
Mail list logo
