I have a method that need return a Iterator. Then I defined a CustomIterator class inside that method and create instance of it as the return value.
It looks fine because only that method need to know about CustomIterator. But I'm afraid if this will produce too many Class instance as scala's type system is path-related.
Each class declaration will produce exactly one class file (that is, provided it does not contain inner classes or anonymous functions itself), so you shouldn't worry about that. Moreover, unless your program is supposed to run in a limited environment, additional classes won't cause any performance problems. In any case, you should profile your program before attempting such premature optimizations.
I'm not sure what you mean by "path-related type system". Is it path-dependent types? If so, this is a completely unrelated concept which exists in Scala type system only and does not affect actual class generation.
Related
In the documentation about Scala value classes, it is mentioned that there are three cases when a value class needs to actually be allocated an instance:
Allocation Summary
A value class is actually instantiated when:
a value class is treated as another type.
a value class is assigned to an array.
doing runtime type tests, such as pattern matching.
Is there a setting in the compiler or in the language features which would produce a warning when a value class needs to be instantiated?
No, not currently.
However, it is very rarely worth bothering with this kind of micro-optimisation.
If you have some very very hot code and you need to optimise it as far as possible then just try a few things and re-benchmark.
The JIT compiler will change what your code is doing at the machine level a lot of the time if the code is hot enough.
The overhead of allocating a value class is often not even measurable unless it is the only thing the thread is doing. See e.g. https://groups.google.com/forum/#!topic/scala-user/XdQnbcs2SRM for some benchmarks where value class allocation is not measurable.
In this video from Google IO 2009, the presenter very quickly says that signatures of methods should return concrete types instead of interfaces.
From what I heard in the video, this has something to do with the GWT Java-to-Javascript compiler.
What's the reason behind this choice ?
What does the interface in the method signature do to the compiler ?
What methods can return interfaces instead of concrete types, and which are better off returning concrete instances ?
This has to do with the gwt-compiler, as you say correctly. EDIT: However, as Daniel noted in a comment below, this does not apply to the gwt-compiler in general but only when using GWT-RPC.
If you declare List instead of ArrayList as the return type, the gwt-compiler will include the complete List-hierarchy (i.e. all types implementing List) in your compiled code. If you use ArrayList, the compiler will only need to include the ArrayList hierarchy (i.e. all types implementing ArrayList -- which usually is just ArrayList itself). Using an interface instead of a concrete class you will pay a penalty in terms of compile time and in the size of your generated code (and thus the amount of code each user has to download when running your app).
You were also asking for the reason: If you use the interface (instead of a concrete class) the compiler does not know at compile time which implementations of these interfaces are going to be used. Thus, it includes all possible implementations.
Regarding your last question: all methods CAN be declared to return interface (that is what you ment, right?). However, the above penalty applies.
And by the way: As I understand it, this problem is not restricted to methods. It applies to all type declarations: variables, parameters. Whenever you use an interface to declare something, the compiler will include the complete hierarchy of sub-interfaces and implementing classes. (So obviously if you declare your own interface with only one or two implementing classes then you are not incurring a big penalty. That is how I use interfaces in GWT.)
In short: use concrete classes whenever possible.
(Small suggestion: it would help if you gave the time stamp when you refer to a video.)
This and other performance tips were presented at Google IO 2011 - High-performance GWT.
At about the 7 min point the speak addresses 'RPC Type Explosion':
For some reason I thought the GWT compiler would optimize it away again but it appears I was mistaken.
in scala i need to implement something similar to python metaclasses. in my case the goal of using the metaclasses is usually to create a registry of all the subclasses of a particular base class - that is, a mapping from say a string representation of the class to a reference to the class. in python it's very convenient to put a metaclass on the base class so that nothing special needs to be done on every subclass. i'm looking to do something similar in scala. is there any way to emulate metaclasses, or otherwise do this a different way? thanks!
If you know the fully qualified name of the class, you can load it using the usual Java reflection methods in java.lang.Class, namely Class.forName(String fqClassName). Given the resulting instance of Class, instantiation is easy only if there's a zero-argument constructor, otherwise you get entangled in the messy world of all the Java reflection types.
If you want a kind of "discovery" where classes unknown at compile time and whose names are not supplied as an input or parameter of the program in some way, then the classloader approach is probably the only answer.
There's nothing similar to python's metaclasses. The registry you speak of might be possible using custom class loaders or reflection.
If I have a function (say messUp that does not need to access any private variables of a class (say room), should I write the function inside the class like room.messUp() or outside of it like messUp(room)? It seems the second version reads better to me.
There's a tradeoff involved here. Using a member function lets you:
Override the implementation in derived classes, so that messing up a kitchen could involve trashing the cupboards even if no cupboards are available in a generic room.
Decide that you need to access private variables later on, without having to refactor all the code that uses the function.
Make the function part of an interface, so that a piece of code may require that its argument be mess-up-able.
Using an external function lets you:
Make that function generic, so that you may apply it to rooms, warehouses and oil rigs equally (if they provide the member functions required for messing up).
Keep the class signature small, so that creating mock versions for unit testing (or different implementations) becomes easier.
Change the class implementation without having to examine the code for that function.
There's no real way to have your cake and eat it too, so you have to make choices. A common OO decision is to make everything a method (unless clearly idiotic) and sacrifice the three latter points, but that doesn't mean you should do it in all situations.
Any behaviour of a class of objects should be written as an instance method.
So room.messUp() is the OO way to do this.
Whether messUp has to access any private members of the class or not, is irrelevant, the fact that it's a behaviour of the room, suggests that it's an instance method, as would be cleanUp or paint, etc...
Ignoring which language, I think my first question is if messUp is related to any other functions. If you have a group of related functions, I would tend to stick them in a class.
If they don't access any class variables then you can make them static. This way, they can be called without needing to create an instance of the class.
Beyond that, I would look to the language. In some languages, every function must be a method of some class.
In the end, I don't think it makes a big difference. OOP is simply a way to help organize your application's data and logic. If you embrace it, then you would choose room.messUp() over messUp(room).
i base myself on "C++ Coding Standards: 101 Rules, Guidelines, And Best Practices" by Sutter and Alexandrescu, and also Bob Martin's SOLID. I agree with them on this point of course ;-).
If the message/function doesnt interract so much with your class, you should make it a standard ordinary function taking your class object as argument.
You should not polute your class with behaviours that are not intimately related to it.
This is to repect the Single Responsibility Principle: Your class should remain simple, aiming at the most precise goal.
However, if you think your message/function is intimately related to your object guts, then you should include it as a member function of your class.
I have seen member functions programed both inside of the class they belong to and outside of the class with a function prototype inside of the class. I have only ever programmed using the first method, but was wondering if it is better practice to use the other or just personal preference?
Assuming you mean C++, it is always better to define functions outside of the class, because if you put it inside the class, compiler may try to inline it, which is not always desirable:
Increase in code size (every object file that includes this header might end up with a copy of the function in their code).
Breaking binary compatibility when function definition changes.
Even with inline functions, it is usually better to put definitions outside the class to improve readability of class public interface, unless the function is a trivial accessor or some other one-liner.
For C++, putting method definitions in the header file means that everything that includes a given header must be recompiled when the header changes - even if it's just an implementation detail.
Moving definitions out of the header means that files which include the header will need to be recompiled only when the header itself changes (functions added/removed, or declarations changed). This can have a big impact on compile times for complex projects.
There's advantages to both techniques.
If you place only prototypes in the class definition, that makes it easier for someone who is using your class to see what methods are available. They aren't distracted by implementation details.
Putting the code directly in the class definition makes it simpler to use the class, you only have to #include a header. This is especially useful (necessary) with templated classes.
Presuming the language is C++:
The bottom line is that is personal preference. Inside the class is shorter overall and more direct, especially for the
int getFoo() const { return _foo; }
type of function.
Outside te class, can remove "clutter" from the class definition.
I have seen both in use...
Of course, non-inlined functions are always outside the class.
It is also common to mix both styles when defining a class. For simple methods consisting of 1 or 2 lines it is common and convenient to define the method body within the class definition. For more lengthy methods it is better to define these externally. You will have more readable class definitions without cluttering them up with the method body.
Hiding the implementation of a method is beneficial in that the user of the class will not be distracted by the actual implementation, or make assumptions about the implementation that might change at a later time.
I assume you are talking about C++.
Having a nice and clean interface is certainly a good idea. Having a separate implementation file helps to keep your interface clean.
It also reduces compilation time, especially if you are using an opaque pointer.
If you implement the function inside the class, you cannot #include the class in multiple .cpp files or the linker will complain about multiple definitions of the function.
Thus, usual practice is to have the class definition in a .h file and the members implementation in a .cpp file (usually with the same name).
Again, assiming C++, I usually restrict this to placeholders on virtual functions, e.g.
virtual int MyFunc() {} // Does nothing in base class, override if needed
Anything else, and Andrew Medico's point kicks in too easily and hurts compile times.