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.
Related
I have a class (character) with inherited classes (solider, medic etc) that have specific game related methods. E.g. Shoot or Heal.
I want it so that the user can type in Heal, for example, and the program can check what type of character they have and therefore see if that is a valid name of a method in that Object.
I know it's possible in other languages but can't see how to do it in Pascal. It must work in Free Pascal as well as Delphi. Thank you
You don't need to be able to check for the validity of a method name to do this, and it is probably preferable if you don't.
You could do check a method name's using RTTI, but that is implemented somewhat differently in FreePascal than Delphi, (in particular for extended RTTI).
However, it would be far more straightforward to implement your own look-up mechanism to resolve in-game entity-names, properties and verbs in a dictionary of some sort. That would be trivial in both FP and Delphi and independent of the compiler used. It would also allow the names used by the end-user to be independent of the names used in code, which would be easier internationalisation, etc. It would also avoid the problem which would arise if an in-game identifier contained a character not permitted in a Pascal identifier (such as a space, accented character or whatever).
PS: You didn't ask this, BUT ... if I were contemplating writing a text-game of any size, I would seriously consider doing it as a hybrid Delphi of Prolog: Delpi for the gui and Prolog as a far easier language in which to code in-game actions, objects and rules, and there is one paricular implementation, Amzi Prolog, which has a very rich interface for interfacing a Prolog engine with Delphi -see https://www.amzi.com/#apls. Amzi used to be commercial but is now PD, fwiw.
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
I need to define simple classes and interfaces (Ex. IClassInterface) in a language neutral way and then use a variety of code generation tools to generate the code files in a variety of languages such as C#, Java, etc... Does anyone know of a standard; ratified or otherwise; that I can use for the neutral representation. I know UML is often used for creating diagrams, but I am actually looking for something that can easily be parsed, extended, and used to drive other automated processes. Maybe this is actually possible with UML, although I am not sure what the markup language might look like if one exists.
I could create my own definition using XML or something similar, but I would prefer to avoid reinventing the wheel if possible.
UML
I think you might be looking for XMI (XML Metadata Interchange)
There is IDL (for example, Google's protocol buffers), and WSDL, which can be used to produce interfaces and classes by many web service frameworks. (You typically do not have to use the generated code as an actual webservice.)
The wikipedia entry for IDL lists a number of implementations of IDL. Although IDL is mainly for describing interfaces, some implementations also use it to describe objects (e.g. Microsoft IDL.)
It seems strange to me that Perl would allow a package to export symbols into another package's namespace. The exporting package doesn't know if the using package already defined a symbol by the same name, and it certainly can't guarantee that it's the only package exporting a symbol by that name.
A very common problem caused by this is using CGI and LWP::Simple at the same time. Both packages export head() and cause an error. I know, it's easy enough to work around, but that's not the point. You shouldn't have to employ work arounds to use two practically-core Perl libraries.
As far as I can see, the only reason to do this is laziness. You save some key strokes by not typing Foo:: or using an object interface, but is it really worth it?
The practice of exporting all the functions from a module by default is not the recommended one for Perl. You should only export functions if you have a good reason. The recommended practice is to use EXPORT_OK so that the user has to type the name of the required function, like:
use My::Module 'my_function';
Modules from way back when, like LWP::Simple and CGI, were written before this recommendation came in, and it's hard now to alter them to not export things since it would break existing software. I guess the recommendation came about through people noticing problems like that.
Anyway Perl's object-oriented objects or whatever it's called doesn't require you to export anything, and you don't not have to say $foo->, so that part of your question is wrong.
Exporting is a feature. Like every other feature in any language, it can cause problems if you (ab)use it too frequently, or where you shouldn't. It's good when used wisely and bad otherwise, just like any other feature.
Back in the day when there weren't many modules around, it didn't seem like such a bad thing to export things by default. With 15,000 packages on CPAN, however, there are bound to be conflicts and that's unfortunate. However, fixing the modules now might break existing code. Whenever you make a poor interface choice and release it to the public, you're committed to it even if you don't like it.
So, it sucks, but that's the way it is, and there are ways around it.
The exporting package doesn't know if the using package already defined a symbol by the same name, and it certainly can't guarantee that it's the only package exporting a symbol by that name.
If you wanted to, I imagine your import() routine could check, but the default Exporter.pm routine doesn't check (and probably shouldn't, because it's going to get used a lot, and always checking if a name is defined will cause a major slowdown (and if you found a conflict, what is Exporter expected to do?)).
As far as I can see, the only reason to do this is laziness. You save some key strokes by not typing Foo:: or using an object interface, but is it really worth it?
Foo:: isn't so bad, but consider My::Company::Private::Special::Namespace:: - your code will look much cleaner if we just export a few things. Not everything can (or should) be in a top-level namespace.
The exporting mechanism should be used when it makes code cleaner. When namespaces collide, it shouldn't be used, because it obviously isn't making code cleaner, but otherwise I'm a fan of exporting things when requested.
It's not just laziness, and it's not just old modules. Take Moose, "the post-modern object system", and Rose::DB::Object, the object interface to a popular ORM. Both import the meta method into the useing package's symbol table in order to provide features in that module.
It's not really any different than the problem of multiply inheriting from modules that each provide a method of the same name, except that the order of your parentage would decide which version of that method would get called (or you could define your own overridden version that somehow manually folded the features of both parents together).
Personally I'd love to be able to combine Rose::DB::Object with Moose, but it's not that big a deal to work around: one can make a Moose-derived class that “has a” Rose::DB::Object-derived object within it, rather than one that “is a” (i.e., inherits from) Rose::DB::Object.
One of the beautiful things about Perl's "open" packages is that if you aren't crazy about the way a module author designed something, you can change it.
package LWPS;
require LWP::Simple;
for my $sub (#LWP::Simple::EXPORT, #LWP::Simple::EXPORT_OK) {
no strict 'refs';
*$sub = sub {shift; goto &{'LWP::Simple::' . $sub}};
}
package main;
my $page = LWPS->get('http://...');
of course in this case, LWP::Simple::get() would probably be better.
I'm investigating using DbC in our Perl projects, and I'm trying to find the best way to verify contracts in the source (e.g. checking pre/post conditions, invariants, etc.)
Class::Contract was written by Damian Conway and is now maintained by C. Garret Goebel, but it looks like it hasn't been touched in over 8 years.
It looks like what I want to use is Moose, as it seems as though it might offer functionality that could be used for DbC, but I was wondering if anyone had any resources (articles, etc.) on how to go about this, or if there are any helpful modules out there that I haven't been able to find.
Is anyone doing DbC with Perl? Should I just "jump in" to Moose and see what I can get it to do for me?
Moose gives you a lot of the tools (if not all the sugar) to do DbC. Specifically, you can use the before, after and around method hooks (here's some examples) to perform whatever assertions you might want to make on arguments and return values.
As an alternative to "roll your own DbC" you could use a module like MooseX::Method::Signatures or MooseX::Method to take care of validating parameters passed to a subroutine. These modules don't handle the "post" or "invariant" validations that DbC typically provides, however.
EDIT: Motivated by this question, I've hacked together MooseX::Contract and uploaded it to the CPAN. I'd be curious to get feedback on the API as I've never really used DbC first-hand.
Moose is an excellent oo system for perl, and I heartily recommend it for anyone coding objects in perl. You can specify "subtypes" for your class members that will be enforced when set by accessors or constructors (the same system can be used with the Moose::Methods package for functions). If you are coding more than one liners, use Moose;
As for doing DbC, well, might not be the best fit for perl5. It's going to be hard in a language that offers you very few guarantees. Personally, in a lot of dynamic languages, but especially perl, I tend to make my guiding philosophy DRY, and test-driven development.
I would also recommend using Moose.
However as an "alternative" take a look at Sub::Contract.
To quote the author....
Sub::Contract offers a pragmatic way to implement parts of the programming by contract paradigm in Perl.
Sub::Contract is not a design-by-contract framework.
Sub::Contract aims at making it very easy to constrain subroutines input arguments and return values in order to emulate strong typing at runtime.
If you don't need class invariants, I've found the following Perl Hacks book recommendation to be a good solution for some programs. See Smart::Comments.