I am pretty happy with bit.dev. But there is one point I am not getting to work.
I need some global functions like formatting currency or saving same constants and enums, that I want to use from different components.
One way would be to add the code to every single component, but that would be just code duplication. The other way could be to create a component with just constants or helper functions, but I don't know whether bit is designed for that way.
Is there some best practice how I could solve that problem?
best regarts!
I work at Bit. In Bit, we solved it by having a scope for utilities functions, which we named toolbox.
Inside that scope, you can publish each of your functions as a nodeJS component. You can give it a look here to our Toolbox
Inside of it, we created several namespaces. We have one for strings, arrays, filesystem, and many others.
The principle is the same as you have been working so far: create your component, export it, and import it to any project you may need.
Let me know if that helped
Related
In Go, public names start with an upper case letter and private names start with a lower case letter.
I'm writing a program that is not library and is a single package. Is there any Go idiom that stipulates whether my identifiers should be all public or all private? I do not plan on using this package as a library or as something that should be imported from another Go program.
I can't think of any reason why I'd want a mixture. It "feels" like going all private is the proper choice.
I don't think I got any concrete answer, but Nate was closest with telling me to think of "exporting vs non-exporting" instead of "public and private".
This leads me to believe that not exporting anything is the best approach. In the worst case scenario, if I end up importing code from my application in another package, I will have to rethink what should be exported and what shouldn't be. Which is a good thing IMO.
If you are attempting to adjust your mindset to be more Go idiomatic, you should stop thinking of variables, functions, and methods as public or private. The more accurate term is exported or not exported. It definitely has a more C like feel to it.
As others have stated exporting really isn't needed for application program code. If for organizational reasons you decide to break your program up into packages, you could use sub-packages. At work we've decided to do just this. We have:
projectgopath/src/projectname
projectname/subcomponent1
projectname/subcomponent2
So far I am really liking this structure. It aids in separation of concerns, but does not go to the extent of making a package outside of the main project. The intent is clear. The sub-package's intended use is for this program only...
The new go build and go install commands seem to deal very well with it. We group components together in packages and expose only the necessary bits via exports.
In the described situation both approaches are equally valid, so it's more or less a matter of personal preferences. In my case I'm using camelCase identifiers for package main, mostly out of habit.
A lot of my go files started their life in isolated commands and were moved to packages as they could be reused by a few commands around the same topic.
I think you should make private all that couldn't possibly be called from elsewhere (supposing one day you make it an importable package) and make public the big functions that can be understood from elsewhere (if any) and structs fields when they are orthogonal (I mean when a change of the value of one field doesn't break the consistency of the struct value).
i'm currently working on a big projekt and i loose many time searching the right thing in the code. i need to get e.g. a method which makes someting special. so i scroll the whole code.
are there any common and effective methods to struct a file of code? e.g.
1. all global variables
2. constructor etc.
3. all methods
4. all event handlers
do you know common methods to do this??
It's more usual to break large projects into several source files, with logically related functionality. This helps with speeding up compilation and reducing coupling in your design as well as helping you navigate the code.
An example might be to have separate files for
UI functionality
helper classes (such as geometric/maths stuff)
file I/O
core functionality that connects the rest together
Design is a large topic, the book Code Complete by Steve McConnell might be a good starting point for you.
You shouldnt use global variables :)
Try spreading things out over different classes and files. Maks sure each class has only one purpose, instead of 1 class that manages a whole lot of different tasks.
That sounds like a sensible enough structure to me, what would really benefit you though is learning to use the tools you have available — whatever editor you're using it will have a search function, you can use that to quickly find what you're looking for.
Some editors will also include bookmarks too, and most offer a way to move back and forward through recent positions in the file.
Seen this sort of things started, never seen it kept on under the pressure to turn out code though.
Basically my rule of thumb is, if I feel the need to do this, break the code file up.
I am working on a project build on the Zend Framework. I'm using Zend_Translate to do my translations, but I want to keep the amount of extra code in the front of my application (views) as minimal as possible. Translation of a text should look like this:
echo __("Text to translate");
Using a view helper isn't doing it, because then I get:
echo $this->__("Text to translate");
This would mean I have to declare a global function somewhere, that calls for Zend_Translate to do the rest of the magic. Because I want the project to stay as clean as possible I'd like some suggestions on where to put this function.
I have considered including a file with my global function inside of the _initLocale() in the bootstrap.
Basically my question is: am I now violating all the holy MVC principles, or is this the right way to go?
This is actually not an easy question to answer. Of course you're violating some principles of OOP because you're basically punctuating your objects with hundreds of little wholes where there should be just one. You should be injecting the translation object into your controllers and views once and then call $this->__(). This is also easily done by creating an intermediate layer between Zend_Controller_Action and your own controllers. BUT... translation is a very specific case and I don't see much potential harm coming from your solution. The Translation method is not likely to change its logics and if you need to rename it, finding and replacing two underscores followed by a bracket will most probably not yield anything else than translated strings... then again that use of 'most probably' is a smell already.
Summary: It seems more or less ok but I still wouldn't do it, especially if it's a software of some meaning with an expected life span of some years.
In response to a previous question on how to achieve a certain effect with Swing, I was directed to JDesktopPane and JInternalFrame. Unfortunately, scala.swing doesn't seem to have any wrapper for either class, so I'm left with extending it.
What do I have to know and do to make minimally usable wrappers for these classes, to be used with and by scala.swing, and what would be the additional steps to make most of them?
Edit:
As suggested by someone, let me explain the effect I intend to achieve. My program controls (personal) lottery bets. So I have a number of different tickets, each of which can have a number of different bets, and varying validities.
The idea is displaying each of these tickets in a separate "space", and the JInternalFrames seems to be just what I want, and letting people create new tickets, load them from files, save them to files, and generally checking or editing the information in each.
Besides that, there needs to be a space to display the lottery results, and I intend to evolve the program to be able to control collective bets -- who contributed with how much, and how any winning should be split. I haven't considered the interface for that yet.
Please note that:
I can't "just use" the Java classes, and still take full advantage of Scala swing features. The answers in the previous question already tell me how to do what I want with the Java classes, and that is not what I'm asking here.
Reading the source code of existing scala.swing classes to learn how to do it is the work I'm trying to avoid with this question.
You might consider Scala's "implicit conversions" mechanism. You could do something like this:
implicit def enrichJInternalFrame(ji : JInternalFrame) =
new RichJInternalFrame(ji)
You now define a class RichJInternalFrame() which takes a JInternalFrame, and has whatever methods you'd like to extend JInternalFrame with, eg:
class RichJInternalFrame(wrapped : JInternalFrame) {
def showThis = {
wrapped.show()
}
}
This creates a new method showThis which just calls show on the JInternalFrame. You could now call this method on a JInternalFrame:
val jif = new JInternalFrame()
println(jif.showThis);
Scala will automatically convert jif into a RichJInternalFrame and let you call this method on it.
You can import all java libraries directly into your scala code.
Try the scala tutorial section: "interaction with Java".
Java in scala
You might be be able to use the scala.swing source as reference e.g. http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/swing/scala/swing/Button.scala
What sort of scala features are you trying to use with it? That might help in coming up with with an answer. I.e. - what is it you're trying to do with it, potentially in Java? Then we can try to come up with a nicer way to do it with Scala and/or create a wrapper for the classes which would make what you're trying to do even easier.
In JRuby, you could mix in one (or more) traits into JDesktopPane or JInternalFrame instead of extending them. This way you wouldn't have to wrap the classes but just use the existing objects. As far as I know, this is not possible with Scala traits.
Luckily, there is a solution, almost as flexible as Ruby's: lexically open classes. This blog article gives an excellent introduction, IMHO.
For example, referencing something as System.Data.Datagrid as opposed to just Datagrid. Please provide examples and explanation. Thanks.
The benefit is that you don't need to add an import for everything you use, especially if it's the only thing you use from a particular namespace, it also prevents collisions.
The downside, of course, is that the code balloons out in size and gets harder to read the more you use specific qualifiers.
Personally I tend to use imports for most things unless I know for sure I will only be using something from a particular namespace once or twice, so it won't impact the readability of my code.
You're being very explicit about the type you're referencing, and that is a benefit. Although, in the very same process you're giving up code clarity, which clearly is a downside in my case, as I want code to be readable and understandable. I go for the short version unless I have a conflict in different namespaces which can only be solved with the explicit referencing to classes.. Unless I make an alias for it with the keyword using:
using Datagrid = System.Data.Datagrid;
Actually the full path is global::System.Data.DataGrid. The point of using a more qualified path is to avoid having to use additional using statements, especially if the introduction of another using will cause problems with type resolution. More fully qualified identifiers exist so that you can be explicit when you need to be explicit, but if the class's namespace is clear, then the DataGrid version is clearer to many.
I generally use the shortest form available in order to keep the code as clean and readable as possible. That's what using directives are for, after all, and tooltips in the VS editor give you instant detail on the provenance of a type.
I also tend to use a namespace tag for RCWs in a COM interop layer, to call out those variables explicitly in the code (they may need special attention on lifecycle and collection), eg
using _Interop = Some.Interop.Namespace;
In terms of performance there is no upside/downside. Everything is resolved at compile time and the generated MSIL is identical whether you use fully-qualified names or not.
The reason why its use is prevalent in the .NET world is because of auto-generated code, such as designer markup. In that case it would be better to fully-qualify names like class names because of possible conflicts with other classes you may have in your code.
If you have a tool like ReSharper, it will actually tell you what fully-qualified references you have are unnecessary (e.g. by graying them out) so you can lop them off. If you frequently cut-paste code across your various code bases, it would be a must to fully qualify them. (then again, why would you want to do cut-paste all the time; it's a bad form of code reuse!)
I don't think there is really a downside, just readability vs actual time spent coding. In general if you don't have namespaces with ambiguous object I don't think it's really needed. Another thing to consider is level of use. If you have one method that uses reflection and you are alright with typeing System.Reflection 10 times, then it's not a big deal but if you plan on using a namespace alot then I would recommend an include.
Depending on your situation, extra qualifiers will generate a warning (if this is what you mean by redundant). If you then treat warnings as errors, that's a pretty serious downside.
I've run into this with GCC for example.
struct A {
int A::b; // warning!
}