On Thu, 24 Apr 2014 14:45:58 -0700, Quincey Morris said:
I still don't see how
foo = [@Something fallbackIfNil:foo];
has any advantage over
foo = foo ?: @Something;
I don’t see how the latter has any advantage over your earlier
suggestion [more or less]:
if (!foo)
On Apr 25, 2014, at 10:22 AM, Sean McBride s...@rogue-research.com wrote:
The 'if form' is arguably better for testing too. Many code coverage tools
are line-based, and with this form it's easier to see if your test cases
cover going in the branch and not.
Sure, and similarly for plain old
On Apr 25, 2014, at 10:38 AM, Andy Lee wrote:
On Apr 25, 2014, at 10:22 AM, Sean McBride s...@rogue-research.com wrote:
The 'if form' is arguably better for testing too. Many code coverage tools
are line-based, and with this form it's easier to see if your test cases
cover going in the
I was just asked yesterday if there is any shorthand in Objective-C for if
this thing = nil, then instantiate a new instance from the class
Something like this:
NSString x;
if ([x isEqualtoString:nil]) {
x = @yo;
}
Feel free to replace NSString with any class.
And we messed around a bit
Usually, I would access such variables as properties that are lazy loaded, in
which case the accessing code is simply:
self.x …
and the accessor is
- (NSString *) x {
if (!_x) {
_x = @“yo”;
}
return _x;
I guess my real question is can we substitute the ternary operator for your if
statement and if not, why?
Thanks man.
On Apr 24, 2014, at 10:53 AM, Raheel Ahmad wrote:
Usually, I would access such variables as properties that are lazy loaded, in
which case the accessing code is simply:
Not native and I've no idea when or if this is a good idea ... nor am I sure
how much typing you want to do ... but you _could_ create a class convenience
method for this
x = [Thing defaultIfNil:x];
With shorter or longer names as you see fit ... down to possibly:
x = [Thing :x]
I've
On Apr 24, 2014, at 11:12 AM, Luther Baker wrote:
Not native and I've no idea when or if this is a good idea ... nor am I sure
how much typing you want to do ... but you _could_ create a class convenience
method for this
x = [Thing defaultIfNil:x];
With shorter or longer names as
well not if it's actually
x = (x) ?: @yo;
but
x = (x) ? x : @yo ;
seems to be fine.
nil is defined to be 0, 0x0, any other kind of zero you like.
I don't like bools not being bools so I'd personally do
x = (!x) ? @yo : x;
or
x = (!!x) ? x : @yo
On Apr 24, 2014, at 10:33 AM, Alex Zavatone z...@mac.com wrote:
I was just asked yesterday if there is any shorthand in Objective-C for if
this thing = nil, then instantiate a new instance from the class
Something like this:
NSString x;
if ([x isEqualtoString:nil]) {
x = @yo;
}
On Apr 24, 2014, at 11:14 AM, Alex Zavatone z...@mac.com wrote:
On Apr 24, 2014, at 11:12 AM, Luther Baker wrote:
Not native and I've no idea when or if this is a good idea ... nor am I sure
how much typing you want to do ... but you _could_ create a class
convenience method for this
On Apr 24, 2014, at 9:21 AM, Roland King r...@rols.org wrote:
well not if it's actually
x = (x) ?: @yo;
Actually, that will work just fine. Personally, I'd leave off the extraneous ():
x = x ?: @yo;
While we're on the subject of obscurities of the ternary operator, if you
really
On Apr 24, 2014, at 7:33 AM, Alex Zavatone z...@mac.com wrote:
And we messed around a bit looking for any shorthand and though it looked
like a terrible idea since the comparison is done against integers using the
ternary operator, I'd like to know exactly why it's a terrible idea.
On Apr 24, 2014, at 8:21 AM, Roland King r...@rols.org wrote:
well not if it's actually
x = (x) ?: @yo;
but
x = (x) ? x : @yo ;
No; “a ?: b” is legal syntax in GCC and Clang*. It’s equivalent to “a ? a : b”.
I don’t think it’s made its way into a C standard yet, but it’s so
On Apr 24, 2014, at 11:21 AM, Roland King wrote:
well not if it's actually
x = (x) ?: @yo;
but
x = (x) ? x : @yo ;
seems to be fine.
nil is defined to be 0, 0x0, any other kind of zero you like.
I don't like bools not being bools so I'd personally do
x
On Apr 24, 2014, at 12:44 PM, Jens Alfke wrote:
On Apr 24, 2014, at 7:33 AM, Alex Zavatone z...@mac.com wrote:
And we messed around a bit looking for any shorthand and though it looked
like a terrible idea since the comparison is done against integers using the
ternary operator, I'd
On Thu, 24 Apr 2014 09:44:42 -0700, Jens Alfke said:
NSString x;
x = (x) ?: @yo;
It’s not a terrible idea; I use this pattern a lot.
The ternary operator doesn’t just work on integers. It’s like “if”, it
takes any expression that can be interpreted as a boolean. For a pointer
the test is
On Apr 24, 2014, at 9:53 AM, Alex Zavatone z...@mac.com wrote:
What worried me was that I've never seen this used in Objective-C in this
manner. I've always used the ? operator to color the backgrounds of cells
with alternating row colors. It seemed like a stretch to actually use it to
On Apr 24, 2014, at 8:48 AM, Scott Ribe scott_r...@elevated-dev.com wrote:
On Apr 24, 2014, at 9:21 AM, Roland King r...@rols.org wrote:
well not if it's actually
x = (x) ?: @yo;
Actually, that will work just fine. Personally, I'd leave off the extraneous
():
x = x ?: @yo;
On Apr 24, 2014, at 9:48 AM, Scott Ribe scott_r...@elevated-dev.com wrote:
(foo ? x : y) = @yo;
Darn it, C++ once again infected a post of mine ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
___
In Smalltalk, where nil is an object like everything else, and we were working
with calls out to C APIs that had a lot of required parameters, we added an
orIfNil: that was very useful:
foo := bar orIfNil:10.
Nil
orIfNil:other
^other
Object
orIfNil:other
^self
It would be useful in ObjC if
Could we throw a category on NSObject for that and then every class that
originates with NSObject gets that lovely method?
Agree on the clunky bit, but so is using the @ compiler directive to accomplish
everything that couldn't be fit in in the first place. Not as if I know a
better way to do
On Apr 24, 2014, at 2:10 PM, Alex Zavatone z...@mac.com wrote:
Could we throw a category on NSObject for that and then every class that
originates with NSObject gets that lovely method?
What's wrong with the simple straightforward C way???
--
Scott Ribe
scott_r...@elevated-dev.com
That won't do any good, since if the receiver is nil, it'll return nil (since
nil isn't an object like it is in Smalltalk)
So the only place where it actually gets called will be the places that don't
need it.
On Apr 24, 2014, at 3:10 PM, Alex Zavatone z...@mac.com wrote:
Could we throw a
On Apr 24, 2014, at 4:10 PM, Alex Zavatone z...@mac.com wrote:
Could we throw a category on NSObject for that and then every class that
originates with NSObject gets that lovely method?
Not exactly, because unlike Smalltalk's nil, Objective-C's nil is *not* an
object. But you could switch
On Apr 24, 2014, at 5:00 PM, Scott Ribe scott_r...@elevated-dev.com wrote:
What's wrong with the simple straightforward C way???
One improvement might be if there was a ?:= conditional assignment operator.
Just as
x += y; is the same as x = x + y;
and likewise for other binary operators,
I hadn't known about the foo ?: something when I was thinking of macros -
it's much closer to an orIfNil: than foo ? foo : something
An orIfNull: for NSObject and NSNull might be nice for those times when you put
placeholders in dictionaries.
On Apr 24, 2014, at 2:21 PM, Andy Lee wrote:
On
On Apr 24, 2014, at 14:21 , Andy Lee ag...@mac.com wrote:
I still don't see how
foo = [@Something fallbackIfNil:foo];
has any advantage over
foo = foo ?: @Something;
I don’t see how the latter has any advantage over your earlier suggestion [more
or less]:
if (!foo)
On Apr 24, 2014, at 5:39 PM, Lee Ann Rucker lruc...@vmware.com wrote:
An orIfNull: for NSObject and NSNull might be nice for those times when you
put placeholders in dictionaries.
For that you really only need a method in one place. I'd be inclined to put it
in NSNull:
+
That's the flip side of what I was thinking about, but also useful. I was
thinking about the code that receives the dictionary:
- (void)processDictionary:(NSDictionary *)d
{
foo = [[d valueForKey:@foo] orIfNull:fooDefault];
...
On Apr 24, 2014, at 2:56 PM, Andy Lee wrote:
On Apr 24, 2014,
On Apr 24, 2014, at 6:03 PM, Lee Ann Rucker lruc...@vmware.com wrote:
That's the flip side of what I was thinking about, but also useful. I was
thinking about the code that receives the dictionary:
- (void)processDictionary:(NSDictionary *)d
{
foo = [[d valueForKey:@foo]
On Apr 24, 2014, at 5:45 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Apr 24, 2014, at 14:21 , Andy Lee ag...@mac.com wrote:
I still don't see how
foo = [@Something fallbackIfNil:foo];
has any advantage over
foo = foo ?: @Something;
I don’t see how the latter
On Apr 24, 2014, at 5:21 PM, Andy Lee wrote:
On Apr 24, 2014, at 4:10 PM, Alex Zavatone z...@mac.com wrote:
Could we throw a category on NSObject for that and then every class that
originates with NSObject gets that lovely method?
Not exactly, because unlike Smalltalk's nil,
33 matches
Mail list logo
