Is there any difference between these two Leap.Gesture.GestureType values?
If there isn't any, then why they are written twice?
No, there is no real difference. The versions without the underscores violated the API naming conventions and are deprecated. They haven't been removed so that older code that uses them will still compile. You should use the versions with the underscore in the name.
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.
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
I'm having a function called isIos() which returns true if the device is iOS (this is a cordova app).
iOS is the correct brand syntax but the coding style implmented used camelcase for the function name.
Should the function name be:
isIos() or isiOs() or isIOs() or something else?
What is the recommended way of dealing with this?
There's no general recommendation, your language might have guidelines that you might want to follow (doesn't seem the case with Node.js or javascript), or your company or application might have guidelines that you will have to follow, or there might be existing uses of the term in the application that you'll probably want to imitate, otherwise just use what seems easiest to read.
In this case, it might be isIOS, or isIos.
If you're using camel case though you should probalbly always put in upper case the first character of each word, isiOs() seems very confusing.
Your best option in these cases anyway is often to spare you the embarrassment and use a different name, if you can come up with one.
EDIT:
If you are not required to follow strict camel case you can also settle to is_iOS, which lets you keep the original case. This is probably the best alternative.
I've recently implemented a package that uses the database/sql package. By limiting the SQL to very simple select/update/insert statements I assumed the package would work with all the DBMS supported by database/sql.
However, it turns out that some databases use ? as placeholder value while others use $1, $2, etc., which means the prepared statements will work with some DBMS but not with others.
So I'm wondering is there any technique to make this work in a generic way with all the supported drivers? Or is it necessary to have DBMS-specific code everywhere? (which I think would make the abstraction provided by database/sql a bit pointless). I guess using non-prepared statements is not an option either since different DBMS have different ways to escape parameters.
Any suggestion?
I assume this behaviour was left out specifically because SQL dialects vary significantly between databases, and the Go team wanted to avoid writing a preprocessor for each driver to translate 'GoSQL' into native SQL. The database/sql package mostly provides connection wrangling, which is an abstraction that falls under 'pretty much necessary' instead of statement translation, which is more 'nice to have'.
That said, I agree that re-writing every statement is a major nuisance. It shouldn't be too hard to wrap the database/sql/driver.Prepare() method with a regex to substitute the standard placeholder with the native one, though, or provide a new interface that specifies an additional PrepareGeneric method that guesses a wrapped sql.DB flavour, and provides similar translation.
Gorp uses a dialect type for this, which may be worth a look.
Just throwing out ideas.
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…
I am looking through code that has multiple naming conventions from multiple developers - a real treat. Amongst them are Hungarian ("s_year", "s_day") as well as this other style ("yearS", "dayS").
Does anyone know what this style is called? For bonus points, do you know where/when it originated?
Disclaimer: Bonus points are hypothetical and awarded on a per-request basis only. Please give 5-12 weeks for delivery.
Edit: I would like to add that there is a third notation ("sYear", "sDay") in the same file. It's the hat trick of naming conventions!
This is an perfect example of either no naming convention, or of a frequently changed naming convention. Unfortunately, I have seen this quite a lot.
It is called "lobotomized notation". It was invented by R. P. McMurphy.
It's likely it's not a notation at all - quite often [lazy] programmers will have a need for a unique variable where a similar one is already in scope - hence they needed another holder for a 'year' and 'year' was already taken so they opted for 'yearS'. If it's any notation at all, it would be to stand out in its blecherousness as a reminder to change it to something meaningful in the future (which never came. Mwahahahaha!)