Re: object system...


"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:8me0gsbq64xn.yl21j2101cti.dlg@xxxxxxxxxxxxx
On Fri, 9 Jan 2009 17:13:29 +1000, cr88192 wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1i10n69z8xcdq$.16kkhaz0ituqy$.dlg@xxxxxxxxxxxxx
On Fri, 9 Jan 2009 00:01:09 +1000, cr88192 wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1svcuf8jnljq$.1g6jq9vst71p2.dlg@xxxxxxxxxxxxx

which potentially breaks all contracts. The stuff need to be recompiled,
end of story.

this assumes that a linking takes place between the objects' physical
layout
and the code compiled to use it. if this does not happen (for example,
slots
are always accessed via a handle and an accessor), then even changing
object
layout need not break the client code (I have designed it to work even in
the multithreaded case...).

No, the contract refers to the public interface. That includes "slots" and
everything a client may use. The rest is implementation. The question is
whether the interface changes or not. If it does not, there is no problem.


this is an interesting way of looking at it...


(however, all of this machinery is hidden behind the API, and so is
solely
the property of the object system machinery...).

The machinery is basically same as dispatch.


ok.

Prototype OO has some capabilities that Class/Instance OO does not...
C/I is also unable to effectively facilitate some non-C/I languages,
such
as JS, ...

Example?

dynamic delegation, ability to use an object the same as a dictionary
absent needing some separate kind of collection object, ability to
dynamically
add slots and methods to an object, ...

These are means, but what is the goal?

supporting certain kinds of programming languages and formalisms that
would
otherwise go unsupported...

Formalisms or sloppiness?


these styles of languages are designed this way intentionally...

though, granted, JS is not a good example of this style (Self was a much
better example...).


many people go and write papers on this topic...

as an example:
http://www.vpri.org/pdf/m2007002a_lieb_proto.pdf

http://www.vpri.org/pdf/rn2008001_worlds.pdf

....

there was actually one I would give a link to, if I could find it...

but, oh well, here is a page of papers:
http://www.viewpointsresearch.org/html/writings.php


http://en.wikipedia.org/wiki/Prototype-based_programming


http://en.wikipedia.org/wiki/Alan_Kay

so, Alan Kay is involved with all this, and he can be considered an
authority over what is OO, and so, P-OO is also a form of OO, although
granted it is different from C/I-OO.


but, anyways, I guess the basic idea is that C/I-OO and P-OO represent
different formalisms, but in any case, both are formalisms...


then again, in C++, MI is often used to similar effect as having
interfaces...

The inverse. Interface is a poor-man's MI.

it depends on how one looks at it, interfaces, as they exist in the JVM
and
CLI, are a rather different concept than MI, with various strengths and
weaknesses, ...

for example, there are things that can be done with one and not the
other,
and also the reverse...

?


each one is not strictly a subset or superset of the other as far as
behavior goes, but rather both MI and interfaces would seem to represent
similar, but none the less different, constructs...

for example:
an interface does not "add" anything to an object, but instead requires the
object to contain the methods in question;
using MI will in effect create the methods, but an interface requires they
already be there;
interfaces don't introduce scoping conflicts, but MI may do so;
an interface does not add branching to the inheritence graph (or add great
complexity to the in-memory object layout);
....

more so, it makes conceptual sense to be able to use an interface with any
"compatible" object, but with MI this does not make sense (since a class
serves to define an object, but does not serve to abstract it...).


however, interfaces do avoid some of the complexities of MI.

Huh, interfaces have all [alleged] problems of MI.

not quite...

since an interface doesn't actually implement anything, there is no real
need to worry about clashes or lookup order (since 2 methods which match
will simply merge). as a result, one major class of problems that exists
in
MI (having to identify which of the superclasses a given method came
from,
...) simply dissapears.

Nope. Consider a doubly-linked list interface. Now if you derive a new
interface from it, you have the conflict in the case when the interface is
inherited twice. The method Next does not merge when the same item should
participate in two lists. For instance, a device port can be in the list
of
ports and in the notification queue.


I don't follow your example...

could you write out an example of this issue (like in Java or C# or
similar?...).


so, for example, 128 bit integers will be slower than 32 bit integers,
and within reason, this much is unlikely to change...

No, they are as slow as your best possible implementation based on
32-bit
instructions available. This is my requirement to the type system. I
don't
require to rewire the CPU.

ok.

well, yes, in my compilers and such, 128 bit ints and similar are built
in
types...

What about 100 bit? In a higher-level language you write:

type Number is range 1..100;

The compiler is responsible to choose an implementation. The idea of
built-in numeric types is all wrong.


100 bit would not be represented effectively, one can have either 64 or 128
bits, but not 100...

now, of course, one can just ignore or mask off the high order bits, and
this works as well...


My point is that I prefer linear search at compile time to a hash table
at
run-time.

in my case, both compiletime and runtime are sort of fused together...

Yep, like the programmer is fused with the program etc. It is too late to
ask why you need a WC on the Mars probe. The choice was made before.


?...

I am not sure I understand...


one of the papers I had been looking for I think had been talking about
programmer MBTI types and their preferences for certain programming
approaches, but given the context (that MBTI is involved), this was probably
the result of me looking up info about psychology, and not about object
formalisms...


oh well, invoking the search engine doesn't turn up what I was looking
for...


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


.

Relevant Pages

  • Re: GoTo in Java
    ... Scripting languages are programming languages; ... override the method.via an interface, or write a new method in the wrapper. ...
    (comp.lang.cobol)
  • Re: home made home security
    ... to interface to the RS485 master circuit. ... You do understand that the "master circuit" in this case needs to be a PC, ... What is the value of your time spent programming that you would ... Home security automation systems _don't_ cost thousands of dollars if you ...
    (comp.home.automation)
  • Re: object system...
    ... C/I is also unable to effectively facilitate some non-C/I languages, ... Interface is a poor-man's MI. ... Consider a doubly-linked list interface. ... such activity as programming, you better program before you execute ), ...
    (comp.object)
  • Re: Good book on OOP? HELP!
    ... > honest good book that can give me some good fundamentals about programming ... Arrays are an easier way to handle lots of data, and data structures are ... A class is the pattern for an object, and specifies all the details exactly, ... will not break existing systems if you use the same interface. ...
    (borland.public.delphi.non-technical)
  • Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
    ... streaming interface. ... Eventually it will be reading some blocks from the disk ... state machine, but in reality it would just become a "user-level thread ... In contrast, if you start using thread-like programming to begin with, you ...
    (Linux-Kernel)
Quantcast