Just an update: it looks like that only happens with Satimage.osax installed. It defines a value-type of list of real, and I suspect that’s somehow involved.
I also gather that as anything probably shouldn’t work in the first place…
It has limitations, as I say. Cocoa’s error reporting is crap. Storing reference objects is a pain. The APIs are alien and intimidating to non-programmers. Ideally AppleScript would already ship with a standard libraries that provide AppleScript-friendly wrappers around all this weird NS crap, but the AppleScript team are clueless goobers who never think to do such useful, practical, simple things for their users; or just botch it when they do try because they never, ever eat their own dogfood, never mind listen to the users who do telling them precisely how foul it actually tastes.
–
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” --Brian Kernighan
Not sure where you’re getting that from. anything is just the AppleScript keyword for typeWildCard («class ****»). Which in this case forces ASOC to resolve the «class ocid» id ... specifier returned by NSDictionary so you get an AppleScript value back (which is maybe a feature, or maybe an undocumented quirk). I don’t think it’s perfect (e.g. single-item lists seem to come back as just the item), but as far as I can tell it works well enough for simple types like numbers and strings.
As I say, there are better ways associative data structures could/should be done in AS. For example, keeping all the values in an AS list and using an NSMutableDictionary to map keys to list indexes would bypass all the problems of sending complex values across the bridge. While I’m a bit time constrained these days, it’s the sort of thing I could easily develop, test, and package into a nicely documented library in an hour or two.
I actually proposed to Chris Page last month that we supply them with a small set of standard libraries that will be guaranteed to meet our needs because we build, test, document, and use them first ourselves, so that all they have to do is audit that code and get it into the next OS version. That’s four weeks with not so much as a cheep in response; not even to say “thanks but no thanks”.
I mean, I pull that sort of callous, lazy crap on other folks too (as I’m sure you know;), but I’m not the highly-trained, highly-paid team of experts responsible for a critical (well, at least to some of us) technology in a major OS platform from one of the biggest technology companies in the world, so what []itheir[/i] excuse is I would love to know.
p.s. Associative lists is one of the progressive teaching examples ** I used in the Apress book, precisely because I knew the code (while a naive implementation for learning’s sake) would also provide an instantly useful cut-n-paste practical solution to precisely these kinds of common user problems.
(** p.p.s. Bonus prizes to anyone who can spot the “deliberate” mistakes in them too.
Hello hhas.
I just didn’t see it then and there, OP wanted to paste together two labels, or ‘plcaceholder’ parts, and turn that into variable.
That was what I tried to solve, and during that course, at least I didn’t see the forest for the trees, because I never did that step of putting the parts of placeholders into variables first, and then concatenate those parts.
That is not an excuse, but an explanation.
When it comes to algorithms, I actually worked as a scientific assistant a couple of years, so I actually know something about algorithms, and what kind of problems the different datastructures are well suited for.
Everybody should 'read a book about algorithms, and I haven’t read the last one yet.
As for Nigel’s implementation, returns are really no problem, you can just substitute it for something, and the reverse the process. I’d choose character id 0.
The caveat with an associative array. is of course, that the keys are unique, which means that what goes in last, is what is going to be taken out of it, but sometimes, this is a great boon, and filter a set of keys and values, down to unique set.
Hi hhas.
Thanks for your post. Your incredibly arrogant belief in your own superiority makes very entertaining reading. :lol:
However, there’s no use banging on about education when your entire attitude is “The problem’s already been solved. Don’t think about it. Don’t reinvent the wheel. Use my brilliant and infallible libraries instead. Oh. And AppleScript and everyone and everything associated with it are crap.” That does nothing to further the understanding of, or to empower, people coming to these fora for help. And of course it makes scripting very boring and stifles the development of better or more appropriate wheels.
And it goes without saying that if you’re going to rant on in such a distainful manner, the script you post to back up your assertions should be at least as informative and work as well as the one on which you’re peeing.
No, but an own implementation of an hash table would still be better or at least safer, which is textbook by the way. I have written a hash table in plain AppleScript for educational purpose a couple of years ago[1].
I was still on Mac OS X 10.6.8 like >60% of all mac users back then, NSDictionary could only be used in ASObjC applications and not in scripts. So it was actually useful is rare cases like reading key value pairs from files.
[1]Truth to be told the script was actually written for an employee of mine to give a small insight on how associative arrays works in PHP and in general in pseudo code, but the code could easily be translated into AppleScript with some small adjustments, so I did.
I do remember your hash map, and I thought it was great. Before that, we did have the property list suite of System Events, that provided for at least dictionaries, with constant access time.
A hash map is a a dictionary with a hash table implemented to facilitate fast lookups while minimizing storage space. Well, Nigel’s dictionary, facilitates dynamic storage and a somewhat constant lookup time as well, at least as long as there are some limit to how many elements are stored in there. Yes, his implementation, probably reach that upper limit faster than yours, but then again, how many elements would your really store in a dictionary for practical purposes in an AppleScript? My theory is, that you have switched from AppleScript for other reasons, long before you reach the limit of the dictionary. 
I enjoy Algorithms, and the maths behind them, but what really make me tick at least, is how to translate the theoretic implementation of them into something that is adequate for solving a practical problem.
This is actually something I did learn to enjoy through styduing the book “Algorithms” by Robert Sedgewick, second edition, first and foremost. Some authors do take a sort of “hands on” approach, and deals with practical implementations, and that is an approach that is most fitting here, and which Nigel is extremely good at, because AppleScript isn’t a “normal” language in any way.
The second thing here, is that it is mentally stimulating to solve problems, and I think a lot is gained when you are having fun, finding a solution to a problem, so the road evolves as you walk, and sometimes, you end up with something far better than anything you’d find in a text book, if you carbon copied an algorithm. (Generally speaking).
People should acknowledge, that reaching some solution, is often a process of collaboration, and that it is the end product that counts, and for that end product to reach good quality, there must be room for fun, play, and exprimentation. Such processess works best in non-judgemental environments.
But why should it resolve it? “maybe an undocumented quirk” is not too far from “probably shouldn’t work”.
It has the same functionality as Nigel’s code but it’s safer and closer to how dictionaries should work, it works no matter what the string of the key contains. After all pretty on topic to me.
:/property list suite is something else, it is to read and write to property files, not to work with it as associative arrays. So I don’t see your point in writing that right now
Hello.
I actually did see your point in posting that right now, and therefore I edited that sentence away from my post.
I am not sure in the moment, if you have to create the property list file at disk, in order to manipulate the contents, but once you have the structure in memory, you can certainly add and retrieve keys -at constant time.
A property list in itself, at least contains a dictionary, therefore, I posted that as yet an example of a dictonary, which has been around for a while, and also to illustrate the example, that I just didn’t make a sour remark, that we had dictionaries in AppleScript already, when you posted your hashmap, even with inbuilt persistent storage.
Edit
Albeit somewhat slower since properties are stored on file immediately, I believe the items to be retrieved from memory however, during lookup.
I was posting while while you were editing
For MS maybe, but not for work.
Using a limited supported file, a wrapper application and some custom code required in order to make it work like a dictionary is not something I would call “dictionaries in AppleScript” but just another self implemented approach.
However to create records on the fly you can simply turn a list alternating key (string) and value (any object) into a record using the AppleEvent manager.
First of all, you are actually dead wrong in that, for work too, I mean if you work in a garage or something, then that may be true, and I am not saying that one shouldn’t judge the quality of the end product, but the process of achieving something better be open minded.
Secondly, I am dead sure that the property list file implementation of System Events rely on NSPropertyList, which in turn uses NSDictionary, so I am pretty sure that it is good enough for work.
The culprit, or boon in other situations, is that the keys/values are automagically written to disk, and not in a batch. This lowers the usability, if you have to store many keys at once, but has the advantage of the values written to storage asap.
So, it is a speed versus robustness approach.
Rhetorical question:
What constitutes an abstract datastructure? -Is it the implementation that should govern, or the properties it provides?
My answer to that questin would be that we have abstract datastructures to provide for implementation independency, so that we can implement them they way we see best fit in some problem solving situation.
To me someone who can’t handle critics or remarks about his quality of work isn’t open minded at all. Someone who is open minded does respect another’s opinion and will listen to what the other person has to say, even if the subject of the conversation is his own written code.
At least practice has showed me right.
Edit: last post, unless topic is getting on-topic again.
I agree with you in that in general, of course, but when the critique is expressed in an overbearing, or condescending tone, then there may be reason to react.
I didn’t not critisize your code in any way: You expressed your opinions, and I expressed mine.
I am also finished with this, unless it gets on track again.
Edit
My view on Computer Science in general, is that it is all about tradeoffs, and that there are very often parameters, that governs which solution is right, and that there at least very seldom exists solutions, that is a “cure-all” for a particular problem.
There is no class NSPropertyList, you probably mean NSPropertyListSerialization.
And the root object of a property list is not required to be an NSDictionary, it can also be an NSArray.
Sorry for the inaccuracy regarding NSPropertyListSerialization, when referring to the dictionary, I was more into the PropertyLists of System Events, I’m quite sure that using an array as a root-object, isn’t a solution there (but I’m not betting on it).
Thanks for the correction Stefan.
No, no. Not blaming you for missing it. Everyone learns by mistakes. This is why practice.
It’s useful info to skim over. Even if you don’t understand the half of it (which is fine; I certainly didn’t), it gives you an idea of what patterns to look for and where to go to fill in the rest of that know-how when the time is right.
Except the implementation doesn’t do that, nor does the documentation caution users to do it themselves. And even if it did, what happens if you then pass in another key that already contains NUL characters of its own? And, like I say, there’s other concerns like how performance goes down the toilet as the correction grows large, and what about deletions and stuff too? Five-minute hacks are all very well, but they have a terrible habit of biting you in the butt come minute six, and blossoming into a five-hour/five-day/ongoing PITA thereafter. Which you might accept as Just One Of Those Things if it’s some unique task that nobody else in the world has ever done before, but for something as humdrum and ubiquitous as this it’s really unforgivable that we’re still at this stage in AppleScript after 20 flipping years when the rest of the world had it solved 40-50 years ago.
This is why I’m so pissed at Apple: people use AppleScript because they’ve got immediate problems that they want to solve, not because they’ve nothing better to do than teach themselves a whole CS degree. You don’t empower users by forcing them to scrabble in the dirt day-in, day-out. This is why everyone but us has reusable libraries, so that basic, generic, everyday operations such as “store a whole bunch of values under arbitrary keys so that they can be retrieved again later” do not require an academic education or deep technical skills to perform: just the ability to read a few lines of documentation and type a couple commands verbatim.
That’s the power of programming: stuffing all the boring, tedious, micromanaging BS completely out of the way, so you can get on with the things you’re actually interested in. And it’s something that AppleScript’s keepers have not only failed to promote and support, they’ve actually encouraged the opposite: hand-to-mouth exchange of “priceless technical knowledge”, that’s actually just a load of self-aggrandizing garbage: Dunning-Kruger egotism and clueless, incompetent amateurism raised to high art.
Not clear what you mean. Caveats with different key-value data structures are things like performance characteristics when adding/removing/searching keys, and what type(s) of keys are accepted.
Again, the nice thing about having a prebuilt library like Cocoa or whatever is that the folks who’ve built it have already considered these issues and optimized and tested the total crap out of it, which they can afford to do because that’s their job, and by doing so they’ve just made millions of users’ jobs that much easier: because for 99.9% of day-to-day tasks, what they’ve provided is more than good enough to meet those users’ needs. Which means those users now have much more time to devote to solving the original parts of their problems, rather than just rebuilding the same old dreary wheels Every Single Time they want to get anything done.
This is true, but there are original problems and there are problems that have already been solved a myriad times before by folks much, much smarter than you or I. Trying to re-solve the latter is just so much make-work, not to mention excellent opportunity to introduce exciting new mistakes of your own. Better to reuse what already exists, and dedicate the time saved to the parts of your problem that are original. Having the ability to think algorithmically ought to be a complement, not an alternative, for plain common sense and ability to deliver on budget and time.
This is why I love working around end-user programming and end-user programmers so much: dealing with folks whose heads are still bolted on really keeps you grounded in timely serving real-world solutions to real-world problems, lest one disappears up one’s own indulgently playful but practically useless abstract ass.
[edited for clarity]
Traditionally, a [get] SPECIFIER as TYPE request kicks the job to the specifier’s owner - in this case ASOC - to resolve as it sees fit. And ASOC is fine with specific type names like integer, string, list, and so on, so assuming it’s using Apple Event Manager mechanisms as they were designed to be used, as opposed to doing weird, janky, everything-a-special-case nonsense (which I’ll admit is something a helluva lot of developers do do), then there should be no problem with anything as well, since that’s just one more type name that the AEM already knows how to deal with.
For instance, if you want to extract an Apple event’s direct parameter and don’t need it to be a specific type:
AEDesc directParamDesc;
OSErr err = AEGetParamDesc(theAppleEvent, keyDirectObject, typeWildCard, &directParamDesc);
This is a standard documented AE feature, working exactly as designed, ever since System 7.
Yeah, I’d be happier too to have the absolute official word from ASOC’s authors that it is indeed working exactly as designed, but a. they almost never speak to me (I do their egos no favors at all), and b. I strongly suspect I understand this stuff better than they do (a thought no-one finds more terrifying than me!). So I’m about as confident as I can be after a decade of trying to black-box reverse-engineer AppleScript’s inner workings to the best of my limited abilities. Caveat Emptor, E&OE, and so on.