Readit Newshttps://slatestarcodex.com/2020/06/01/book-review-origin-of-...
Object-orientation is about grouping together functionality and data. I.e., an object consists of both a struct, and the functions that act on that struct, known as methods.
In OO, your type additionally refers to the functions called on the data, not just on the data. E.g. you might have a car and a boat and they both only have a position and velocity as data, but the boat has a "sink" method the car doesn't.
There are also debates on what qualifies as "true" object orientation. https://stackoverflow.com/questions/250062/what-is-meant-by-...
For games programming in particular, there is a paradigm known as ECS or Entity Component System. (Depending on your view you might call this a sub-paradigm of object orientation, but I think it's much more accurately described as an alternative.) As the Wikipedia article states:
> An entity only consists of an ID and a container of components. The idea is to have no game methods embedded in the entity.
https://en.wikipedia.org/wiki/Entity_component_system
EDIT: There's also the very interesting paradigm that e.g. Julia uses known as "Multiple Dispatch". This is kind of like defining methods on objects, except that the method is defined on a collection of objects instead of a single one.
E.g., in traditional OO, you might have a vehicle#crash method. And it might take another vehicle as argument, e.g. car.crash(truck). But in multiple dispatch you define a function crash that takes in two vehicles, and then depending on the type of the vehicles given, it changes its behaviour so that crash(car, truck) is different from crash(car, car).
In a sense, the function is not thought of as belonging to either the car or the truck, but as belonging to the pair of them, so conceptually this is different to OO.
I'm not particularly familiar with the paradigm so I'm sure I'm not doing it justice, but you can read further on Wikipedia and in the Julia docs, or the given video:
https://en.wikipedia.org/wiki/Multiple_dispatch
https://docs.julialang.org/en/v1/manual/methods/index.html#M...
To support backwards-compatibility, Java could not simply introduce functions as first-class objects. Instead, it works like follows:
Syntax for a function `foo` which itself takes in a function called `intConcat` that takes in two ints and spits out string:
foo(BiFunction<Integer, Integer, String> intConcat) {
// ...
}
Java then just adds some nice syntactic sugar to make stuff look like functions. E.g., if you do want to define an anonymous lambda like
(x,y) -> "" + x + y;
BiFunction<Integer, Integer, String> bif = (x, y) -> "" + x + y;
BiFunction<Integer, Integer, String> {
String apply(Integer x, Integer y) {
return "" + x + y;
}
// ...
}
Like I said, a very object-oriented approach to functionality.
In stock first, out of stock second.
It could potentially mean one of:
- Computer Simulation
- Pen & Paper Mathematical models
- Pen & Paper narrative modelling (i.e., writing a paper about different situations and the possible contingency plans - though granted this is not usually referred to as "simulation")
- Role-playing a situation via speech
- Acting out a situation with props and physical movement / simulated limited communication
- Sending out simulated broadcasts ("this is only a test")
- Sending out false but believable broadcasts
- Infecting the public with a (hopefully less harmful) disease in order to gauge response.
This site has more info:
http://www.upmc-biosecurity.org/website/events/2001_darkwint...
http://www.upmc-biosecurity.org/website/events/2001_darkwint...
A better name for "the speed of light" might actually be "the speed of time" or "the speed of information transfer".
It's a mathematical limit and you can derive it using pretty much anything, not just light.
As an object goes faster, it experiences time dilation, length contraction, etc. The "Speed of Light" C is basically the point at which all of these things reach either zero or infinity.
It also "just so happens" that electromagnetic waves (such as light) travel at exactly this speed in a vacuum. They travel that fast because they travel at the maximum possible speed, and that happens to be the maximum possible speed.
It's like if you always traveled at the speed limit because you didn't want to break the law, and we called it "triplesex_ speed", but really it's just the maximum speed that anyone would go if they didn't want to break the law.
Except in this case it's not just a law- it is (to the best of our knowledge) physically impossible to go faster. It's not just that we haven't seen anything go that fast- it's that going faster than that doesn't even really make sense theoretically - for example, it would result in time-travel (this has to do with the fact that the order in which events happen and the speed at which time passes is different to different observers depending on the speed at which you're traveling).
- "severity" as level of importance the tester assigned it when they found the bug and - "priority" as level of importance a developer assigned to it after triage.
That first piece of information is important when you need to determine which bugs to look at first for triage, but how important is it after that point? Can it not just be replaced after the developer's judgement?
In other words, could you not have a single priority field? The tester uses a heuristic to assign an initial priority (e.g., crashes are P0, cosmetic are P4). The dev uses this to prioritize which bugs to triage first, and once they've determined a new priority based on customer experience combined with app behaviour, they replace the old one.
If you really need to go back and check what the tester assigned, then I assume you can just use the "history" or "revision" feature in your bug tracking app.
Additionally, as suggested in a different comment, you can add a label for the bug's type if you feel that's important (crashing, lagging, cosmetic, etc.).
Perhaps the message here is that the app's behaviour in a vacuum is not the sole determinant of its priority. But then that should be the message, rather than claiming there is another metric which needs to be separately tracked when evaluating bugs.
Apps like Instagram have a standard carousel for photo albums and people use them and can trust the functionality.
But most websites have varying implementations of carousels, with weird functionality (autoplay, transitions, no-swipe, randomized). Users get confused by each implementation and eventually just ignore them...
Yeah, but that only applies to users who are used to Instagram. It's definitely not an INTUITIVE feature.
I've had friends and family link me to Instagram posts, and though I've learned now, for a long time they'd have to explicitly mention there were additional pictures in the post, or I'd miss them.
(I don't know if it's different in the app, but certainly in the webpage those little dots at the bottom are non-obvious to a first-time user.)