Anders Norås wrote:
> OO is all about objects, so objects need to be mass produced in some
> way or another, There are basically two ways of doing this; the
> industrialized way of using classes that serve as blueprints for new
> object instances or object factories that build new instances - or -
> the biological way of building prototype objects that can be cloned.
> Most OO-languages use the "industrialized" method, but other
> languages, like JavaScript or Self, are prototype based.
> In my JavaScript I clone objects and swap implementations of some of
> the methods to demonstrate the biological way of building.
Agree!
> a_person = new Person();
>
> nancy_cartwright = Object.clone(a_person);
> nancy_cartwright.setFirstName("Nancy");
> nancy_cartwright.setLastName("Carthwright");
<snip>
> You (Rikard) probably don't like the rouge dynamic style of this code,
> and I agree that writing this kind of code is bad for maintainability,
> but for quick disposable solutions, this is "easier" than building a
> big static structure to achieve the same thing.
Actually, if you do it in the prototype-based way it is ok. It's when
you start making these kinds of decision on a per-instantiation basis
that it becomes a little too flimsy :-) Basically your prototype becomes
a class, but (to me) one of the main things is that what is put into it,
the various mixins, have to be "known" somehow, or else the resulting
object is kind of pointless.
It's the same as with XML in a sense: you build an XML document from
scratch, and each document may be different, but if it uses namespaces
and clients discover these properly, then the clients don't have to know
the "type" of the overall document. Same thing with objects: as long as
the various mixins and mixin types are known, the client code doesn't
care whether the instance was put together using prototyping or class
instantiation.
This is closer to ObjectOrientation, as opposed to class-based
approaches, but the loss of static structure does have some drawbacks,
such as making it harder to do static analysis (our visualizer wouldn't
work at all!).
> Whether you like the idea of copying single methods between objects or
> not, the underlying concept here is reuse of fragments, which is one
> of the things Qi4j enables us to do. Qi4j does this in a very
> different way from what one would do in JavaScript or Ruby, but my
> argument is that the concept of fragment composition is more or less
> the same.
Agree!
> BTW; are you (Rikard again :) planning on coming to Oslo anytime soon,
> I really feel that we could have a good discussion of this over a beer
> or five.
Right now I have no Oslo trip planned, so probably next JavaZone. I
pretty much live in Malaysia most of the time now (moving into a new
house in KL this Friday), so getting to Norway is a bit of a hassle :-)
Thankfully internet works reasonably well.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
