I have seen this syntax in ruby for a number of items and I wanted to learn more about when it's used.
def __some_wrapper__
#__some_wrapper__ ||= SomeClass.new(self)
end
When and where are two lower dashes __ before and after a name used? What's the rule for it? I have seen it used for method names, and such.
I have seen this syntax in ruby for a number of items and I wanted to learn more about when it's used.
This is just a method definition like any other method definition. An underscore is a legal part of an identifier. It doesn't have any special meaning whatsoever.
When and where are two lower dashes __ before and after a name used? What's the rule for it? I have seen it used for method names, and such.
As with any other name, a developer uses such a name when she thinks that it is the right name to use for this thing. There is absolutely no difference whatsoever between the names ✅ or foo or add or __some_wrapper__. You choose the name which best conveys the intent of the method.
Related
I have this line of code before I create my entity manager:
breeze.NamingConvention.camelCase.setAsDefault();
and this query:
var query = entityQuery.from('vehicle')
.expand("engine, driveType")
.select("engine.friendlyEngineName, driveType.friendlyDrivetrain")
The data comes back like so:
driveType_FriendlyDriveTrain = "Rear Wheel"
engine_FriendlyEngineName = "6.2L V8"
Why are "FriendlyDriveTrain" and "FriendlyEngineName" PascalCase? This seems clearly wrong since I set camelCase before I created the EntityManager and the query. How do I make it so that the parts after the '_' are camelCase as well?
note: I made sure to remove any web api json formatting configurations so that breeze is the only one managing the translation.
edit: The weird thing is that this same query returns properties that are camelCase after the '_' when it hits the cache. So same query, two different results.
Please review the documentation on NamingConvention. If that doesn't clear it up, you can come back and ask a more specific question. Thanks.
Edit 2 Sept 2014 (morning)
Please also explain what you think Breeze should be doing with the "_" character. The Breeze convention treats it like any other identifier character (e.g., a-z,A-Z,0-9) and does nothing with it. It seems you want your convention to skip over leading underscores and lower the case of the first char thereafter if it is alpha. I think you also want to drop the underscores ... but I'm not sure.
That's cool. You can write your own NamingConvention that does what you want. And you can make it the default too. In fact, the noUnderscoreConvention shown on the NamingConvention documentation page is more than half way home for you.
I will say you threw me for a loop with your mix of periods and underscores in the select statement and returned data. I have no idea how you got the select to work or got that kind of result.
Edit 2 Sept 2014 (afternoon)
Ok ... I overlooked the fact that you are doing a projection!
The projection flattens dotted property path values (whether ComplexType or EntityType navigations). It creates projected property names for these "flattened properties" by using "_" as the separator character. Yes, it applies the applicable MetadataStore's naming convention to those "_" separated names and, yes, the Breeze camelCase convention doesn't do anything special with the underscore. So you get back flattened projection property names such as "engine_FriendlyEngineName".
You can call this a bug if you like. I don't. I don't because (a) it seems to me a matter of opinion as to what a camelCase convention should do in this situation; (b) it's been this way forever; and (c) I don't think it is important enough to risk breaking existing applications that might rely on the current behavior ... not when your remedy is so simple.
And that remedy is to write your own camelCase convention that handles these projected property names differently.
Please include it here when you write it so that others who share your perspective may benefit from it.
I'm not sure what you mean when you write: "this same query returns properties that are camelCase after the '_' when it hits the cache". What query is that? Not the one you wrote here.
Projection results don't "hit the cache" ... unless the projected property value is itself an entity ... and that is NOT the case here. What do you mean by "this same query". I await your response.
After having spent a lot of time researching Rails reserved words and implementing, I still have a few questions regarding use.
In my example here, I'll consider the reserved word 'time'.
Let's say I want to create a class 'Timepiece'. Is it not recommended to use 'timepiece' because the name begins with 'time'? Would it be recommended to use 'time_piece' or to avoid inserting the reserved word at all? My question here is also about use of the exact reserved word within the class like that.
Thank you.
How is time a reserved word?
How does time_piece not use a reserved word like timepiece does?
In any case, name your classes what they should be named: there's no reason, technical, cultural, semantic, or otherwise, not to use a reserved word inside a class or variable name, even if Time was the same as time (it isn't) and time was reserved (AFAIK it isn't).
Let's instead say you meant Time, which isn't a reserved word, but is an existing class. If you name something Time you're re-opening the class. If you name something with Time in it it's entirely unrelated to Time itself, and whether or not you should use it as part of the name has more to do with semantics than anything else: again, no reason not to.
Lets say I have a field which accepts A-Z,a-z,0-9 . If I'm trying to communicate to someone, via documenation or api creation "what" my code can accept, i HAVE to say:
A-Z,a-z,0-9
Now that in my mind this is restrictive and error prone.
Compare that to what i'm proposing.
Suppose A-Z,a-z,0-9 was allocated the "code" ANSI456
When I'm communicating that to someone, I can say that my code accepts ANSI456. If someone else was developing a check, there is no confusion on what my code can or cannot accept.
To those who will suggest just specifying character ranges, please note that what i'm envisioning will handle scenarios where even this is defined as a valid "code"
0-9, +, -, *, /
In fact, if its done properly, we can have a site generate automatic code in various languages to accomodate the different "codes".
Okay - i KNOW there are ~ infinite values, eg:
a-z
is different from
a-l,n-z
And these would have two different codes in this "system".
I'm not proposing a HUMAN moderated system - it can be completely automatic BUT systematic way of generating these "codes"
There already is such a standard, although it doesn't have the word "standard" in its name. It is called Perl 5 compatible regular expressions, and it is used in Perl 5, Java, JavaScript, libpcre and many other contexts.
I come across the following in code.
_name1
_name2
smeEGiGross:
In general, what does _name1 underscore mean in Delphi 4?
I think it's just a common practice to begin variable names with underscores.
Rules for variable (and component) names in Delphi:
Name can be any length but Delphi uses only first 255 characters.
First character must be letter or underscore not a number.
You cannot use any special characters such as a question mark (?), but you can
use an underscore (_).
No spaces area allowed in the name of a variable.
Reserved words (such as begin, end, if, program) cannot be used as variables.
Delphi is case insensitive – it does not matter whether capital letters are
used or not. Just make sure the way variables or components are used is
consistent throughout the program.
It's a convention to help determine scope of a variable by its name, like private class members. The original author probably uses C++ as well.
In Delphi, I prefer to prefix fields with "F", method parameters with "a" (argument) and local variables with "l".
Update:
Another place you might see underscores is after certain identifiers in code generated with WSDLImp or TLBImp to avoid confusion with existing Delphi identifiers. For example, unless you specify otherwise, "Name" is renamed (no pun intended) to "Name_".
To add to the answer of phoenix:
* You can use reserved words as identifiers, but you must add a & sign: &then,
&unit.
I only use this if another name ís not apropriate.
I associate leading underscores with C/C++ not with Delphi. The C syntax is more character oriented (like {, }, || and &&) so the underscores fit perfectly. While the Delphi/Pascal syntax is more text oriented (begin, end, or, and) so the underscores look a bit strange as you don't expect them there.
It's regularly used for scope.
I declare all my private variables with a _ at the beginning, which is more common in C#/C++.
It's for readability and doesn't necessarily mean anything.
I cannot say what the author of the code you have in mind was thinking, but an underscore prefix has a fairly well recognised convention in relation to COM.
Members in a COM interface that have an underscore prefix are (or were) hidden by default by interface browsers/inspectors, such as VB's library browser etc. This is used when members are published by necessity but are not intended to be used directly.
The _AddRef and _Release members of the IUnknown interface are perhaps the most obvious example of this.
I've adopted this convention myself, so that for example if I declare a unit implementation variable that is exposed through the unit interface via an accessor function I will name the variable with an underscore prefix. It's not strictly necessary in that sort of example but it acts as documentation for myself (and anyone else reading my code that is aware of the convention, which is fairly self-evident from the context).
Another example is when I have a function pointer that may refer to different functions according to runtime conditions so the actual functions that the pointer may refer to are not intended to be called directly but are instead intended to be invoked via the function pointer.
So speaking for myself, I use it as a warning/reminder.... Proceed with caution you are not expected to reference this symbol directly.
Question
I would like to be able to use a single regex (if possible) to require that a string fits [A-Za-z0-9_] but doesn't allow:
Strings containing just numbers or/and symbols.
Strings starting or ending with symbols
Multiple symbols next to eachother
Valid
test_0123
t0e1s2t3
0123_test
te0_s1t23
t_t
Invalid
t__t
____
01230123
_0123
_test
_test123
test_
test123_
Reasons for the Rules
The purpose of this is to filter usernames for a website I'm working on. I've arrived at the rules for specific reasons.
Usernames with only numbers and/or symbols could cause problems with routing and database lookups. The route for /users/#{id} allows id to be either the user's id or user's name. So names and ids shouldn't be able to collide.
_test looks wierd and I don't believe it's valid subdomain i.e. _test.example.com
I don't like the look of t__t as a subdomain. i.e. t__t.example.com
This matches exactly what you want:
/\A(?!_)(?:[a-z0-9]_?)*[a-z](?:_?[a-z0-9])*(?<!_)\z/i
At least one alphabetic character (the [a-z] in the middle).
Does not begin or end with an underscore (the (?!_) and (?<!_) at the beginning and end).
May have any number of numbers, letters, or underscores before and after the alphabetic character, but every underscore must be separated by at least one number or letter (the rest).
Edit: In fact, you probably don't even need the lookahead/lookbehinds due to how the rest of the regex works - the first ?: parenthetical won't allow an underscore until after an alphanumeric, and the second ?: parenthetical won't allow an underscore unless it's before an alphanumeric:
/\A(?:[a-z0-9]_?)*[a-z](?:_?[a-z0-9])*\z/i
Should work fine.
I'm sure that you could put all this into one regular expression, but it won't be simple and I'm not sure why insist on it being one regex. Why not use multiple passes during validation? If the validation checks are done when users create a new account, there really isn't any reason to try to cram it into one regex. (That is, you will only be dealing with one item at a time, not hundreds or thousands or more. A few passes over a normal sized username should take very little time, I would think.)
First reject if the name doesn't contain at least one number; then reject if the name doesn't contain at least one letter; then check that the start and end are correct; etc. Each of those passes could be a simple to read and easy to maintain regular expression.
What about:
/^(?=[^_])([A-Za-z0-9]+_?)*[A-Za-z](_?[A-Za-z0-9]+)*$/
It doesn't use a back reference.
Edit:
Succeeds for all your test cases. Is ruby compatible.
This doesn't block "__", but it does get the rest:
([A-Za-z]|[0-9][0-9_]*)([A-Za-z0-9]|_[A-Za-z0-9])*
And here's the longer form that gets all your rules:
([A-Za-z]|([0-9]+(_[0-9]+)*([A-Za-z|_[A-Za-z])))([A-Za-z0-9]|_[A-Za-z0-9])*
dang, that's ugly. I'll agree with Telemachus, that you probably shouldn't do this with one regex, even though it's technically possible. regex is often a pain for maintenance.
The question asks for a single regexp, and implies that it should be a regexp that matches, which is fine, and answered by others. For interest, though, I note that these rules are rather easier to state directly as a regexp that should not match. I.e.:
x !~ /[^A-Za-z0-9_]|^_|_$|__|^\d+$/
no other characters than letters, numbers and _
can't start with a _
can't end with a _
can't have two _s in a row
can't be all digits
You can't use it this way in a Rails validates_format_of, but you could put it in a validate method for the class, and I think you'd have much better chance of still being able to make sense of what you meant, a month or a year from now.
Here you go:
^(([a-zA-Z]([^a-zA-Z0-9]?[a-zA-Z0-9])*)|([0-9]([^a-zA-Z0-9]?[a-zA-Z0-9])*[a-zA-Z]+([^a-zA-Z0-9]?[a-zA-Z0-9])*))$
If you want to restrict the symbols you want to accept, simply change all [^a-zA-Z0-9] with [] containing all allowed symbols
(?=.*[a-zA-Z].*)^[A-Za-z0-9](_?[A-Za-z0-9]+)*$
This one works.
Look ahead to make sure there's at least one letter in the string, then start consuming input. Every time there is an underscore, there must be a number or a letter before the next underscore.
/^(?![\d_]+$)[A-Za-z0-9]+(?:_[A-Za-z0-9]+)*$/
Your question is essentially the same as this one, with the added requirement that at least one of the characters has to be a letter. The negative lookahead - (?![\d_]+$) - takes care of that part, and is much easier (both to read and write) than incorporating it into the basic regex as some others have tried to do.
[A-Za-z][A-Za-z0-9_]*[A-Za-z]
That would work for your first two rules (since it requires a letter at the beginning and end for the second rule, it automatically requires letters).
I'm not sure the third rule is possible using regexes.