Hi All,
I’m doing some investigative work using the Scripting Bridge:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ScriptingBridgeConcepts/ScriptingBridgeConcepts.pdf
The first step is to use the “sdef” and “sdp” terminal commands to generate
header files that can be i
When I create a new TextEdit document, add a “-“ (aka. HYPHEN-MINUS), select
this “-“ and then move the cursor inside the window I will see in Console.app
10 lines like:
24/06/2015 21:44:17.319 Han Radicals[20349]:
_NSExtensionIsSafeExpressionForObjectWithSubquerySubstitutions: Expression
cons
Hi,
Quick question, does the “super” of NSObject == nil?
Cheers
Dave
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.appl
yea, you can run class_getSuperclass([NSObject class]) to confirm
On Wed, Jun 24, 2015 at 10:50 AM, Dave wrote:
> Hi,
>
> Quick question, does the “super” of NSObject == nil?
>
> Cheers
> Dave
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple
I've been experimenting with Swift 2, and have started writing a generic
Vector3 class. It looks something like this:
-
protocol
VectorElementType: IntegerLiteralConvertible
{
func +(a: Self, b: Self) -> Self
}
struct
Vector3
{
init()
{
x = 0;
This is a problem that seems to come up a lot in swift (they really need
something like “IntegerArithmeticType” that includes floats, doubles, CGFloats,
etc… so we don’t have to cast for simple arithmetic).
I think the trick that IntegerArithmeticType uses is that it has a common form
that ever
Anyone know what would cause NSFileManager (on OS X 10.10) to fail to create an
NSItemReplacementDirectory? We’re using this call to create a temporary
directory to save an intermediate file into, and it works fine on iOS and Mac …
except for right now, when it’s started reliably failing on my M
On Jun 24, 2015, at 3:39 PM, Jens Alfke wrote:
> Anyone know what would cause NSFileManager (on OS X 10.10) to fail to create
> an NSItemReplacementDirectory? We’re using this call to create a temporary
> directory to save an intermediate file into, and it works fine on iOS and Mac
> … except
Never mind, I figured it out by running fs_usage to watch what was going on.
There were already 1000 of those “(A Document Being Saved By xctest %d)”
directories in the TemporaryItems directory, so apparently it gave up. The
underlying problem is that our code isn’t deleting those temporary dire
I'm really liking Swift 2, and after watching some of the WWDC2015 videos on
the subject, I can't wait to use it in a real project.
But one area where it REALLY bugs me is that external parameter names are
required. I can see their utility, particularly with regard to a set of default
values an
> On Jun 24, 2015, at 2:09 PM, Rick Mann wrote:
>
> But I don't understand the need to require the use of external names at the
> call site. If there's enough information available to the compiler at the
> call site to unambiguously choose a function or method to call, why must I
> supply the
> On Jun 24, 2015, at 2:09 PM, Rick Mann wrote:
>
> I'm really liking Swift 2, and after watching some of the WWDC2015 videos on
> the subject, I can't wait to use it in a real project.
>
> But one area where it REALLY bugs me is that external parameter names are
> required. I can see their u
> On Jun 24, 2015, at 14:53 , Greg Parker wrote:
>
> Swift's design is that the API author gets to choose what the call site looks
> like. Allowing the caller to choose whether to specify names or not hurts
> readability because of the inconsistency. It's bad for different calls to the
> same
I guess I cannot agree with you, Rick. I love the fact that Objective-C and
now Swift require parameter names. I prefer verbose function names,
parameters, etc.. than obtuse ones. I don't want to have to infer. I want
it to be explicit. Infering types works because let myAttribString =
NSMutableAtt
> On Jun 24, 2015, at 15:25 , Alex Kac wrote:
>
> I guess I cannot agree with you, Rick. I love the fact that Objective-C and
> now Swift require parameter names. I prefer verbose function names,
> parameters, etc.. than obtuse ones. I don't want to have to infer. I want it
> to be explicit.
As I wrote above, where you are assigning a type at that moment - no. Its
quite obvious. You're doing it right there where its obvious. Frankly, I
don't see the two things as being the two sides of the same coin. In one
case the type is seen pretty obviously because you're assigning it. In the
othe
> On Jun 24, 2015, at 15:43 , Alex Kac wrote:
>
> As I wrote above, where you are assigning a type at that moment - no. Its
> quite obvious. You're doing it right there where its obvious. Frankly, I
> don't see the two things as being the two sides of the same coin. In one case
> the type is
> On 24 Jun 2015, at 9:22 pm, Dave wrote:
>
> I was wondering if I should just give up now and forget using the Bridge or
> if there’s any chance that I might get a usable header file generated
> somehow. My instincts tell me to give up, but if anyone knows better or they
> know a better solu
> On Jun 24, 2015, at 14:53 , Greg Parker wrote:
>
> Swift 2 established a single default naming rule for all methods and global
> functions. Swift 1 had two different rules which was confusing. The naming
> rule (first parameter un-named, additional parameters named) was chosen
> because it
> On 25 Jun 2015, at 3:50 am, Dave wrote:
>
> Hi,
>
> Quick question, does the “super” of NSObject == nil?
>
> Cheers
> Dave
No, because super == self.
Perhaps what you mean is, does NSObject have a superclass? No it doesn’t. To
verify:
Class objSuper = [NSObject superclass];
On Jun 24, 2015, at 4:09 PM, Rick Mann wrote:
>
> I guess I disagree: it's obvious in most cases. Again, I'm just arguing for
> the OPTION. You can always choose to use the parameter name if you wish.
You have the option. Given this signature:
func foo(intArg: Int, stringArg: String) -> Bo
> On Jun 24, 2015, at 16:37 , Marco S Hyman wrote:
>
> On Jun 24, 2015, at 4:09 PM, Rick Mann wrote:
>>
>> I guess I disagree: it's obvious in most cases. Again, I'm just arguing for
>> the OPTION. You can always choose to use the parameter name if you wish.
>
> You have the option. Given t
> On Jun 24, 2015, at 15:43 , Alex Kac wrote:
>
> As I wrote above, where you are assigning a type at that moment - no. Its
> quite obvious. You're doing it right there where its obvious. Frankly, I
> don't see the two things as being the two sides of the same coin. In one case
> the type is
> On 25 Jun 2015, at 8:13 am, Rick Mann wrote:
>
> I guess I disagree with this assertion. Generally, in a given body of code,
> the usage will be consistent, and of course there are the billions of lines
> of existing (C) code where no parameter names are specified.
Reminds me of when I fi
Fascinating, thank you. I tried to do the two-type func+ generic, but I was
getting complaints from the compiler. I wonder what I did wrong.
So, Swift will preferentially select the single-type func+? That makes sense,
of course, but is it defined in the language spec to do so? Is that documente
>> code such as that above wouldn’t be an issue.
>
> Again, pretty huge burden.
Only a burden to one who wants the ability to call functions or methods with
or without argument names. Many (most?) are not asking for that ability.
___
Cocoa-dev maili
I am having a problem with NSViews and mouseDown events.
I have defined a custom view (call it CardView) that is an NSOutlineView
centered in a slightly larger view used as a border. When displayed, a CardView
looks like an index card holding an outline inside a narrow border. There are a
few s
On Jun 24, 2015, at 7:44 PM, Thomas Wetmore wrote:
> I am having a problem with NSViews and mouseDown events.
>
> I have defined a custom view (call it CardView) that is an NSOutlineView
> centered in a slightly larger view used as a border. When displayed, a
> CardView looks like an index car
Please continue to reply to the list. That way: a) others can jump in to help,
too; and b) others can see whatever advice I give to you (whether it turns out
to be good or bad).
On Jun 24, 2015, at 9:56 PM, Thomas Wetmore wrote:
> Thanks.
You're welcome.
> I must admit that I will have to w
Ken,
Thanks. I must admit that I will have to work for awhile to figure out what
your answer means. This is the first time I’ve done any out of the ordinary
custom view stuff, and I’m having to learn almost everything as I go along.
Getting dragging and resizing to work cleanly was a big accomp
Ken,
First followup.
I added an override of hitTest to my custom view.
Behavior is a bit confusing.
Say I have three overlapping views. If I click in a spot where they all overlap
over their respective table subview areas, hitTest is called on all three of
the custom views, and all three then
> On Jun 24, 2015, at 8:44 PM, Thomas Wetmore wrote:
>
> So I have a view in which one of the subviews seems to work fine with respect
> to mouse events, but the border subview around it seems to be invisible to
> the event system.
Experimentation has proven this statement incorrect. The bord
> On 25 Jun 2015, at 2:08 pm, Thomas Wetmore wrote:
>
> I assume the quirks of dealing with overlapping views have long been ironed
> out.
What SDK and minimum target version do you have?
I’m just wondering if there’s a compatibility thing kicking in for older
systems, which did not make an
IMHO, named parameters at call sites are one of the things that makes
Objective-C great; and I am VERY happy that Swift-2 enforces this.
It is not any additional burden in any modern IDE to have this; as the IDE’s
autocomplete fills in the parameter names for you.
Also, consider a body of code
34 matches
Mail list logo
