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 8 years ago.
Improve this question
Can anyone list out the immutable objects in Ruby..
I saw Ruby - Immutable Objects this and I know about how to convert mutable objects into immutable objects but no clarity on immutable objects in ruby.
It's been my experience that you have two choices:
Aggressively freeze any objects, and this means deep freeze where you not only freeze the main object but any contained objects, in order to prevent modification.
Be disciplined about not modifying the objects in certain sections of your code.
The second approach is what most applications use because once frozen there's no way to un-freeze something. Objective-C has mutable and non-mutable variants of many objects, C++ has const that can prevent modification of any object, but there's no such thing in Ruby.
This is largely because Ruby methods are free to do whatever they want with very little in the way of constraints. Can a reader method modify the state of the object? Yes. You might have a very good reason for doing this and Ruby won't get in your way.
If you're writing code that depends on objects being in a non-changing state, make a copy, freeze it, and use that for reference. This will probably slow down and complicate your application considerably, so it's a very heavy handed approach.
The best method is to share as little information as is necessary, provide interfaces to this information that are read-only by design, and avoid tampering with things outside of specific circumstances by employing proper locking measures.
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 7 years ago.
Improve this question
Ruby has support for the for i in a syntax, but no one really uses it. One of the design principles of Ruby is it's readability, and I find
for i in a
...
end
much more readable (and easier to type) than
a.each do |i|
...
end
Why is it not preferred? Do others not also find it more readable? Is it for consistency reasons, e.g., relation with other functions like each_with_index and variable scoping?
For me, it's uniform syntax. When I am going to do something with array a, I just start typing a.. What am I going to do? Filter? a.select; determine the size? a.size. Iterate? a.each etc.
Iterating an array is nothing special and requires no special language construct. Also eachwithout an immediate block results in an Enumerator, which can be chained with other methods.
Then again, Ruby does have a fine for i in a loop. So if you are more comfortable with a for loop: by all means, use a for loop.
Because for loop is less objective and more limited in use.
From the OOP point of view, possibility of iterating through elements of an object is a property/characteristic of that object. Using explicit "outer" way either with a global function or a keywords find redundant, inconsistent and less objective (encapsulation).
for is also more limited, it allows only iterate through object elements. Enumerator#each on the other hand allows you much more. You may play with enumerator object like chaining with other methods before values unpacking, passing named blocks, methods converted to procs etc.
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
while browsing for a contains method, I came across the following Q&A
contains-method-for-a-slice
It is said time and again in this Q&A that the method is really trivial to implement. What I don't understand is, if it were so easy to implement, and seeing how DRY is a popular software principle && and most modern languages implement said method , what sort of design reasoning could be involved behind the exclusion of such a simple method?
The triviality of the implementation depends on the scope of the implementation. It is trivial to implement when you know how to compare each value. Application code usually knows how to compare the types used in that application. But it is not trivial to implement in the general case for arbitrary types, and that is the situation for the language and standard library.
Figuring out if a slice contains a certain object is an O(n) operation where n is the length of the slice. This would not change if the language provided a function to do this. If your code relies on frequently checking if a slice contains a certain value, you should reevaluate your choice of data structures; a map is usually better in these kind of cases. Why should the standard library include functions that encourage you to use the wrong data structure for the task you have?
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
The sense I get about this idiom is that it is useful because it ensures that resources are released after the object that uses them goes out of scope.
In other words, it's more about de-acquisition and de-initialisation, so why is this idiom named the way it is?
First, I should note that it's widely considered a poorly named idiom. Many people prefer SBRM, which stands for Stack Bound Resource Management. Although I (grudgingly) go along with using "RAII" simply because it's widely known and used, I do think SBRM gives a much better description of the real intent.
Second, when RAII was new, it applied as much to the acquisition as releasing of resources. In particular, at the time it was fairly common to see initialization happen in two steps. You'd first define an object, and only afterwards dynamically allocate any resources associated with that object. Many style guides advocated this, largely because at that time (before C++ had exception handling) there was no good way to deal with failure in a constructor. Therefore, the style guides often said, constructors should do only the bare minimum of work, and specifically avoid anything that was open to failure -- especially allocating resources (and a few still say things like that).
Quite a few of those already handled releasing the resources in the destructor though, so that wouldn't have been as clear a distinction from previous practice.
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 6 years ago.
Improve this question
This is a general question that comes to answer an issue that interests me for general knowledge and not to answer a specific problem.
I was wondering what are the available ways to implement a physical engine where objects interact with each other and with outside forces. As an example we can look at Angry Birds, or games like TIM. Where there are objects that "fly" through the air, collide and interact with each other, and are affected by the potential of the environment like gravity, winds and other "forces".
The model that I have thought about is that each object has an object (as an object of some class) and a thread that relate to it. Each time slot the thread get it "advances" the object in the space for some small dt. In this case you could have an "environment" object that can get a position in space and give you the equivalent force that is applied by the environment potential. What I can't exactly get is how the objects interact with each other?
Also, am I close in my direction? Are there other solutions and models for those problems, and are they better? What are the things I'm missing (I must be missing some things)?
the implementation is typically nothing like you describe, which is way too expensive. instead, everything is reduced to matrix transformations. points are lists of coordinates that are operated on by matrices that update them to the next time interval. the matrices are themselves calculated from the physics (they are a linear solution of the forces at that moment, more or less).
things get more complicated when you have very large differences in scale (say, for simulating stars in a galaxy). then you may use a more hierarchical approach so that critical (eg fast moving or, more accurately, strongly accelerating) points are updated more often than non-critical points. but even then the in-memory representation is very abstract and nothing like as direct as "one object per thing".
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Is that worth to learn LINQ for hobbyists or the professionals (who are free from formal job requirement)? We can achieve the same thing that LINQ does via traditional language functionality such as loop, array, etc.
Why bother to duplicate the way to achieve the same objective?
I find LINQ tends to let you focus more on intent. In other words, what is the code doing rather than how is the code doing it. Or to put it yet another way, it's more of a declarative form of programming (like functional programming) rather than imperative programming style.
I've found using LINQ to be very beneficial, from the standpoint that I don't have to write the for loop to iterate over a collection and perform some operation. Rather, I can use a single line LINQ statement to do that for me.
One simple example could be someCollection.OrderBy(c => c.propertyOne); Doing that on your own would take a bit more code.
LINQ isn't so much something you need to learn, it's just something that you probably just will learn. It's now just part of the framework along with some cool additional syntax. If you aim to write clean, maintainable code then you will no doubt want to write code which leverages LINQ extensions.
Apart from the syntactic sugar of "from ... select ... where" in C#, you'll find that LINQ is leveraging other bits of the framework/languages anyway - that is, extension methods, enumerators, lambda expressions, and delegates. All of these are increasingly hard to avoid anyway.
When it comes to using frameworks that provide their own LINQ proimplementations, for example, Entity Framework or LINQ-to-SQL, then that's another story. I would learn those based on requirements. In your case, if your side-project needs some DB CRUD stuff then you might look at either of those.