Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

web.archive.org

Post reply on HN
Print view View original

101–110 of 113 posts

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#101

Post by kd5bjo »

tome wrote: post #97
colllectorof wrote: post #76

Earlier quoted context omitted.

Firstly, late binding is orthogonal to inheritance. It simply means that methods are looked up based on runtime information, rather than determined at compile time. You can have late binding in a language with no inheritance or classes at all. Secondly, OO composition does not solve the problem I described in #3. If object X has 9 methods I want to reuse in object Y, making X a component of Y still requires me to re-…

Actually, I shouldn't have made claims about "the core reason why inheritance was developed" because I've no idea why it was developed. On the other hand, I believe I know why it is necessary (as opposed to convenient ). In many languages there is functionality it provides that is otherwise unavailable. In Java, or C++, or Python, how can we allow superclass methods to call methods on a subclass (a form of late bindi…

The “superclass” can take a config object with a well-defined interface in its constructor, and call methods on this config object when it might need to do something differently.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#102

Post by kragen »

tome wrote: post #96
smrq wrote: post #95

Earlier quoted context omitted.

I don't think you have to squint very hard to see that as an implementation of inheritance.

Will that allow the version of m in x to send messages back to y? I don't know Ruby, but most likely not.

No, for that you need to pass a self argument. See my comment below about Abadi and Cardelli's book for a (reference to a) full development of the theme.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#103

Post by kragen »

tome wrote: post #98
hota_mazi wrote: post #47

Earlier quoted context omitted.

> As for higher order functions you would write a function that does the 90% and accepts a function parameter for the other 10%. Surely you see how this doesn't scale, right? You would need to first write your code, then abstract every single piece of it as a call to a function passed in parameters. Now your function is accepting five different functions in parameters, and calls them. This is a terrible and impossibl…

So put those parameters in a single record type and just override the 10% of them that you need to.

Abadi and Cardelli identified some ways that this solution falls short—in particular, the self parameter isn't covariant—and how to fix them.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#104

Post by kragen »

hinkley wrote: post #62
inopinatus wrote: post #60

Earlier quoted context omitted.

Pot, kettle, black. Blasphemy is a subclass of profanity.

Fun fact, “golly” is a contraction of “god’s body” which at one point was among the highest of blasphemies. Implying that the Creator was corporeal, that’s a paddlin’

Apparently this etymology is plausible but still considered speculative. At the point that "golly" appears in the written record, it is no longer among the highest of blasphemies.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#105

Post by [deleted] »

andrepd wrote: post #86
callmeal wrote: post #59

Earlier quoted context omitted.

This is how it would be done in Java: class Parent { public void first() {}; public void second() {}; public void third() {}; } class Child extends Parent { @Override public void third() {}; //change implementation of third function, reusing the first two. }

In OCaml: module Foo = struct let first = 1 let second = 2 let third = 3 end module Bar = struct include Foo (* Include contents of [Foo] *) let third = 4 (* Override [third] *) end

[deleted]

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#106

Post by colllectorof »

andrepd wrote: post #86
callmeal wrote: post #59

Earlier quoted context omitted.

This is how it would be done in Java: class Parent { public void first() {}; public void second() {}; public void third() {}; } class Child extends Parent { @Override public void third() {}; //change implementation of third function, reusing the first two. }

In OCaml: module Foo = struct let first = 1 let second = 2 let third = 3 end module Bar = struct include Foo (* Include contents of [Foo] *) let third = 4 (* Override [third] *) end

OCaml has real objects and classes. Moreover, it is trivial to demonstrate that your example doesn't work in practice:

  module Foo = struct
   let first() = 1
   let second() = first() + 1
  end

  module Bar = struct
    include Foo
    let first() = 0
  end
Bar.second () will still be 2 because of static binding. Thus you cannot use this approach to replace 'first' by itself without creating inconsistencies.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#107

Post by DonHopkins »

kragen wrote: post #30
ben509 wrote: post #5

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some concerns (e.g. file I/O and word splitting). It's odd he makes these complaints, because the comment he's responding has this caveat: > unless they are talking about writing a clone of The Sims or something In the context of a game or simulation, such classes can abs…

> It's odd he makes these complaints, because the comment he's responding has this caveat: > > unless they are talking about writing a clone of The Sims or something Although I formatted it as a quote, I wasn't quoting or responding to somebody else in that part. That part about the Sims was part of the somewhat flippant principle I was proposing. The litany about ducks was just to explain the reasons for it. It wasn…

The Sims actually uses "subject oriented programming", and it even personalizes objects and objectifies people! ;)

It's actually implemented in C++ of course, but it has a virtual machine that executes a noodly visual programming language called "SimAntics". And by noodly, I mean optimized for spaghetti code, containing intertwined loops, floppy, and droopy...

https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74d...

Subject Oriented Programming

This is described by some people as object — not Object Oriented Programming, but Subject Oriented Programming.

Objectifying People

People are objects, so when you click on another person, the items that you get in the menu depend on your mood, and your relationship with that person.

(From the transcript of this demo video:)

https://www.youtube.com/watch?v=-exdu4ETscs

The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo

This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that I developed for The Sims with Will Wright at Maxis and Electronic Arts.

http://radar.oreilly.com/2009/03/interview-will-wright-sims-...

Will Wright: Well, one of the first challenges was could we develop a really robust model of human behavior test so that we could put these little characters in the elements in any situation they would behave reasonably. A Sims user is kind of controlling the environment. They can put the Sims in a wide variety of potential environments and then the Sims have to act reasonable. So we kind of had to develop a very — well, on the surface, it looks like an object-oriented programming model, but in fact, it’s what’s technically called a subject-oriented programming model. But I won’t get into that detail. So developing this robust kind of behavior system — in fact, it was environmentally distributed intelligence is the way we solved it.

But on the design side, there was a lot of thought about how much autonomy do these characters have versus how much reliance do they have on the player directing their actions. And there was also a whole dimension of thought around how much are we going to let the player read in to the simulation. In other words, how much of the simulation are we going to offer them to play of imagination versus make very clear and overt?

https://www.gamedev.net/forums/topic/697362-need-some-advice...

All8Up Moderator

Posted June 15, 2018

From the way the embedded code is shown, I would say the first thing to do is reverse the logic. What I mean is that what you posted suggests that the code is along the lines of "I'm trying to interact with you" and "I need to figure out what you are and what I can do to you". Conceptually of course is the most sensible solution, unfortunately in practice it is also the solution which fails the most often. Rather than this, I've always used subject oriented programming for interactions. This reverses the logic such that rather than the 'doer' figuring things out the subject of the interaction performs the work. Basically this means that the input system would simply set a flag on the input component saying "this entity wishes to interact". The interaction system can then do pre-cull for subject entities which are in range, which ones can be used from the doer's position, etc. Finally, you end up with a door that runs the rule checks: "You are in range, you have my key, it is Monday after noon, you are wearing a purple shirt... Ok, guess I will open now."

As to how you implement these things in the ECS itself, I suspect everyone does it differently. Personally I use a handle based approach where the interaction component simply contains a handle which refers to usually a script which checks the interaction rules. The script gets the doer and subject ID's so it can check states and make the decision. Then, likely in another script, an action is performed.

Overall this probably sounds ass backwards but it is a well proven solution to removing massive 'if/else' checks. It is also great for expansion packs and such since all the new logic is contained in the subject and you don't have to patch the doer code to understand the new interaction. Just as an example, The Sims used(still uses I assume) this subject oriented approach which allows DLC to be dropped in and mostly just work.

Hope this makes sense.

http://ivizlab.sfu.ca/arya/Papers/SW/SOP.pdf

Subject-Oriented Programming (A Critique of Pure Objects). William Harrison and Harold Ossher.

Abstract

Object-Oriented technology is often described in terms of an interwoven troika of themes: encapsulation, polymorphism, and inheritance. But these themes are firmly tied with the concept of identity. If object-oriented technology is to be successfully scaled from the development of independent applications to development of integrated suites of applications, it must relax its emphasis on the object. The technology must recognize more directly that a multiplicity of subjective views delocalizes the concept of object, and must emphasize more the binding concept of identity to tie them together.

This paper explores this shift to a style of object oriented technology that emphasizes the subjective views: Subject-Oriented Programming.

https://en.wikipedia.org/wiki/Subject-oriented_programming

In computing, subject-oriented programming is an object-oriented software paradigm in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions (“subjects”) of the objects. The term and concepts were first published in September 1993 in a conference paper[1] which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996. As illustrated in that paper, an analogy is made with the contrast between the philosophical views of Plato and Kant with respect to the characteristics of “real” objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird’s nor the tax-assessor’s additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant’s analysis, the same may be true even of characteristics we think of as intrinsic.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#108

Post by DonHopkins »

overgard wrote: post #7
ben509 wrote: post #5

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some concerns (e.g. file I/O and word splitting). It's odd he makes these complaints, because the comment he's responding has this caveat: > unless they are talking about writing a clone of The Sims or something In the context of a game or simulation, such classes can abs…

Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You…

Both Unity and COM use aggregation instead of implementation inheritance to compose bunches of small sub-objects together.

Unity has the notion of components (inheriting from MonoBehaviour => Behaviour => Component => Object), which can be multiply attached to GameObjects (inheriting from Object), that you can switch between with gameObject.GetComponent().

COM has the notion of multiple interfaces to the same "controlling unknown" object (analogous to GameObject), that you can switch between with QueryInterface.

https://docs.microsoft.com/en-us/windows/win32/com/aggregati...

https://flylib.com/books/en/3.357.1.89/1/

http://www.369o.com/data/books/atl/0321159624/ch06lev1sec5.h...

https://en.wikipedia.org/wiki/Object_composition#Aggregation

They're basically the same idea, but slightly different in the details and implementation.

COM is essentially C++ pure virtual interfaces implemented by one or more concrete classes using multiple inheritance (like the way Java lets you multiply inherit interfaces, but only singly inherit classes). Different COM interfaces can refer to the same shared C++ implementation object, or separate delegate objects, and "tear off" objects created on demand.

Unity's component model is implemented in C#, but isn't an essential language feature of C#, just a way of using it to implement aggregation.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#109

Post by kragen »

DonHopkins wrote: post #108
overgard wrote: post #7

Earlier quoted context omitted.

Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You…

Both Unity and COM use aggregation instead of implementation inheritance to compose bunches of small sub-objects together. Unity has the notion of components (inheriting from MonoBehaviour => Behaviour => Component => Object), which can be multiply attached to GameObjects (inheriting from Object), that you can switch between with gameObject.GetComponent (). COM has the notion of multiple interfaces to the same "contr…

From your point of view, are GameObjects in Unity an implementation of entities from the entity–component–system pattern, or is there a difference?

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#110

Post by kragen »

DonHopkins wrote: post #107
kragen wrote: post #30

Earlier quoted context omitted.

> It's odd he makes these complaints, because the comment he's responding has this caveat: > > unless they are talking about writing a clone of The Sims or something Although I formatted it as a quote, I wasn't quoting or responding to somebody else in that part. That part about the Sims was part of the somewhat flippant principle I was proposing. The litany about ducks was just to explain the reasons for it. It wasn…

The Sims actually uses "subject oriented programming", and it even personalizes objects and objectifies people! ;) It's actually implemented in C++ of course, but it has a virtual machine that executes a noodly visual programming language called "SimAntics". And by noodly, I mean optimized for spaghetti code, containing intertwined loops, floppy, and droopy... https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a…

SOP sounds a lot like ECS, with the subjects being the components, but I guess I kind of said that in a different comment.

The Kantian thing is kind of a mindfuck. I may need to think about that for a while. It reminds me of the work Phil Agre did on literary criticism of AI.

Post reply on HN