![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
learned something
Mar. 24th, 2019 07:32 pmif your class is not a function of its constructor parameters (like, e.g., case class is), don't introduce these parameters at all. Make them members. Use a factory to build your class.
Then you can turn them into traits, and compose them freely. That's just one advantage.
The other advantage is that you won't need to reassign parameter values to members that are already declared in traits.
In short, careful with constructors. You may not need them. Scala is not C++, you know.
еще решение про обращение списка
Jun. 9th, 2018 11:15 pmПредположим, что список двунаправленный.
Меняем два пойнтера.
Mission accomplished (цитируя Дабью Буша)
Меняем два пойнтера.
Mission accomplished (цитируя Дабью Буша)
Theory of Objects
Nov. 3rd, 2016 11:42 amon one page
1. Idea
The theory of objects is the logical theory whose models in a category 𝒞 are precisely the objects of 𝒞.
2. Definition
The theory of objects 𝕆 is the theory with no axioms over the signature with a single type and no primitive symbols except equality.
===================
The classifying topos 𝒮[𝕆] for the theory of objects 𝕆, or the object classifier, as it is also called, is the presheaf topos [FinSet,Set] on the opposite category of FinSet.
What motivates the terminology, is that for any topos E, geometric morphisms E→𝒮[𝕆] correspond to objects of E.
1. Idea
The theory of objects is the logical theory whose models in a category 𝒞 are precisely the objects of 𝒞.
2. Definition
The theory of objects 𝕆 is the theory with no axioms over the signature with a single type and no primitive symbols except equality.
===================
The classifying topos 𝒮[𝕆] for the theory of objects 𝕆, or the object classifier, as it is also called, is the presheaf topos [FinSet,Set] on the opposite category of FinSet.
What motivates the terminology, is that for any topos E, geometric morphisms E→𝒮[𝕆] correspond to objects of E.
array bounds checking
Feb. 5th, 2016 09:54 amSo, I just bumped into this problem being mentioned. "For performance", bounds are not being checked by c programmers, who mostly don't care about any cases except the ones they like.
But well, what's the point in these checkings?
I know three cases.
1. We know during compile time the size of the vector we need, and we should not accept the smaller ones; we should rather not accept the larger ones, but mostly we don't care. This is the case for tuples. It's not an array. If someone wants to pass into the code an array pretending to be a tuple, this fact should be checked at the border. Ok, yes, there are no tuples in C or C++. Well, bad luck, and say hi to the threemorons interesting people that provided you with such a language.
2. We don't specify the size, but we have some constraints, like the height of one matrix should be equal to the width of another; or maybe that a vector must contain not less than so many members. Ok, why not have it all in a specialized class? Once the class is instantiated (optionally, with all the checks), there's no way the sizes will change, right? So we don't have to check the bounds.
3. A loose collection of ancient libraries with loose, frequently unknown, requirements. I guess these libraries should be wrapped and hidden from the eyes of a modern human. It's like a slaughterhouse, hardly any modern city dweller wants to see what's going on there.
But well, what's the point in these checkings?
I know three cases.
1. We know during compile time the size of the vector we need, and we should not accept the smaller ones; we should rather not accept the larger ones, but mostly we don't care. This is the case for tuples. It's not an array. If someone wants to pass into the code an array pretending to be a tuple, this fact should be checked at the border. Ok, yes, there are no tuples in C or C++. Well, bad luck, and say hi to the three
2. We don't specify the size, but we have some constraints, like the height of one matrix should be equal to the width of another; or maybe that a vector must contain not less than so many members. Ok, why not have it all in a specialized class? Once the class is instantiated (optionally, with all the checks), there's no way the sizes will change, right? So we don't have to check the bounds.
3. A loose collection of ancient libraries with loose, frequently unknown, requirements. I guess these libraries should be wrapped and hidden from the eyes of a modern human. It's like a slaughterhouse, hardly any modern city dweller wants to see what's going on there.
...is that nobody cares whether subtyping is monomorphic.
I mean, if we only say that A is a subtype of B when we have a canonical inclusion A ↣ B, many things would make more sense.
But for some reason, any canonical function A → B is accepted as a subtyping relationship, and I wonder why. Or rather not, I don't. Liskov etc. Projections.
I mean, if we only say that A is a subtype of B when we have a canonical inclusion A ↣ B, many things would make more sense.
But for some reason, any canonical function A → B is accepted as a subtyping relationship, and I wonder why. Or rather not, I don't. Liskov etc. Projections.
Every time you write
you are introducing an algebra over
Even if you have no clue what an algebra or a monad is.
Same goes for catching exceptions and returning a "default value". Now you have a category of algebras over the exception monad.
This category is called Eilenberg-Moore category for the monad. There's a couple of adjunctions of course.
Kleisli also provides a couple of adjunctions.
All possible adjunctions make a category, where Kleisli is an initial object and Eilenberg-Moore is a terminal object.
Nlab says that Kleisli can actually be embedded into Eilenberg-Moore.
Meaning, guys, you don't need to invent "default values"; just use Option[T]. Whatever. Probably hard to explain to people that are thinking in terms of saving computer memory on string instantiation.
val myName = props.get("Name") orElse ""you are introducing an algebra over
Option monad.Even if you have no clue what an algebra or a monad is.
Same goes for catching exceptions and returning a "default value". Now you have a category of algebras over the exception monad.
This category is called Eilenberg-Moore category for the monad. There's a couple of adjunctions of course.
Kleisli also provides a couple of adjunctions.
All possible adjunctions make a category, where Kleisli is an initial object and Eilenberg-Moore is a terminal object.
Nlab says that Kleisli can actually be embedded into Eilenberg-Moore.
Meaning, guys, you don't need to invent "default values"; just use Option[T]. Whatever. Probably hard to explain to people that are thinking in terms of saving computer memory on string instantiation.
apple swift
Jun. 2nd, 2014 04:22 pmSo, with the new "Apple language", object-oriented Java people are going to do what?
There must be some deep philosophy, explaining why they are so retarded.
I think.
I mean, I kind of heard an explanation from Josh; in my translation it sounds like this: "Java programmers are not very smart anyway, let's not overload them with closures and all that stuff."
The correlation I was writing about lately kind of shows itself again.
Weird.
Well, it's not Scala, of course; but it's a nice step in the right direction, I think.
There must be some deep philosophy, explaining why they are so retarded.
I think.
I mean, I kind of heard an explanation from Josh; in my translation it sounds like this: "Java programmers are not very smart anyway, let's not overload them with closures and all that stuff."
The correlation I was writing about lately kind of shows itself again.
Weird.
Well, it's not Scala, of course; but it's a nice step in the right direction, I think.
Subclassing errors, OPP, and practically checkable rules to prevent them
P.S. I believe the problem is that with stateful objects, we do not know exactly which category are we dealing with; roughly speaking, for class A subclassing class B, there are actually two monads, with a natural transformation from one to another; and we think we have a functor from, not sure yet, one Kleisli category to another, or from one Eilenberg-Moore category to another, or even an interesting relationship between two categories of adjoints generated by the monads.
Have to look closer; maybe this explains the problem with "Liskov substitution".
P.S. I believe the problem is that with stateful objects, we do not know exactly which category are we dealing with; roughly speaking, for class A subclassing class B, there are actually two monads, with a natural transformation from one to another; and we think we have a functor from, not sure yet, one Kleisli category to another, or from one Eilenberg-Moore category to another, or even an interesting relationship between two categories of adjoints generated by the monads.
Have to look closer; maybe this explains the problem with "Liskov substitution".
inheritance: is circle an ellipse?
Jan. 24th, 2011 11:46 amIt's a known puzzle from the depths of object-oriented teaching: is Circle a subclass or Ellipse. From school we know it is; but as we read in books, for programmers, it is not. How come? Oh, "Liskov principle". They use Liskov principle to scare kids.
Actually we know that a circle is an ellipse with both axes being the same length.
But in programming, an ellipse is something different. It is at least stretchable. And it is also moveable. Somehow it is not rotatable, but we can skip it for simplicity.
An ellipse in programming is (almost) always horizontal; it can be moved (by changing coordinates of its center) and it can be stretched/compressed by changing its height and width. Sure a stretchable ellipse is neither an ellipse nor a circle, not even a stretchable circle. A stretchable circle stretches equally in all directions.
That's it, no? Questions? Objections?
Actually we know that a circle is an ellipse with both axes being the same length.
But in programming, an ellipse is something different. It is at least stretchable. And it is also moveable. Somehow it is not rotatable, but we can skip it for simplicity.
An ellipse in programming is (almost) always horizontal; it can be moved (by changing coordinates of its center) and it can be stretched/compressed by changing its height and width. Sure a stretchable ellipse is neither an ellipse nor a circle, not even a stretchable circle. A stretchable circle stretches equally in all directions.
That's it, no? Questions? Objections?
