Translate ASOC into Objective-C?

Scripting Forums AppleScriptObjC and Xcode
,
#11

Get used to it :D. Objective-C is a superset of C. Objective-C started out a s pre compiler and in some sort of way still is. Properties, synthesize, implementation, interface, Class, protocol etc… are all compiler instructions. For instance a property + syntesize will just be replaced by a getter and setter method (and methods will be replaced by C functions further in the process before compiling). The more you work with Objective-C the more you will love it and also the more you will hate it. Many times I write C because “I can make that code better in C myself because Objective-C can’t”. When performance becomes an important part of you application you will need C or C++. There is a reason why the core parts of the system and applications are almost never written in Objective-C. Those parts are mostly written in C/C++ like Safari and iTunes for example.

Don’t get your hope up too high if you’ve seen Microsoft’s visual studio’s debugger. Xcode has comporared to Window’s debugging tool still a poor debugging utility. If you’ve only worked with ASOC a whole new world opens.

You sometimes need that in Objective-C as well. Objective-C inherit some drawbacks from C while C++ and C# solved these problems like type casting.

You now have full access to cocoa as well. Core foundation is not Cocoa, it is a C library/API and published under a different library (open source). So it’s a big plus that most of these features are supported by the AppleScriptObjC framework.

See my first answer. I can assure you that less than 50% in the AppStore is actually written in Objective-C. I guess it’s around 10% maybe.

How will you be assured that Apple won’t do that with Objective-C? When I programmed C and Carbon to make Mac OS applications and went to Mac OS X, the Carbon framework that has been used By Adobe, Microsoft and Quark for a very long time (till Leopard; still the core is in C++). Also Carbon was always superior to Cocoa, Cocoa with Objective-C gives the programmer some scripting-feeling which makes late bindings easy and more reliable than with Carbon. Also the goal was with Objective-C and Cocoa to keep the programmer away from the OS and more towards the desktop. Result is coercing paranoia (where casting isn’t possible) if you want something that isn’t in the API (Yet), only we give it a fancy name: ‘Wrapper’.

Well I don’t want to keep you away from Objective-C, I would welcome you to join it. But so many people had their expectations high from Objective-C. Pure Objective-C wise (no core frameworks, no C or C++) there isn’t much that Objective-C can do more than AppleScriptObjC.

#12

I knew that – it’s the big advantage of the bridge (except for methods that use blocks). The problem is not Applescript, ASOC, Objective-C, C++, C or the Intel assembler: the problem is always to have a clean design of the application.:wink: All the problems I have had in ASOC won’t be solved by coding in Obj-C.

Well, no gain, only the pain? Or is it the traditional “Give me C or give me death”?

When I programmed in Pascal, it was “use MC68000 assembler to get this thing done”; In Object Pascal, I was violating the encapsulation to make things work faster, so I know the feeling. Always one layer down.

No, my real problem is code readability. Applescript, ASOC and Obj-C all have, for me, this trait in common. When I say “tell application Finder to set theList to files of theFolder”, I can return two years later to my code and still understand what I did.

No one would have the idea to organize an International Obfuscated Applescript Code Contest. But such a thing exists for C. Is it a sign?

I thought ObjC is to so far from ASOC- I’ll try first to “translate” a small ASOC app (with array bindings in a table) to ObjC, just to keep my mind awake.

Anyway, thank you for your detailed answers, each of you!

#13

No not at all. But you said ‘I don’t like C’; it’s more like a warning that you need a lot of C in Objective-C when you want something that Apple doesn’t have pre-coded for you.

Great! so you’re prepared then that Objective-C isn’t the solution for everything

That’s where comments are for ;). I understand the advantage of AppleScript but it’s the responsibility of the coder to create good readable code. I’ve seen AppleScript code that is more complex than C. Also In my opinion Objective-C is not user friendly at all.
example:

First: AppleScript and C are totally different and can’t be compared. Second: the number of C programmers is more than a thousand times larger. C is multi platform, can be used in micro controllers, different OS (PC, handhelds and tabloids) while AppleScript can only be used in Apple’s desktop OS Since system 7. AppleScript is too simple and basic and one OS oriented and therefore not worthy to create any kind of AppleScript contest.

After all I still think you should take a look at Objective-C because performance wise you have an big improvement. After all ASOC is slow when the framework can’t coerce the code into a full Objective-C class. Like I say, don’t expect something like the solution for all of your ASOC problems.

#14

FWIW, obfuscated AppleScript competitions used to be more-or-less regular occurrences on the AppleScript and MACSCRPPT mailing lists. Entertaining they were, too.

I don’t like C either, but how much of it you have to use depends very much on what you’re trying to do. If a project is interface heavy, chances are the only thing you’ll need to deal with are C-style control structures.

There are a couple of bits of C in AppleScriptObjC Explorer, where some Carbon stuff is required, but otherwise it’s Objective-C with a dash of AS. I didn’t see anywhere that performance required using C. The fact that I had that option was comforting, though.

I’ll happily bow to DJ’s experience on programming matters, but I don’t find Objective-C particularly unfriendly. But I think that’s very much a subjective call, depending on your background. What matters is how friendly you find it.

#15

Thanks and you’re right Shane. Therefore I started with ‘in my opinion’ because what is good for one doesn’t have to be good for another. Clean organized code doesn’t really come with the programming language. Larry flon wrote once “There is no programming language, no matter how structured, that will prevent programmers from making bad programs.”. I think you can tell the same about code organizing. The Problem (personal) is that I mess up Objective-C more often and need more time to re-structure to make it user friendly again before it gets released and archived.

#16

First troubles.

Interface part:

 @property (assign) IBOutlet NSMutableArray *classNames;

implementation part:

 @synthesize classNames;

in applicationDidFinishLaunching:

self.classNames = [NSMutableArray arrayWithArray: [theDictionary allKeys]];
NSLog(@"Array : %@", self.classNames);

Log gives the correct contents, but nothing appears in the table view.

Is the use of “self” ok? If I use it, no error but not text in table view. If I don’t – bang.

#17

what is the IBOutlet for?

the self. syntax uses the synthesized accessor methods which is necessary for key value observing.

Have you set the bindings correctly?

Unlike Shane’s statement I recommend to always retain (for collections) or copy (for NSString/NSNumber etc) object properties even in garbage collection environment and set them with self. to nil in the dealloc method.

An exception are UI element IBOutlets in Mac OS, which could be assigned

As iOS doesn’t support Garbage Collection at all, I would use Memory Management or ARC anyway

#18

The first lines are always the worse.

NSBundle *bundle = [NSBundle mainBundle];
NSString *filePath = [bundle pathForResource:@"Classes" ofType:@"plist"];
self.classNames = [NSMutableArray arrayWithContentsOfFile];
NSLog(@"Array : %@", self.classNames);

logs self.classNames: (null).:mad:

Is "self.classNames = " the equivalence of ASOC “set my classNames to”?

Suddenly ASOC seems a breeze :confused:

#19

I don’t think you want classNames to be an IBOutlet, you can’t have an array in IB that you would be connecting that to (but I tested that and that’s not what is keeping the data from showing up in the table). I suspect you have something in your bindings set up wrong. You should just have your array controller’s content array bound to app delegate with MKP of classNames, and your column in the table should be bound to the array controller with controller key arrangedObjects.

#20

is the root element of the plist file really an array (normally it’s a dictionary)?
Consider also that using arrayWithContentsOfFile the array items are not mutable although the array itself is mutable.

Yes

#21

Ric,
First it wasn’t. I’m just trying to get this thing work and test everything.

Stefan,
The file is a plist file whose first key is array-type and contains 10 strings.

If the file is badly formatted, what will return? A null array (null) or an empty array ()?

PS:
Oh, oh. that’s why not putting “my” produces no result (and no error): the variable is local to the handler, it is not the property anymore.

#22

maybe you should use a standard plist file with a dictionary root element

#23

Ok, it’s working now:

the plist file is a list of dictionaries. No “root” key. Shouldn’t be one?

Thanks!

(Note: I remember now – it took me weeks to understand the basic of ASOC. I had just forgotten :slight_smile: )

#24

Stefan, I’ve seen you post this before, where does this idea come from, that the “normal” plist has a dictionary as its root object? I’ve used plists with arrays at the top with no problem. Apple’s docs say:

" A root property-list object is at the top of this hierarchy, and in almost all cases is a dictionary or an array."

Ric

#25

You’re right, “standard” plist file means that all preference plist files have a dictionary root element as well as the empty plist file from the Xcode file template.
Furthermore all examples in the Property List Programming Guide are dictionary based property lists

#26

Ok, so I tried this without success:

self.classNames = [NSMutableArray initWithArray: [theDictionary allKeys] copyItems : true];

Xcode says: No known class method with such name. I know, but why can I not use an instance method?

Now take time to look back at ASOC and consider that

set my classNames to theDictionary’s allKeys()

simply works-- elements of the AS list are mutable, no worries, and the code is much more readable, is not it?

#27

you forgot the alloc

self.classNames = [[NSMutableArray alloc] initWithArray: [theDictionary allKeys] copyItems : YES];

but copying the items doesn’t make them mutable, only new objects are created.

The mutable issue is:

If you create an mutable array with [NSMutableArray arrayWithArray:someArray], the new array is mutable that means you can add, insert and remove items.
If one of the items in the array is an dictionary for example and this dictionary was mutable in someArray, it’s now immutable.

#28

Ok, and now. what the heck is this:

@synthesize gSegControl = _gSegControl;

a) is the property gSegControl “renamed” _gSegControl? And why?
b) what’s the difference between self.gSegControl and _gSegControl
c) which one should I use? which one should I not? :rolleyes:

Thanks!

#29

first of all

mine too, gSegControl is not very readable :wink:

there is an instance variable _gSegControl and a property gSegControl.
An instance variable can be synthesized with a different name

the dot syntax self. uses the synthesized accessor method, the second case accesses the instance variable directly.

for key value observing/coding use the property with self. syntax, otherwise the instance variable is sufficient.

Normally it’s not necessary to synthesize a property with a different name,
if you don’t know the purpose it confuses more than it helps

#30

Ok. so let’s say I want to reproduce :

script myAppDelegate
property parent : class “NSObject”
property theSegmentedControl : missing value – outlet
property theArrayController : missing value – outlet
property theDictionary : missing value – no outlet, just a property to be accessed by all methods
property currentClass : missing value – no outlet, just property

I should declare, in the .h file :

@interface myAppDelegate : NSObject

@property (assign) IBOutlet NSSegmentedControl *theSegmentedControl;
@property (assign) IBOutlet NSArrayController *theArrayController;
@property (assign) NSMutableDictionary *theDictionary;
@property (assign) NSString *currentClass;

@end

and then, in the .m file :

@implementation myAppDelegate

@synthesize theArrayController;
@synthesize theSegmentedControl;
@synthesize theDictionary;
@synthesize currentClass;

And now for coding:

NSString *filePath = [[NSBundle mainBundle] pathForResource:@"Classes" ofType:@"plist"];

theDictionary = [[NSMutableDictionary alloc] dictionaryWithContentsOfFile: filePath];

// NO: gives no visible @interface for 'NSMutableDictionary declares the selector ‘dictionaryWithContentsOfFile’

theDictionary = [NSMutableDictionary dictionaryWithContentsOfFile: filePath];

// NO: gives EXC_BAD_ACCESS – Bang!

self.theDictionary = [[NSMutableDictionary alloc] dictionaryWithContentsOfFile: filePath];

// NO: gives error no visible @interface.

And of course self.theDictionary = [NSMutableDictionary dictionaryWithContentsOfFile: filePath]; bangs too.

Remember? I’m trying to translate only a working property theDictionary : missing value! Maybe I’m too stupid but I just can’t see yet the advantages of Objective-C. How long did I read on another post? One year? :frowning: