Preface: I'm on 10.1C on Unix.
OK, so I've got a parent class called Table that takes in a ROWID for a constructor. Then, I create a subclass called Customer that takes in an INTEGER (customer #) for a constructor. However, when I try to instantiate a Customer object using a ROWID, I get a compile error - "Cannot use NEW statement with class 'Customer' because no constructor found with matching signature. (13840)". When I add an explicit super constructor to Customer:
CONSTRUCTOR PUBLIC Customer(INPUT rowid AS ROWID):
SUPER(rowid).
END CONSTRUCTOR.
It works fine. Please tell me this isn't needed in later versions (>10.1C). Also, why do I get a run-time error "Invalid cast from Table to Customer. (12869)" when downcasting?:
DEF VAR objCust AS Customer NO-UNDO.
objCust = CAST(NEW Table(ROWID(customer)), Customer).
One more... why, after I change a class (.cls) (and compile to new .r code), do I have to restart my entire session to get the changes? I only have this issue with classes, not .p's. I've been unable to find any documentation in ProKB about this.
Thanks.
1. If a class has a constructor requires parameters and you intend to derive from it, then the derived class must also have a constructor that calls one of the parent's constructors. There is no implied constructor in the derived class other than the default constructor.
2. You can't downcast class customer to class table. That would be an up-cast since customer inherits from table, not a down-cast. You can only down cast if your instance of the table class IS an instance of class customer. Which it will never be since customer inherits from table, not the other way around.
3. Unlike other languages where the compiler and the runtime are separate, in OpenEdge they are the same session and the compiler caches stuff for the runtime. New instances of an object should get the changes, but anything still in memory will use the old cached instance. Don't rely on this behavior. The AVM doesn't hotswap code sections. The same behavior applies to .p files. But you probably don't see it very often unless you run lots of persistent procedures.
3. Thanks for the info. It's generally not a problem; it's more of an annoyance for Webspeed since we have to restart the broker
Trimming the agents should be sufficient an is usually faster.
1. Yes. In all the OO languages I"m familiar with.
2. I mis-typed. I meant " You can't downcast an instance of table to the type customer". Because table instance doesn't have all the stuff (variables, methods, properties, events) that an instance of customer would have.
3. If this is a dev environment, then you can run with source code (turn on compile-on-fly for the broker), and make sure you don't leave objects around between requests. Or trim all the agents as Mike suggests.
Great; thank you gentlemen