Re: object system...

Responding to cr88192...

I think we already have far too many OOPLs. IMO we need another OOPL about as much as a revival of smallpox. So I am rather biased below...

but, oh well, I figure I will present some of the ideas behind an object system I had implemented and am making use of in my projects, and maybe people can comment if some things are good or not so good.

basically, the core of the system is this:
Single-Inheritance Class/Instance OO (MI is more-or-less supported as well, but it is hacky and not well supported by the APIs, so I mostly ignore MI);
there are Interfaces, like in Java and friends;
...


but, it differs from the normal model some in a few ways:

interfaces can implement slots as well as methods;

What is a 'slot'? In software a slot is usually a pre-allocated block of memory that will be filled in later (e.g., allocating an array pf objects to be initialized later to avoid multiple heap operations and/or provide contiguous addressing), but that doesn't seem like the case here.

What about synchronous services to access knowledge (e.g., getters and setters)? In OOA/D accessing knowledge responsibilities is quite different than accessing behavior responsibilities.


it is technically possible to use any interface with any compatible class (due to a side effect of how the interface mechanism is implemented, the same interface will work on a class regardless of whether or not said class implements the interface as such);

The parenthetical comment seems like a Really Bad Idea. Interfaces exist to provide decoupling by hiding responsibility implementations so there should be no interface if there is no implementation. Corollary: no-op methods usually indicate a design flaw. But "working" when there is no implementation is even worse.


it is possible to modify class layout at runtime, and the object system machinery will work to keep everything consistent (internally, a versioning system is used, so an older object may be layed out according to an older version of the class), however doing so will reduce the performance of the class(es) in question;

I grew up with FORTRAN's assigned GOTO, COBOL's ALTER, and the Forth language (which could alter its own instructions at run-time). All were disasters for long-term maintenance. (By the late '70s using any of those things was grounds for summary dismissal in many shops.) So I would need a lot of convincing to accept modifying classes at runtime as a good idea. [IMO, one of the very few things that Smalltalk got wrong was having the ability to add properties to individual objects of a class. Having the run-time type system detect the problem when you incorrectly access the property on an object that doesn't have it does not endear you to customers using a production version 2000 miles away.]


it is possible to add slots to individual instances of an object, allowing the emulation of some aspects of Prototype-OO style (as well as the ability to "clone" objects, ...), however, these slots will perform worse than those defined in the class, and in general there are some restrictions placed on these slots (it is only possible to access them either by name-based access, special functions, or through the use of interfaces which contain the slot in question);

Can't respond because I don't know what you mean by 'slot'.


there is also support for object delegation (like in Self or JavaScript), but this feature can at present only be used via interfaces (this is mostly for technical reasons);

This makes me nervous since JavaScript is a poster child for poor maintainability.

I don't see any need for special features to do delegation. I think existing relationship navigation and interfaces work just fine in supporting peer-to-peer collaboration whether delegation is used or not.

[Delegation of a service just means the client collaborates with a different object after the delegation than before the delegation. That is, after delegation the original object should be out of the picture except as a placeholder for relationship navigation (which is orthogonal to class semantics). When the original object maintains the delegated responsibility in its interface and redispatches it becomes a high-level node in a functional decomposition tree. One can argue strongly that the primary goal of the OO paradigm is to eliminate those sorts of hierarchical dependencies.]


there is also support for special assignable methods, which exist in the instance rather than in the class (the method is actually directed through a slot rather than through the vtable).

Yech. Assigned GOTOs and ALTERs reincarnated. Keeping track of who has which properties to avoid incorrect access is a maintenance minefield for the developer.


--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@xxxxxxxxxxx
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
.

Relevant Pages

  • Re: Relational model versus object model
    ... Today almost all OOPL IDEs provide integrated class libraries. ... Note that OO classes with no behavior responsibilities are fairly ... >> paradigm as manifested by a relational DBMS. ... implement interfaces for inclusion polymorphism. ...
    (comp.object)
  • Re: Modeling User/Accounts
    ... interfaces, I ... One usually only needs the Interface model element when one wants to limit the access some objects have (i.e., to not expose all the responsibilities to certain other objects) AND that is important to the problem solution. ... IOW, a ContactInfo object might be an associative object on the relationship or it could be a separate object that is dynamically related to certain persons depending on context. ...
    (comp.object)
  • Re: DUnit TestCase wizard is useless
    ... > abstraction between design and implementation. ... You use interfaces to ... > responsibilities and implementations around as needed until you have ...
    (borland.public.delphi.non-technical)
  • Re: Bobs Self-aggrandizing ignorant Count: Was: What databases have taught me
    ... This can be done in OO with abstract base classes or interfaces. ... form a set of responsibilities that the object guarantees to ... Mike ...
    (comp.object)
  • Re: object system...
    ... whatever can be accessed via interfaces). ... similar feature (although, they do so by dynamically adding interfaces to ... it does simplify implementing languages like JavaScript which do have ... I don't see any need for special features to do delegation. ...
    (comp.object)