Re: object system...

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.

(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.

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?

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...

?

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.

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.

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.

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

Relevant Pages

  • Re: g++: using fstat on an already open stream
    ... standard IO features in C++. ... C++ is very nice when you are writing an algorithm. ... But if it comes to interfaces, be it filesystem interface as in orginal ... Only thing you can do if you have to support multiple compilers, ...
    (comp.unix.programmer)
  • Re: Type, bind(c) and gfortran
    ... I think your code is correct and gfortran has a bug in its C interop ... three other compilers do not fail to compile ... I'm trying to interface gsl to a fortran program. ...
    (comp.lang.fortran)
  • Re: Best Language for .Net?
    ... early compilers. ... Interface section is what allows Pascal to have a fast ... Delphi (the language). ... I agree, most languages tend to boil down to your preference in syntax, ...
    (borland.public.delphi.non-technical)
  • band via Mahammed AL-Mihmadis socialism
    ... it inherits a interface too polish at first her unknown ... You mainly impose proud and contracts our governing, ...
    (rec.pyrotechnics)
  • Re: OO Concepts and C# Properties
    ... You look at an interface, ... >class designer took the trouble to write a line of JavaDoc or XMLDoc. ... Contracts imply function. ... external invariants and contracts, then I think functions lower the ...
    (comp.object)
Quantcast