Inheritance in Contracts??: A request for code reading and blank opcodes

LukeDLukeD Member Posts: 23
I will describe a simple way that OO could be implemented via code inspection. In this implementation, there would be objects (but no classes), each of which contains the template for the object. There is also an "object" contract, from which all objects inherit.

I assume the following:
That I can read another contract's code.
That the blank opcodes Virtual_(Start/End) and If_Child_Wanting_(Start/End) exist. These opcodes do nothing except annotate the code for processing by another contract.
The Virtual_(Start/End) opcodes indicates that the contained code can be replaced in a child contract.
The If_Child_Wanting_(Start/End) opcodes indicate that the included code should not be executed, but might be included in a child contract. In addition, there would need to be new blank opcodes to handle a template language for use inside the If Child Wanting blocks.


The following pseudo-Serpent code would implement the object contract.

init:
// this allows objects to have constructors
VIRTUAL_START
VIRTUAL_END
code:
// this allows an object to have a minimum tx.value for calling it
IF_CHILD_WANTING_START
if tx.value < $1$: // $1$ is the symbol for template variable 1
stop
IF_CHILD_WANTING_END

// this allows an object to only execute when a particular sender calls it
// though perhaps you would want a list, not just a single address
IF_CHILD_WANTING_START
if tx.sender != $2$:
stop
IF_CHILD_WANTING_END

if msg.datasize > 0:
// a child object would implement methods here
VIRTUAL_START
VIRTUAL_END

Now consider an object for a stack

code:
if tx.value < 100*block.basefee:
stop

if msg.datasize > 0
if msg.data[0] == "push": // a final method
// code for push method
else:
if msg.data[0] == "pop": // a virtual method
VIRTUAL_START
// code for pop method
VIRTUAL_END
else:
// added to allow the object type to be inherited with new methods implemented
VIRTUAL_START
VIRTUAL_END

Now, assuming that I can read in 2 different contracts code, I can write a contract that implements isOfDerivedType(possible_parent, possible_child) that would tell me that the stack is derived from the object
The template language could obviously use some work. For instance, it would be nice to allow a child contract to increase the gas requirement but not decrease it.

I'm wondering what the core team thinks about code inspection of another contract and allowing blank opcodes to be used for a template language. I can think of no way to implement contract inheritance without both.

Comments

  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    To be honest i dont think they should add too complicated features in the stack language itself, though compilers can basically do what they wish. That said, a contract starting with a command happens a lot.

    Programs can *not* read each others memory, not sure how it goes with reading their own memory. Dennis Mckinnon(again!) has a replicator contract, looks like there is a CODECOPY instruction. So if a contracts has a way to return that value, maybe another contract can use it. That said, i am not sure how gas-expensive that would be.

    To be honest i am not sure what feature you mean. Like if the one contract says stop, this one takes over?

    Aside: You can use <pre>....</pre> to make code look good. Forum is just limited html.
  • LukeDLukeD Member Posts: 23
    ::To be honest I don't think they should add too complicated features in the stack language itself, though compilers can basically do what they wish.
    What I'm asking for wouldn't complicate the stack language much at all. I'm asking for the ability to read another contract's code and blank opcodes that simply get skipped over. That is all.

    ::To be honest i am not sure what feature you mean. Like if the one contract says stop, this one takes over?
    No, that's not even close to what I'm talking about. I'm describing how type checking and polymorphism can be implemented via the following:

    A contract called the TypeChecker reads the code of 2 contracts and tells if one contract's code is derived from the other (where what is allowed in a derived contract is defined by a language implemented in the TypeChecker via blank opcodes)

    A contract returning its code wouldn't do it. I need access to the other contracts' code directly because a contract can return whatever it wants and can return fake code.

    Please ask if you do not understand what I am trying to do. I am describing how Type Checking and Polymorphism can be implemented in Ethereum. It is not even possible to do such a thing without the ability to read another contract's code and blank opcodes. Without such a thing, Ethereum will be severely crippled and barely worth using!
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Well you have the ability to read all the code and state as client. Basically.. please acknowledge the difference in what a contract can do and what you can do, it is different. :)

    Contracts just can't unless the other contract specifically implements to return CODECOPY. You can turn it around the other way, you want to force how other contracts are supposed to behave. Maybe the guys behind that contract dont want you to have their code. Similarly EXTRO was removed, because 1) contracts trying to read each others memory would soon become a mess, and tricky to handle for compilers 2) contract may use providing some data as their business model. This gives them a (somewhat small) leverage.
    Without such a thing, Ethereum will be severely crippled and barely worth using!
    Lol, that is clearly far from true.
  • nejucomonejucomo Member Posts: 40
    I'm -1 on adding OO features to the bytecode or EVM. Message passing is already present, simpler, and more flexible. If people want to implement OO frameworks they may do so with message passing (and take on the added gas overhead implied).
Sign In or Register to comment.