Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
We are using Perl extensively in our project which is used to fetch the data from DB and install several components. Now we want to upgrade it to 5 from 4.2. I would like to know what changed and what are features that the latest Perl version has over 4.2. Someone please guide me to get this done.
Some things perl4 didn't have:
local (lexically scoped) variables
data structures (beyond simple arrays-of-scalars and hashes-of-scalars)
references (including references to subroutines, which let you abstract over behavior)
closures / first-class functions
OO: classes, methods, and objects
a module system, and a way to implement parts or all of a module in C, letting you bind to external libraries
CPAN: a central repository for modules written by other people for almost any task you can think of (current count: 188,959 modules)
pragmas that can warn you about or disable dangerous and questionable operations (use strict, use warnings)
Unicode support (in strings + all core operations; encoding layers in file handles)
subroutines that can be called like (most) builtins (& and parentheses not required, special calling conventions can be enabled by using "prototypes")
tie: a variable (scalar/array/hash) can be backed by an object; operations on the variable automatically invoke methods on the object instead
threads
overridable keywords
exception handling with die/eval {}
tons and tons of regex enhancements
... and hundreds of things I don't remember and can't list here. Seriously, perl5 is a very different language from perl4, even if many perl4 features are still there.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have been a searching for alternative to Moose (Modern object-oriented Perl)
Because Moose is slow I have seen several post relation to this issue, I not want that.
Example from the same creator: https://www.youtube.com/watch?v=ugEry1UWg84&feature=youtu.be&t=260
So I found this alternative from the same creator of moose:
https://metacpan.org/pod/MOP#DESCRIPTION
MOP - A Meta Object Protocol for Perl 5
This module implements a Meta Object Protocol for Perl 5 with minimal overhead and no non-core dependencies (eventually).
Work with UNIVERSAL::Object:
https://metacpan.org/pod/UNIVERSAL::Object
Is this a good choice and alternative to Moose, does someone test this software ?
Related post:
https://www.perlmonks.org/?node_id=1220917
Thanks.
Note: I forget to mention I know about Moo, Mouse, etc, maybe exist something better ?
MOP is very low level, Moxie is based on it; but it's still a proof of concept.
There are faster and lighter alternatives that have been tested in production: Moo and Mouse.
In which context do you use Moose and find it slow ? There is of course an overhead involved, but most of it happens at startup time (compilation) ; then, at runtime, most features are cheap (as long as you make your classes immutable), as explained in the documentation. Over the time Moose has become the de facto standard for object oriented programming and it has a very, very wide ecosystem (a search on MooseX on metacpan returns 820 results). Don't give up on it to early.
If you really need faster startup time (like in vanilla CGI environment for example), the most relevant alternative to Moose is Moo, Minimal Object Orientation. It is really light-weithg, has no XS dependency, while implementing a significant subset of Moose (also, its syntax is fully compatible with Moose so you upgrade to Moose anytime later if you need some piece of functionality that you find missing in Moo). It also has a rich ecosystem.
This question already has an answer here:
Using all variables in a module, except for one - is there an opposite of "only"?
(1 answer)
Closed 4 years ago.
I want to import everything in ISO_FORTRAN_ENV except for NUMERIC_STORAGE_SIZE, how can I do that?
Strictly you can't.
What you can do is rename NUMERIC_STORAGE_SIZE to something that is unlikely to be a problem for you in the scope of the USE statement.
USE :: ISO_FORTRAN_ENV, something_unlikely_to_be_a_problem => NUMERIC_STORAGE_SIZE
However, because ISO_FORTRAN_ENV is an intrinsic module that is not under your control, a common style recommendation is to go the other way - explicitly list the entities from that module in an only clause that you need to access. This avoids problems with future revisions of that module, either by updates to the standard or by the vendor of you Fortran processor, introducing identifiers that clash with existing local identifiers in the scope of the use statement.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
(The following is a kind of a "theoretical MCVE" of the kinds of complexity I'm encountering in organizing source code I'm working on. You can treat it as a concrete problem and that would be good, or you can refer to the general concerns it brings up and suggest how to address them.)
Suppose I have modules of code A, B, C and D. A depends on B,C,D; B depends on C; C, D don't depend on other modules. (I use the term "modules" loosely, so no nitpicking here please).
Additionally, in all of A,B,C,D, a few identical header files are used, and perhaps even a compiled object, and it doesn't make sense to put these together and form a fifth module because it would be too small and useless. Let's have foo.h be one of the files in that category.
While all of these modules are kept within a single monolithic code repository, all is good. There's exactly one copy of everything; no linker conflicts between objects compiled with the same functions etc.
The question is: How do I make each of B, C, D into a version-managed repository, so that:
Each of them can be built with only the presence of the modules it depends on (either as submodules/subrepositories or some other way); and
I do not need to make sure and manually maintain/update separate versions of the same files, or make carry-over commits from one library to the next (except perhaps changing the pointed-to revision); and
When everything is built together (i.e. when building A), the build does not involve qudaruple copies of foo.h and a double copy of C (once for A and once for B) - which I would probably always have to make sure and keep perfectly synchronized.
Note that when I have a bit more time I'll edit this to make the question more concrete (even though I kind of like the broad question). I will say that in my specific case the code is modern C++, CUDA, some bash scripts and CMake modules. So a Java-oriented solution would not do.
VERY BRIEFLY, you might want to explore an artifact repository (Artifactory) and dependency management solutions (Ivy, Maven, Gradle). Then as shared-base-module is built, you stick it in the artifact repo. When you want to build the top-modules that depend on shared-base-module; the build script simply pulls down the last version of shared-base-module and links/compiles top-module against what it pulled down .
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm pretty much a noob with Unity. As a c++ programmer, the naming conventions in Unity bothers me a little. And having OCD ontop of that makes me go crazy ;)
The objects has say a property Transform which again has a property Position.
But these properties must be accessed by writing transform.position in the code using lower case. This is not very intuitive to me. So I wonder how I can look at it in order to more easily avoid complications. And what conventions I should use to be able to tell everything appart by taking a quick look at the variables.
The Unity convention is actually rather simple: everything is Pascal-cased, types (classes, structs, enums) and methods start with upper-case, fields and properties with lower-case. Enum values in upper-case, constants in lower-case (usually).
So ClassName, MethodName, myField, myProperty { get; set; }, MyEnum.CaseA... that's it.
As for your example, Transform is a class, whereas transform is an accessor to the instance of Transform in that particular GameObject/Component.
Also, Transform doesn't have a Position property, it has a position property (always lower-case).
This is more or less based on C#'s conventions and the standard .NET library (MS has very precise guidelines about it), except standard .NET uses UpperCase for public/protected methods AND properties, and lower-case for private (again, usually; what's private is more left to the taste of the coder I think).
As a side-note, with any codebase, in any language, the best way is ALWAYS to follow the existing convention. Every seasoned programmer will tell you this. I understand about OCD, believe me, but in this case I suggest you let it go.
There are very little objective arguments as to why a convention would be better than another (by definition a convention is arbitrary), and even if there was, the absolute worse thing you can do is mix several conventions, because then you have 0 convention at all and never know what to expect.
At least C# tries to standardize; I've worked on several C++ codebases and I fail to see a common denominator: UpperCaseClassNames, lowerCaseClassNames, underscore_separated, tClassName, ENUMS_IN_UPPER, or not... it's rarely consistent, so the less you mix the better.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Among all the various incomplete lists of features going into Scala 2.10, there are various mentions of improvements to Scaladoc. But it's unclear which ones there are, and which ones are actually going in -- e.g. one of the lists of improvements says "fixes to Scaladoc" with links to various pull requests, some of which got rejected.
Can anyone summarize what's actually changed between Scala 2.9 and 2.10 milestone 4, and maybe indicate what else is planned for 2.10 itself?
Also, are they finally going to fix the problem of not being able to link to methods? E.g. littered throughout my code I have things like this:
/**
* Reverse the encoding computed using `encode_ngram`.
*/
def decode_ngram(ngram: String): Iterable[String] = {
DistDocument.decode_ngram_for_counts_field(ngram)
}
where I want to refer to another method in the same class, but AFAIK there's simply no way to do it. IMO it should be something obvious like [[encode_ngram]] -- i.e. I definitely shouldn't need to give an absolute class (which would make everything break as soon as I pull out a class and stick it somewhere else), and I shouldn't need to give the parameter types if the method name itself is unambiguous (i.e. non-polymorphic).
Several new features, as well as many bugfixes are coming, but there's no definitive list of all the fixes that are in, yet. Of the more notable new features:
Implicitly added members will now be visible. A good example is to look at scala.Array, where methods like map which you might've assumed you had are now visible in the Scaladoc.
Automatically-generated SVG inheritance diagrams, for a bird's eye view of relationships between classes/traits/objects at the package-level and then also at the level of individual classes etc. For example, see the Scaladoc diagrams nightly at both the package-level (click "Content Hierarchy") as well as at the class-level.
Method-linking in some limited form should go into 2.10 (not in the nightly yet). (It's actually not totally trivial to implement in its complete form, due to practical stuff like overloading, as you noted.)
Improved use cases A member with a use case isn't doubly generated anymore, and they're now a bit clearer and simpler than before.
(Less-notable) Keyboard shortcuts for navigating Scaladoc have been added, they're explained here and here
For a more exhaustive list of bugfixes, it might be a good idea to write to scala-internals-- there's a good chance someone will compile a list of all major bugfixes in the past year for you there.