11–20 of 33 posts
---
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
---
What is really described here is a dynamicly typed, actor-based language. I can see a bit of truth in Joe Armstrong's joke that Erlang is the original and true OO language.
Consider this tree: dog bark softly loudly run fast slow cat meow purr run Let's call this the coordinate-system of your API (I've extended it a little hopefully to make it clearer). It's a small coordinate-system because it doesn't take any strings, but whatever. 'loudly' only makes sense in the context of 'bark', and 'bark' only makes sense on the context of 'dog'. That list of nodes is a coordinate that identifies…
Or can think of dog having an internal state machine and can be in two states -- barking or running. When it is barking he can get two messages {softly} or {loudly}. If it is running, can get fast or slow messages. There is a way to switch from one state to another say getting a {bark} or {run}. Other messages might lead to an error/exception.
This way the first way of doing things is just sending a message which both switches state and regulates intensity of activity.
Heck pretty much a similar example is presented in Learn You Some Erlang For Great Good book in the "Rage Against the Finite State Machine":
http://learnyousomeerlang.com/finite-state-machines
(My favorite state machine is a that of a cat though in that text)
Maybe we need some sort of hn robots.txt file to stop things from getting posted before someone's ready for them to be :)
Consider this tree: dog bark softly loudly run fast slow cat meow purr run Let's call this the coordinate-system of your API (I've extended it a little hopefully to make it clearer). It's a small coordinate-system because it doesn't take any strings, but whatever. 'loudly' only makes sense in the context of 'bark', and 'bark' only makes sense on the context of 'dog'. That list of nodes is a coordinate that identifies…
According to Alan Kay true OO is message based. First you'd identify what the objects are -- it seems dog and cat. Then you have a choice. Can either send them messages which look like {bark, softly}, {bark, loudly}, {run, fast}, {run, slow}. Similar for cat. Or can think of dog having an internal state machine and can be in two states -- barking or running. When it is barking he can get two messages {softly} or {lou…
Neat link, I'll have to check it out. I've not done erlang but I'm quite intrigued by gen_server in particular.
Sorry for talking about coordinate-systems: I can't help it, I have a physics degree.
I don't really see a pervasive point to this rant. It is true that OOP can be reduced to message passing, and that there's a specific style of OOP a lot of people see as "OOP", but that doesn't mean that this style is "just obfuscated procedural code, or uglified functional code". That OOP can be implemented on top of functional style code, or procedural style code says nothing about it being "true OOP" or not. For e…
Reducing how many channels interact semplify code a lot. Oop went for input, status and statu, output pairs. Functional uses input, output and api, output pairs.
Good programmers understand that and apply the one which is proper to model their problem, to reach performance/memory goals and most importantly to reduce te cognitive load of large codebases.
"Message Oriented" flows well into multiple dispatch, as the entire message can be taken into account for determining the final method combination.
This of course is related back to the notion of a language focusing on the nouns (Objects), or verbs (Methods, Messages): http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
In a purely linguistic sense, the phrase "Object Oriented" does have some affinity to single dispatch, because the dispatch is oriented around a single special Object. "Message Oriented" flows well into multiple dispatch, as the entire message can be taken into account for determining the final method combination. This of course is related back to the notion of a language focusing on the nouns (Objects), or verbs (Me…
I'm not sure about this. The metaphor is that you send a message to a specific recipient, and the recipient figures out, independently, how to behave in response to that message. So it still seems like single dispatch to me.
Consider this tree: dog bark softly loudly run fast slow cat meow purr run Let's call this the coordinate-system of your API (I've extended it a little hopefully to make it clearer). It's a small coordinate-system because it doesn't take any strings, but whatever. 'loudly' only makes sense in the context of 'bark', and 'bark' only makes sense on the context of 'dog'. That list of nodes is a coordinate that identifies…
($define! tree ($branch
(dog ($branch
(bark ($branch
(loudly ($lambda () "WOOF!"))
(softly ($lambda () "woof"))))
(run ($branch
(fast ())
(slow ())))))
(cat ($branch
(meow ($lambda () "meow!"))
(purr ())
(run ())))))
($walk tree ($walk dog ($walk bark (loudly)))
=> "WOOF!"
In the above Kernel code, the context is called an environment, and environments are first class. The evaluator takes an expression o and an environment e as arguments, and it is said that "o is evaluated in e".
The tree is basically described by construcing new environments, where for example, the symbol "dog" is bound to another environment containing the bindings "bark" and "run". I've used the word "$branch" in the example for simplicity, but this term already exists in Kernel under another name.
($define! $branch $bindings->environment)
($define! $walk
($vau (env expr) dynenv
(eval expr (make-environment (eval env dynenv) dynenv))))
I've termed it environment-oriented-programming. I basically use it as a means to implement OOP, generics, records, algebraic data types and whatnot. When combined with the use of other Kernel features like encapsulation types, it can be used to implement interesting type systems.
What was so urgent about getting out this half-baked thought out that the dude couldn't have waited to write something coherent? If all you're doing is calling methods on objects with no supertypes or private members, then yeah, you could accomplish the same thing by convention. But once you start layering on more functionality in your object system, the number of way you code encode this functionality starts to expl…
Sometimes, we just want to use the medium to share thoughts with people, there's no cause to be annoyed or even condescending like that, it makes for a horrible atmosphere where no one will want to engage in public discourse.