> On 18 Oct 2014, at 17:19, Luther Baker wrote:
>
> Coming from an iOS background, I'm used to seeing (and encapsulating) the
> creation of key Core Data components (persistent store, location,
> contexts). Everything is pretty explicit and consequently easy to follow.
>
> When I use Xcode to g
Coming from an iOS background, I'm used to seeing (and encapsulating) the
creation of key Core Data components (persistent store, location,
contexts). Everything is pretty explicit and consequently easy to follow.
When I use Xcode to generate a desktop Document based app for me, that
functionality
Hi again,
first, thanks a lot to all of those who took five minutes of their own time to
answer my "micro-poll". I really appreciate it.
So, to wrap up, that's mainly up to each person's taste. I think I'll stick to
the first solution I used since then.
Thanks again!
Vincent
_
On Mon, 30 Aug 2010 08:37:08 -0700, Joar Wingfors said:
>I think that it's definitively preferable to autorelease on the same
>line. It keeps all memory management together, and it's much less likely
>that later rearrangements of the code in question will result in memory
leaks.
And for those tha
On 30 Aug, 2010,at 11:33 AM, Dave DeLong wrote:
My personal preference is the latter example. My general rule of thumb is that
once I -release or -autorelease an object, I shouldn't interact with it
anymore, since I have relinquished ownership of said object.
Definitely true once you release,
On 30 aug 2010, at 08.29, Vincent Habchi wrote:
> baz = [[[Foo alloc] init] autorelease];
I think that it's definitively preferable to autorelease on the same line. It
keeps all memory management together, and it's much less likely that later
rearrangements of the code in question will result
On Aug 30, 2010, at 10:29 AM, Vincent Habchi wrote:
> just an enquiry regarding coding style. What is considered best:
>
> baz = [[[Foo alloc] init] autorelease];
> …
> return baz;
>
> or
>
> baz = [[Foo alloc] init];
> …
> return [baz autorelease];
>
> ?
As with most style questions, there's
On Aug 30, 2010, at 11:29 AM, Vincent Habchi wrote:
> Hi everybody,
>
> just an enquiry regarding coding style. What is considered best:
>
> baz = [[[Foo alloc] init] autorelease];
> …
> return baz;
>
> or
>
> baz = [[Foo alloc] init];
> …
> return [baz autorelease];
>
> ?
According to the
My personal preference is the latter example. My general rule of thumb is that
once I -release or -autorelease an object, I shouldn't interact with it
anymore, since I have relinquished ownership of said object.
The only time I don't follow that guideline is when I'm working inside a method
th
Prefer the first
[[[Foo alloc] init] autorelease];
If there is a @throw between the creation and return, there is a chance (if not
properly handled) that the autorelease won't be called.
On 30 Aug 2010, at 17:29, Vincent Habchi wrote:
> Hi everybody,
>
> just an enquiry regarding coding style
Hi everybody,
just an enquiry regarding coding style. What is considered best:
baz = [[[Foo alloc] init] autorelease];
…
return baz;
or
baz = [[Foo alloc] init];
…
return [baz autorelease];
?
Thanks!
Vincent___
Cocoa-dev mailing list (Cocoa-dev@lis
hi-
The default NSPopUpButton button style is Push.
But, I'm getting board of it and it looks old-style.
I think the button style of Round Textured is more "modern".
Now I see that Xcode 3.0 -> 3.1 changes the PUB button style to Round
Textured (I think)! Looks yummy!
Is "Round Textured" P
> Should be possible, no?
Emacs ;-)
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact
Am 04.07.2008 um 18:16 Uhr schrieb Gary L. Wade:
For example, this kind of code just bugs me when I'm balancing
braces back-and-forth:
Well, I find *this* one preferable:
#if WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
if (thisTestIsTrue && newFunctionalityIsAvailable) {
#else
if (thi
> Of course, if you're only talking about a few hundred
> lines,
Oh yes, at most. *NEVER* the size code base you're talking about!
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice
___
Cocoa-dev mailing list (Cocoa-dev
Scott Ribe wrote:
Anyways, it really is a personal preference. All arguments I've ever seen
that try to claim one style or the other is more correct or safer, are B.S.
(Including the one referenced--the bounds of a block were *ALWAYS*
absolutely vitally important, well before objects & destructor
> Actually, I couldn't agree more with the documentation!
Funny thing is, although I've used the style he advocates for a very long
time (15 years???), I don't agree with his reasoning.
Indentation of *code* should be consistent, an object comes into scope where
it's declared, not at an opening b
On Jun 27, 2008, at 10:25 PM, Jens Alfke wrote:
On 27 Jun '08, at 9:45 PM, Rob Ross wrote:
Btw, how many people realize this convention comes from the early
K&R C book, and the *only* reason they wrote it this way was to
minimize the number of lines of text their examples would take up
On Jun 28, 2008, at 1:25 AM, Jens Alfke wrote:
On 27 Jun '08, at 9:45 PM, Rob Ross wrote:
Btw, how many people realize this convention comes from the early
K&R C book, and the *only* reason they wrote it this way was to
minimize the number of lines of text their examples would take up
o
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
On
> Behalf Of Roni Music
> Sent: Saturday, June 28, 2008 1:13 PM
> To: cocoa-dev@lists.apple.com
> Subject: Re: Style Question (Robert Claeson)
>
> the bottom of the page below has o
On Sat, Jun 28, 2008 at 6:15 AM, Alex Wait <[EMAIL PROTECTED]> wrote:
> I was meaning to imply that if it was called "FirstName" would setFirstName
> still be called?
See the first word of Jens' reply. But more importantly, just as Jens
says, unask the question :)
Hamish
the bottom of the page below has one opinion why one style is superior to
the other,
(at least when it comes to C++ and the way C++ objects behave when going out
of scope)
http://www.relisoft.com/book/lang/scopes/2local.html
On 28 Jun 2008, at 06:30, Alex Wait wrote:
I have noticed, co
On Jun 28, 2008, at 6:39 AM, Sam Mo wrote:
On Jun 28, 2008, at 4:54 AM, Robert Claeson wrote:
On 28 Jun 2008, at 06:30, Alex Wait wrote:
I have noticed, coming from C++ and Visual Studio (at school), a
couple
style differences
if (value) {
//do something
}
insteasd of
if (value)
{
On Jun 28, 2008, at 4:54 AM, Robert Claeson wrote:
On 28 Jun 2008, at 06:30, Alex Wait wrote:
I have noticed, coming from C++ and Visual Studio (at school), a
couple
style differences
if (value) {
//do something
}
insteasd of
if (value)
{
//do something
}
Also since I am using this
On 28 Jun 2008, at 06:30, Alex Wait wrote:
I have noticed, coming from C++ and Visual Studio (at school), a
couple
style differences
if (value) {
//do something
}
insteasd of
if (value)
{
//do something
}
Also since I am using this style, XCode doesn't tab in for me when I
type {
On 27 Jun '08, at 9:45 PM, Rob Ross wrote:
Btw, how many people realize this convention comes from the early
K&R C book, and the *only* reason they wrote it this way was to
minimize the number of lines of text their examples would take up on
each page? It's a type-setting design decision,
I was meaning to imply that if it was called "FirstName" would setFirstName
still be called?
I know the convention for naming variables. :)
On Fri, Jun 27, 2008 at 10:13 PM, Jens Alfke <[EMAIL PROTECTED]> wrote:
>
> On 27 Jun '08, at 9:44 PM, Alex Wait wrote:
>
> if I have a member, let's say a
On 27 Jun '08, at 9:44 PM, Alex Wait wrote:
if I have a member, let's say a NSString, called FirstName...
would the setter still be setFirstName?
Yes. But you shouldn't name the property "FirstName". Property and
method (and instance variable) names should be lowercased. There are
some ex
On Fri, Jun 27, 2008 at 9:44 PM, Alex Wait <[EMAIL PROTECTED]> wrote:
> I got another Style related question.
/me points at ...
http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/index.html
-Shawn
___
Cocoa-dev mailing list (Co
I love this one. This becomes a religious issue for some people.
Both styles are popular, you should feel comfortable reading either
one. Write in the one you like best.
Btw, how many people realize this convention comes from the early K&R
C book, and the *only* reason they wrote it this wa
I got another Style related question.
if I have a member, let's say a NSString, called FirstName...
would the setter still be setFirstName?
I notice how it capitalizes the first letter even if the member doesn't
start with a capital letter.
if I have a "three word" named variable, let's say firs
On Fri, Jun 27, 2008 at 9:30 PM, Alex Wait <[EMAIL PROTECTED]> wrote:
> Also since I am using this style, XCode doesn't tab in for me when I type {
> then a return.
It will if you enable it (at least it always does for me).
Use whatever coding style you want however do try to follow Cocoa like
n
I have noticed, coming from C++ and Visual Studio (at school), a couple
style differences
if (value) {
//do something
}
insteasd of
if (value)
{
//do something
}
Also since I am using this style, XCode doesn't tab in for me when I type {
then a return. This is the style I "taught" and I
33 matches
Mail list logo
