There was a discussion about that here in SO but I still have a question about that topic, though. So, a simple question: what is a naming convention for projects in Scala? Is it "my_new_project", "myNewProject", "my-new-project", "MyNewProject" or "mynewproject"? And the same question for packages.
Packages follow com.mycompany.myproject reversed-URL style. There is no naming convention for project names. Many people prefer all lower case with hyphenation like scala-foo. I prefer capitalised camel-case like ScalaFoo. It's a matter of taste. I have not seen scalaFoo as a project name convention, also underscore is not used (I think that's C or Python style?)
Like in the earlier days of Java, where almost every project begins with a J, there are a lot of projects beginning with scala. While I think this makes sense for porting existing libraries, I came to think that you should probably not call your project ScalaFoo or ScFoo but just Foo unless there is a specific reason to highlight the fact it's written in Scala.
You may take a look at the community libraries wiki to sense the taste for project names.
I don't know if there is a specific naming convention for projects in Scala, but usually the Java convention is used, so:
- thisIsAVariable (all but first word initial letter uppercase aka camelCase)
- ThisIsAClass (all initial letters uppercase aka PascalCase)
- com.example.www (reversed url for packages)
I've seen both camelCase and PascalCase for naming projects in Java, but I prefer PascalCase!
For projects, I have seen many people use my-new-project or MyNewProject frequently. I personally prefer MyNewProject. I have researched your question a lot and haven't found any set conventions for project names. I do believe on GitHub a lot of repositories use my-new-project and almost appears like it's their own convention for repository names.
For packages, the convention is to either use a company domain address or personal domain address with all lowercase letters in reverse order style: com.company.packagename.
Hope that helps!
Brady
Related
I'm a beginner at Flutter/Dart and I keep seeing dollar signs appearing before calls to classes or methods, an example is the following (found in Floor package documentation):
final database = await $FloorAppDatabase.databaseBuilder('app_database.db').build();
I've searched a lot and the only meaning of dollar signs in Dart that I could find is for string interpolation, but this doesn't seem the case.
It's not a Flutter or Dart convention - at least not an official one: the official Dart naming conventions document (as of October 2020) makes no mention of using $ in identifier names.
However, I do know that other programming languages' ecosystems do use a dollar-sign (Sigil) and I think that habit was inherited by the authors of the floor database that you linked to. More specifically, in Java it's commonplace to use a $ prefix for type-names generated by tooling rather than being hand-written (such as ORM entity types, for example), and people using RxJS observables in JavaScript will use a $ as a variable-name suffix.
As $FloorDatabase is a type-name, not a variable or member-name, I'm going to go with the assumption it's a habit picked-up from Java:
Java: The $ character should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems.
So in this case, a clue is in the documentation you linked to:
Use the generated code. For obtaining an instance of the database, use the generated $FloorAppDatabase class, which allows access to a database builder
So that's my conclusion: it's not an official naming convention in Dart/Flutter, but it is in Java, and it seems like the authors of floor carried it over from Java.
(I personally wish they didn't as it isn't a particularly useful indicator - what does it matter to a consuming application if a type was created a tool instead of hand-written?)
I am trying to localize a CPAN module MooX::Options using Locale::TextDomain after having read "On the state of I18N in perl".
In the discussion in the pull request the question came up how to deal with messages not originating in the module itself, but in a dependency. In this specific case, when you specify an option on the command line which is not defined anywhere in the code, you'll get the warning:
Unknown option: xyz
originating in the module Getopt::Long, which in itself is not localized yet.
The question is how to deal with these. I see basically three strategies:
Ignore them, which I find dissatisfactory.
Try to someway or other catch all the corner cases and messages in the module I'm currently localizing (in this case MooX::Options), and this way working around the missing localization in the dependent modules. This option seems brittle, as I'd have to constantly adapt to changes in the base modules. Sometimes, it might by next to impossible to catch messages, as they're written to output streams directly by the modules (as is the case in this example).
Try to localize the dependent modules themselves. This option seems hard to achieve, as different projects might use different I18N tools and strategies themselves and the dependency graph might be huge.
All in all, I think this problem is more general and not that specific to perl and cpan modules. So, I'm interessted in your thoughts, strategies and approaches.
I have rather strong opionions on the idea of translating computing terms, and most people disagree with my views, so take what I am saying with a grain of salt.
I do not understand the point of internationalizing a library for parsing command line options unless you want to further ghettoize what is already a small group of users of said library.
Would wget be more useful to Turkish users if instead it was called wal or wgetir? Or, instead of wget --mirror, should Turkish users write getir --ayna? What about that w?
If you just translate the messages, what is the point of outputting a help message in response to wget -h when the Turkish equivalent would be wget -y?
The fact is, almost all attempts at translating programming related terms I have seen are simply awful. The people who are most eager to translate are usually not in command of either human language — Nor do they seem to understand what they are translating.
However, as a result of these eager people, I find that at least the Turkish translations of pretty much any software I touch is just awful. Whatever Danish translations I have seen did not fare much better, but, at least, they were tolerable owing to the greater commonality of structure between Danish and English.
I think everyone's energy is better spent on actually making sure their programs handle content, including names of external resources/references, in different languages well, rather than giving me error messages in some Frankenstein language, or letting me specify command line options whose mnemonics do not match their descriptions etc, or presenting menus that contain of strings of words that really do not convey any meaning.
I have felt this way for the last for many decades now ... Even when I was patching IBM PC keyboard drivers with hex editors so people at various places could type reports in WordStar, and create charts in Harvard Graphics.
So, my unpopular advice is to put your energy elsewhere ...
For example, use exception objects so the user of your library (who is likely a programmer and will understand "Directory not found" much more readily than "Kütük bulunamadı") can deduce in a human-language independent way what happened, and what message to show the user. I haven't looked closely at MooX::Options, but I notice there is at least one string croak.
Here is an actual error message from an IBM product:
Belirtilen kütük örüntüsüyle eşleşen hiçbir kütük bulunamadı
You can ask every one of the almost 200 million Turkic people on earth what a "kütük örüntüsü" is, and only the person who actually came up with this non-sensical string of characters will be able to tell you that it corresponds to "file pattern". What, then, do they gain by using the phrase "kütük örüntüsü" versus "file pattern"? Nothing.
However, they lose the ability to communicate with, and, also, compete with, programmers in the English speaking world.
PS: Apologies for all Turkish examples, but I feel most comfortable drawing abominable examples based on my native language.
Just starting to learn scala for a new project. Have got to the point where I would like to define different properties files for the different environments the app is going to run on, ideally in a similar way to Rails - very lightweight, just one different properties file per environment that is loaded based on its name. I don't really care if it's a java properties file, YML or scala code.
In the spirit of not reinventing the wheel I've been looking to see if there is some accepted standard Scala way of doing this but I can't find one, I've found a few similar but not identical questions here where people suggest using system properties in the startup script but this feels like it would end up being a nightmare.
I could obviously implement it if needs be but feels like the sort of thing that should already exist. So - does it?
I'm using sbt if that makes a difference.
I know of Configgy. Also, Akka/Play 2.0 will be using Config, which looks nice too. See blog about the latter.
Basically, Configgy has been used for a while now, but has been deprecated, while Config will be all-new. However, having Config as the default Typesafe Stack configuration tool will probably make it the preferred tool for that pretty fast.
I have written a Configgy replacement called Configrity. It can use different input formats (like YAML), it's immutable, supports functional patterns and uses type class to convert automatically the values to the desired type.
I have written BeeConfig, a replacement for java.util.Properties except that it is a Scala API and uses UTF-encoded configuration files. It supports string interpolation, chaining and a bunch of other features. But its main objective is simplicity.
Bitbucket | Blog post
Rick
I realize that it is impossible to have one language that is best for everything.
But there is a class of simple programs, whose source code looks virtually identical in any language.
I am thinking not just "hello world", but also arithmetics, maybe string manipulation, basic stuff that you would typically see in utility classes.
I would like to keep my utilities in this meta-language and have it automatically translated to a bunch of popular languages. I do this by hand right now.
Again, I do not ask for translation of every single possible program. I am thinking a very limited, simple language, but superportable.
Do you know of anything like that? Is there a reason why it should not exist?
Check Haxe, and its Wikipedia page. It's open source and its main purpose is what you describe: generating code in many languages from only one source.
Just about any language that you choose is going to have some feature that doesn't map to another in a natural way. The closest thing I can think of is probably a useful subset of JavaScript. Of course, if you are the language author you can limit it as much as you want, providing only constructs that are common to just about any language (loops, conditionals, etc.)
For purposes of mutability, an XML representation would be best, but you wouldn't want to code in it.
If you find that there is no universal language, you can try a pragmatic model-driven development approach, using a template-based code generator.
On the template you keep the underlying concepts of an algorithm. Then, you would add code for this algorithm in one or more specific languages (C++,Java,JS,Python) when necessary. You would have to do it anyway, whatever the language or approach you choose. A configuration switch would pick the correct language for any template you apply.
AtomWeaver is a code generator that works with templates and employs ABSE as the modeling approach.
I did some looking and found this.
https://www.indiegogo.com/projects/universal-programming-language
looks interesting
A classic Pascal is very simple. Oberon is another similar option. Or you could invent your own derivative language similar to the pseudocode from the computer science textbooks. It's trivial to implement a translator from one of that languages into any decent modern imperative language.
I have created some of my own user packages and have run into a name clash.
In Java, the naming convention is to use your domain name in the package name:
e.g. import com.example.somepackage;.
Are there any widely used package naming conventions for common lisp packages?
Regards,
Russell
The convention I use is to use a unique word: salza, skippy, zs3, etc. I don't really try to have a direct relationship to the library functionality. I try to avoid generic words that others might use like "zlib" or "zip" or "png".
Edi Weitz uses Frank Zappa-related words to name many of his packages: Hunchentoot, Drakma, etc.
Some people use Java-style org.foo.bar reversed domain naming.
So, the direct answer is no, there isn't a common, agreed-upon convention that everyone uses.
One convention that you see sometimes is packages which provide a thin compatibility wrapper over routinely implemented but non-standardized functionality are often called TRIVIAL-SOMETHING.
This leads to some really wonderful names: the library for working with *FEATURES* in a implementation-independent way is called TRIVIAL-FEATURES; even better, the library for interacting with the garbage collector in a standardized way is called TRIVIAL-GARBAGE.
There's no general convention, but there are a few patterns:
When the library is a port from some other language, a wrapper or an interface library it is often prefixed with cl-, like cl-gtk2 or cl-ppcre. Although there was a time, when this prefix got abused, and there are a lot of packages (e.g. cl-who), that implement a unique functionality, but still use it.
If the package is implementation-specific, it's prefixed with implementation shorthand (most notably: sb-), like sb-queue or lw-compat.
If the package is a compatibility layer between implementations, it is often prefixed with trivial-, like trivial-backtrace or trivial-garbage
There's also s- prefix, which may stand for 'symbolic', like s-xml, but it's rarely used.
These prefixes help making the name of the package unique and thus simplify finding information about it on the web.
Otherwise there are no specific conventions, but the general rule is to favor short, unique and, probably, descriptive names. For the reasons of ease of remembering, usage and finding information.
If the package happens to have a long name it's handy to provide a shorter nickname, because more often, than not people will use package's symbols qualified by their names. For example in my code I add a nickname re to cl-ppcre, and it makes the client code much more understandable and clear. Although caution should be applied, so that nicknames didn't cause name-conflicts.