> Actually, heck, you wouldn't even need that. All a virus would have to
> do would be to move the binary somewhere else and put a binary in its
> place that does something malicious and then launches the real binary,
> and the user would never tell the difference.
>
> Unless, of course, the app c
> Not necessarily true. While you are free to specify a delegate as
> NSObject , it is not standard convention. The convention
> for delegates is: id.
As I recall, sending variables of type id useful messages like
retain and release generate a compiler warning, whereas NSObject
are fine.
I cou
> > I could be wrong on this, but I definitely recall thinking it was a
> stupid compiler behavior.
>
> This is because you didn't declare your protocol as extending the
> NSObject protocol. If you do something like this:
>
> @protocol MyProtocol
>
> Then you can call all the NSObject stuff with
> aAbBcCdDeEfF .. etc with everything outside the letter space sorting
> 'naturally' and coming after the letters (I actually don't care too much about
> the last bit honestly they can go where they like as long as it's outside the
> alphabet range).
>
> so
>
> myClass comes before
> In most cases, yes. However, copyWithZone: is special, the superclass'
> implementation just blindly copies all of the raw bits in the source
> object to the newly created one. If you were to use the normal
> -setImage: call, that old value would be released one too many times.
> Assigning to the
> > Why would you not just do:
> >
> >[cell->image retain];
> >
> > That makes it a lot clearer to me - since it was a bitwise copy,
> > cell->image and image are identical values whereas the assignment
> > looks like you are changing something.
>
> Because it may *not* have been a bitwise cop
> > I think dictionaryWithCapacity should both alloc and init it, right?
>
> Yes, and it autoreleases it too. :-o That means it'll conveniently be
> released later on, which is exactly what you're running into. If you
> want to keep a reference to the dictionary, you should call alloc and
> init y
> >> Yes, and it autoreleases it too. :-o That means it'll conveniently be
> >> released later on, which is exactly what you're running into. If you
> >> want to keep a reference to the dictionary, you should call alloc and
> >> init yourself.
I wrote:
> > No, you should just *retain* the result o
> > Part of your response suggests that if there was an existing
> framework that was openly available, it wouldn't do me any good because
> the bad guys would have the source code.
>
> I disagree. If it's based on a tried and tested (and occasionally
> formally verified) crypto system, knowing th
> I haven't tried it, so this might be nonsense, but I think that YACC
> simply copies the emitted code from the source file to the final C
> file.
Yacc has to parse the emitted code enough to be able to replace references to
$$, $1, etc with the corresponding tokens from the recognized grammar e
> For example, is:
>
> NSMutableArray *anArray = [[NSMutableArray array] retain];
>
> better than:
>
> NSMutableArray *anArray = [[NSMutableArray alloc] init];
I've been reamed, in the recent past, for expressing the opinion that the first
was just as good as the second - apparently the answer
Ok, I'll bite.
How does the mail server that Mail.app is talking to distinguish between
Mail.app and /usr/sbin/sendmail ? They both presumably just talk SMTP ?
If the scriptable solution works, then roll-your-own-smtp should also work,
provided you go the hard yards and implement everything it
cker.com/software/email-apps/how-to-use-gmail-as-your-smtp-server-66.php
-Original Message-
From: Andrew Farmer [mailto:andf...@gmail.com]
Sent: Wednesday, 24 June 2009 3:27 PM
To: Jeff Laing
Cc: Nick Zitzmann; cocoa-dev@lists.apple.com
Subject: Re: Cocoa and email (SMTP/POP3)
On 23 Ju
> I think it depends what language you weaned yourself on. If you've used Lisp
> or some other
> functional language, manual reclamation is an unthinkable monstrosity. If you
> weaned yourself
> on C or similar languages, manual reclamation seems like the default state of
> play.
Its also going
> Well, no, that's not a good summary of the last couple paragraphs. IF
> YOU HAVE A FINALIZER, then you should probably be using the
Unless you peer into the implementation details of your superclasses, you
should assume that all classes may have a finalizer. Unless you don't care
about every l
> 1. If your objects use (scarce) resources that are not themselves
> subject to GC (file handles, network connections, whatever), you'd be
[snip]
> 2. If you expect objects to be returned to the free memory pool "the
> instant that those objects aren't required" then GC isn't going to
> satisfy yo
> Because you have no idea what subclassers may do in their overrides of
> the accessors
Sort of invalidates the whole encapsulation promise of OO design, doesn't it?
> (e.g. The subclassed accessor may rely on state that's
> been torn down earlier in -dealloc).
But any subclass that's going to
> No, it doesn't. It would in fact violate the encapsulation principle
> if your -dealloc method required your accessors to not rely on certain
> state.
The "ability to override accessors violates encapsulation" because it adds
additional restrictions to the accessor that the superclass is not a
> According to Cocoa/ObjC memory-management, if you get an object
> (reference) via "alloc","new",any object that contains "copy", and
> any object you send [ retain] to, is yours - it becomes your
> responsibility to call [ release] on it when you're
> done. Ditto for properties like
>
> @propert
> Unfortunately, this contract isn't always followed. Lots of people
> "optimise" away this policy instead of doing a "superfluous" 'return
> [[foo retain] autorelease]'.
On initial read, I didn't quite follow this. If my method is returning a foo
that I know I have "retained", what requirement
obj foo];
b) indirectly.NSObject *val = [[[someobj foo] retain] autorelease];
return val;
Technically those are the only ways you are allowed to retrieve the value then
return it and in both cases there is zero change in 'retain count' and the
object remains aliv
> OK, so this discussion is getting a little crazy :-)
Agreed.
> The -hash method is important for objects that are used as keys in
> associative collections.
> [snip]
> So, in practice, it's perfectly safe in 99.9% of cases to base your
> hash off your object's properties. In the specific case
> Core Data doesn't use random objects as keys in dictionaries or sets
> for this reason. It's not that we don't trust you, but ... to
> prevent misunderstandings, all NSManagedObject subclasses are
> forbidden from overriding -hash and -isEqual.
I have to admit, I didn't know this bit but I see
> Separately, collections may (and presumably sometimes do) use *object*
> hash values to distribute objects in memory. (Obviously, NSSet does,
> and for all we know NSDictionary does too, to distribute object values
> that stored under the same key hash value -- though it would be an
> implementat
> > If that's not possible, how can I define a function that can reach the
> objects of my application? The ViewController is stored in the
> ApplicationDeletegate, but I can't find any reference to that object.
Ummm, is this really hard?
id MyAppDelegate = [[UIApplication sharedApplication] dele
> Of course it is. Suppose for a minute that [myMutableDictionary allValues]
> returned a mutable array. That means that you could add to and remove from
> this array with impunity.
>
> Except... the objects in this array are supposed to have an associated key.
Um, no they aren't. Arrays don't
> > How many times will the user display the about panel in an average
session
> > of working with your app?
> >
> > Most likely, the answer is once.
At the risk of being provocative, I'd say the answer is closer to zero.
As such, it's a premature optimisation to worry about it, and we all
know A
That's because you aren't making the point hard enough.
Make the seekForward: method look at the bottom "two digits" in the ID
of the button. That lets the interface designer has a 1x 2x 4x 8x 16x
seek buttons it he wants to, or just 1x
- (IBAction)seekForward:(id)sender
{
[self seekBy:1
> If you declare a property:
>
> @property (nonatomic, assign) MyLabel *label1;
>
> but make the connection in IB to mLabel1, then the property accessor
> isn't used. So the outlet is set using setValue:forKey:. Which
> results in the value being retained, precisely as described in the
> docume
> But if your dealloc is like this...
>
> - (void)dealloc
> {
> self.thisProp = nil;
> self.thatProp = nil;
> ...
> }
>
> then you'll be calling the accessors and the right thing will happen
> (i.e. release if necessary). This is what I currently do for all dev
> work (iPhone or M
cessors* for the
property' which it does do completely. And it does seem like having one
more hack, perhaps
- (void)dealloc
{
@release xxx;
[super dealloc];
}
would make me feel like the feature (properties) was actually complete.
Jeff Laing <[EMAIL PROTECTED]>
---
> There's no difference between setting through a property, and setting
> through a plain old setter method. That said, it's up to you to decide
> if you want to go with the official recommendation or not. If you
> think that you have enough control over the implementation of your
> accessor method
> From: Roland King [mailto:[EMAIL PROTECTED]
> I think if you're talking about your own instance variables which you
> are declaring and synthesizing, you have enough information to decide
> if it's safe to call your property accessors in dealloc or not.
Well, that's sort of my point, really. I d
Mark D. Gerl asked:
> There's something that's just "uncomfortable" about dereferencing
> pointers without first checking for validity. Is it just me?
I don't think its just you, though most Cocoa types eventually give up
and go with the simpler 'just trust it, it works' approach. Personally,
> So what? Implement the appropriate methods in your NSApp delegate, or
> perhaps a custom subclass of NSDocumentController, and have them stow
> any arguments and keep reminding themselves using
> -performSelector:withObject:afterDelay: until conditions change such
> that the original message can
> I have seen a couple of fairly nice solutions, and lots of really
> awful ones. Generally speaking, the awful ones try to go to great
> lengths to be sneaky and hide files or other data in places in your
> computer they shouldn't be messing with.
Its worth pointing out that most hacker-ty
>> Is there a way to read one line of a text file at a time
>> using NSFileHandle (the way fgets does)?
>
> This code illustrates how you might approach
> filtering lines of data obtained through an NSFileHandle.
I've come across this problem as well - its fine to say "read it all
into memory,
gured I might as well ask.
Failing Cocoa, is that info available via some sort of sysctl() or
ioctl() interface ?
Thanks in advance,
Jeff Laing
--
Remember kids, there are no stupid questions, just stupid p
st locals vs an enum in an
enclosing scope.
Apple might think about using better (ie, prefixed) names for all their
enums if they are going to clash like this, otherwise the set of
available variable names is going to evaporate over time...
Jeff Laing
39 matches
Mail list logo
