are there constant strings for names of build in filters(CIColorControls, CIBloom, etc.) in Mac OS X?
There are constant strings like kCIInputEVKey, which you can use to avoid string literals like #"inputEV", but i can't find something similar for names of filters.
thx in advance!
Yevgeniy.
It's hidden away, but there is a list of names of filters, and what they do:
Core Image Filter Keys - Apple Documentation
As you’ve probably found out already, there aren’t.
While I see that filters can be provided at runtime, so in order to get the full picture you have to query the list of available filters at runtime, I can only guess why there isn’t a canonical set of filters that are guaranteed to exist — after all, that’s what introducing such constants boils down to.
Most (if not all) filters that were introduced in 10.4 are still around, so it’s not too unsafe a bet to rely on them sticking around. That said, you should probably always account for a failed lookup…
Related
After discovering (see here and here) that:
"VBA.Len" is not equivalent to "Len"
"VBA.LenB" is not equivalent to "LenB"
"VBA.Mid" is not equivalent to "Mid"
"VBA.Left$" is equivalent to "Left$"
and other confusing things like that:
"Left" and "InStr" are in this official list of keywords while it's not in this other official list of keywords
"InStrRev" and "LenB" don't appear in any official keywords lists while "InStr" and "Len" do appear in one or both lists
I'm left very confused about when to use "VBA." and when not.
Is there a way to obtain a real complete list of the native-internal VBA commands, more reliable than the official documentation?
I mean something like an "object browser" (where I can see the real complete list of the commands in the "VBA." library) for native-internal VBA commands?
The best resource is probably VBE's help and similar on-line, though it's not complete, and doesn't go into the details your raise. Also it doesn't document 'hidden' methods which were once intended to be deprecated but never were, some of which are very useful! Some of your questions were well answered in those other threads, but more generally about your points -
Qualifying with VBA is more about 'where' the method is sourced, and then whether or not there is any difference in the actual method, which in most cases there isn't apart from sourcing. Most of those strings functions are both in the Strings module and in the _HiddenInterface Interface (which is faster).
Left$ though is only in the Strings module, as are similar $ functions, and why you don't notice any difference in performance. Str is both in the _HiddenInterface and Conversion module.
If you're sure the unqualified versions do what you want you might think best to not to qualify, and generally that's fine. But if you ever end up with a project with a MISSING reference, unqualified Strings and DateTime functions will blow before your code has a chance to be alerted. Depending on how deployed or if not sure I tend to fully qualify, eg VBA.Strings.Left$, VBA.DateTime.Date. FWIW as a small bonus you'll get the intellisense.
I'm trying to figure out if it's possible to use different row templates for specific rows in an NSPredicateEditor (or, if need be, an NSRuleEditor). I've got a screenshot that I think helps me explain this more clearly.
In this contrived example, I only want people to generate a filter that looks for a specific path above a certain size. So, in Section A (the Any block), users can only specify path rules (and the users can add additional paths). In section B, I only want the Size option to be available.
Nothing's jumping out at me from the docs (or, the stuff that does jump out at me ends up being something else), but it seems like this is the sort of thing that might come in handy, which makes me think it might be possible.
From what I understand about NSPredicateEditor, this is not possible. You might be able to swing it if you do everything yourself with an NSRuleEditor, but I haven't played with that class as much.
So in a nutshell: if you implement it yourself, it's possible. With the built-in stuff, I'm 99.9% certain that it's not a configurable behavior.
There are a multitude of key-value stores available. Currently you need to choose one and stick with it. I believe an independent open API, not made by a key-value store vendor would make switching between stores much easier.
Therefore I'm building a datastore abstraction layer (like ODBC but focused on simpler key value stores) so that someone build an app once, and change key-value stores if necessary. Is this API too simple?
get(Key)
set(Key, Value)
exists(Key)
delete(Key)
As all the APIs I have seen so far seem to add so much I was wondering how many additional methods were necessary?
I have received some replies saying that set(null) could be used to delete an item and if get returns null then this means that an item doesn't exist. This is bad for two reasons. Firstly, is it not good to mix return types and statuses, and secondly, not all languages have the concept of null. See:
Do all programming languages have a clear concept of NIL, null, or undefined?
I do want to be able to perform many types of operation on the data, but as I understand it everything can be built up on top of a key value store. Is this correct? And should I provide these value added functions too? e.g: like mapreduce, or indexes
Internally we already have a basic version of this in Erlang and Ruby and it has saved us alot of time, and also enabled us to test performance for specific use cases of different key value stores
Do only what is absolute necessary, instead of asking if it is too simple, ask if it is too much, even if it only has one method.
Your API lacks some useful functions like "hasKey" and "clear". You might want to look at, say, Python's hack at it, http://docs.python.org/tutorial/datastructures.html#dictionaries, and pick and choose additional functions.
Everyone is saying, "simple is good" and that's true until "simple is too simple."
If all you are doing is getting, setting, and deleting keys, this is fine.
There is no such thing as "too simple" for an API. The simpler the better! If it solves the need the way it is, then leave it.
The delete method is unnecessary. You can just pass null to set.
Edited to add:
I'm only kidding! I would keep delete, and probably add Count, Contains, and maybe an enumerator (or two).
When creating an API, you need to ask yourself, what does my API provide the user. If your API is so simplistic that it is faster and easier for your client to write their own app, then your API has failed. Ask yourself, does my functionality give them specific benefits. If the answer is no, it is too simplistic and generic.
I am all for simplifying an interface to its bare minimum but without having more details about the requirements of the system, it is tough to tell if this interface is sufficient. Sure looks concise enough though.
Don't forget to document the semantics for "key non-existent" as it isn't clear from reading your API definition above. updated: I see you have added the exists method: is this necessary? you could use the get method and define a NIL of some sort, no?
Maybe worth thinking about: how about considering "freshness" of a value? i.e. an associated "last-modified" timestamp? Of course, it depends on your system requirements.
What about access control? Is it within scope of the API definition?
What about iterating through the keys? If there is a possibility of a large set, you might want to include some pagination semantics.
As mentioned, the simpler the better, but a simple iterator or key-listing method could be of use. I always end up needing to iterate through the set. A "size()" method too, if not taken care of by the iterator. It obviously depends on your usage, though.
It's not too simple, it's beautiful. If "exists(key)" is just a convenient shorthand for "get(Key) != null", you should consider removing it. I guess that depends on how large or complex the value you get() is.
Most languages give guidelines to separate different words of a name by underscores (python, C etc.) or by camel-casing (Java). However the problem is when to consider the names as separate. The options are:
1) Do it at every instance when separate words from the English dictionary occur e.g. create_gui(), recv_msg(), createGui(), recvMsg() etc.
2) Use some intuition to decide when to do this and when not to do this e.g. recvmsg() is OK, but its better to have create_gui() .
What is this intuition?
The question looks trivial. But it presents a problem which is common and takes at least 5 seconds for each instance whenever it appears.
I always do your option 1, and as far as I can tell, all modern frameworks do.
One thing that comes to mind that just sticks names together is the standard C library. But its function names are often pretty cryptic anyway.
I'm probably biased as an Objective-C programmer, where things tend to be quite spelled out, but I'd never have a method like recvMsg. It would be receiveMessage (and the first parameter should be of type Message; if it's a string, then it should be receiveString or possibly receiveMessageString depending on context). When you spell things out this way, I think the question tends to go away. You would never say receivemessage.
The only time I abbreviate is when the abbreviation is more clear than the full version. createGUI is good because "GUI" (gooey) is the common way we say it in English. createGraphicalUserInterface is actually more confusing, so should be avoided.
So to the original question, I believe #1 is best, but coupled with an opposition to unclear abbreviations.
One of the most foolish naming choices ever made in Unix was creat(), making a nonsense word to save one keystroke. Code is written once and read many times, so it should be biased towards ease of reading rather than writing.
For me, and this is just me, I prefer to follow whatever is conventional for the language, thus camelCase for Java and C++, underscore for C and SQL.
But whatever you do, be consistent within any source file or project. The reader of your code will thank you; seeing an identifier that is inconsistent with most others makes the reader pause and ask "is something different going on with this identifier? Is there something here I should be noticing?"
Or in other words, follow the Principal of Least Surprise.
Edit: This got downmodded why??
Just follow coding style, such moments usually well described.
For example:
ClassNamesInCamelNotaionWithFirstLetterCapitalized
classMethod()
classMember
CONSTANTS_IN_UPPERCASE_WITH_UNDERSCORE
local_variables_in_lowercase_with_underscores
I want to write a very simple Spell Checker. The spell checker will try to match the input word with equivalent words form the dictionary.
What can be done to find those 'equivalent words'? What analysis can be preformed on two words to mark them equivalent?
Before investing too much trying to unravel that i'd first look to already existing implementations like Aspell or netspell for two main reasons
Not much point in re-inventing the wheel. Spell checking is much trickier than it first appears and it makes sense to build on work that has already been done
If your interest is finding out how to do it, the source code and community will be a great benefit should you decide to implement your own anyway
Much depends on your use case. For example:
Is your dictionary very small (about twenty words)? In this case it probably is better to precompute all possible nearby mistaken words and use a table/hash lookup.
What is your error model? Aspell has at least two (one for spelling errors caused by nearby letters on the keyboard, and the other for spelling errors caused by the way a word sounds).
How dynamic is your dictionary? Can you afford to do a massive preparation in order to get an efficient retrieval?
You may need a "word equivalence" measure like Double Metaphone, in addition to edit distance.
You can get some feel by reading Peter Norvig's great description of spelling correction.
And, of course, whenever possible, steal code. Do not reinvent the wheel without a reason - a reason could be a very special domain, a special way your users make spelling mistakes, or just to learn how it's done.
Edit Distance is the theory you need to write a spell checker. You also need a dictionary. Most UNIX systems come with a dictionary already installed for your locale.
I just finished implementing a spell checker and used a combination of the following in getting a list of "suggested" words
Phonetic hashing of the "misspelled" word to lookup a hash of identical dictionary hashed real words (for java check out Apache Commons Codec for a suitable library). The phonetic hash of your dictionary file can be precomputed.
Edit distance between the input and the potentials (this is reasonably expensive so you need to reduce the list first with something like a phonetic hash, assuming a higher volume load - in my case, a server based spell check)
A known list of common misspellings, e.g. recieve vs. receive.
An ordered list of the most common words in the english language
Essentially I weighted each potential word primarily based on edit-distance and commonality. e.g. if word probability is a percentage, then
weight = edit-distance * 100 / probability
(lower weights are better)
But then I also also override any result with the known common misspellings (i.e. these always float to the top suggested result).
There may be better ways, but this worked pretty well.
You may also wish to ignore ALL CAPS words, initials etc, so choosing what to ignore is also something to think about.
Under linux/unix you have ispell. Why reinventing the whell.