Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-2952145 ] Constructor call chain configuration
|
From: SourceForge.net <no...@so...> - 2010-03-02 02:20:42
|
Bugs item #2952145, was opened at 2010-02-15 15:56 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2952145&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 35. TclOO Package Group: development: 8.6b1.1 >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Ashok P. Nadkarni (apnadkarni) Assigned to: Donal K. Fellows (dkf) Summary: Constructor call chain configuration Initial Comment: A posting by Martin Lembourg in c.l.t leads to the following question - how does one implement the following scenario: Two independent classes A and B and a class C that derives from both of them. I want to be able create objects of each of these classes. When I create an object of class C, constructors for both A and B must be called. The issue is that ( assuming the statement "superclass A B" in C's definition), if A's constructor has a command "next", the statement "A create foo" raises an error "no next constructor implementation". If we remove the "next" command from A's constructor, then "A create foo" works but then when doing "C create bar", the constructor for B does not get called (presumably because A's constructor no longer has a next statement). So how does one write code to meet the above requirements ? (tested with CVS HEAD as of Feb 15 2010) /Ashok ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-03-02 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-02-15 16:13 Message: I hate these sorts of questions. The (hardline ontological-theoretic) answer is that if A and B are truly wholly independent classes, C has no business deriving from both of them. If they are not that separate, make both A and B derive from a common parent class and the problem goes away. If you wish to argue that I'm wrong, feel free. Demonstrate a specific example where it matters. Not a theoretical example either; while I know it is certainly possible to create code that will fail in the circumstances outlined, my whole point is that code that is going to be working sanely will not actually need to do so. Thus a combobox widget can be considered to be a subclass of entry, but not of listbox. (The listbox-ness is best held in another widget that is delegated to, with forwarded methods doing the delegation.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2952145&group_id=10894 |