| 09-10-2007, 06:37 PM | #1 |
I generally make these lame questions on IRC where guys like pipedream and grim0001 are willing to waste time thinking of good syntax for a feature. But IRC is off-line... So this is the deal, for no actual reason I began coding on saturday what some of you may call "inheritance" (it isn't, but from now during this post I'll call it "inheritance" for simplicity) and as a matter of fact it is inheritance only that virtual methods are still a monopoly of interfaces... As a matter of fact I have just finished to code it today, and yadda yadda yadda apparently testing is the only thing is left before releasing it. But I found myself in an strange problem, there is this mostly unknown feature of interfaces where you can create an instance of an object that follows the interface out of simply the object id. I actually like that feature, although it is quite risky, because it can only do it correctly if the struct's create method was declared to take nothing or was not declared at all, else it would use allocate() which breaks encapsulation badly. The thing is, after adding this "inheritance" thing the signature for the allocate() method changes, for example:  JASS:struct A integer b static method create takes integer x returns A local A s=A.allocate() set s.b=x return s endmethod endstruct struct B extends A integer a endstruct B.allocate would actually have to take an "integer x" as argument , why? Because when an struct extends another struct it is not more than making use of the parent struct, and somehow my decision was to make it do that... Anyways what happens is that you can extend an struct that extends an interface, then the bottom most child may still implement (and change) the interface's methods, so virtual stuff stays for interfaces (but you can have default code, etc in the middle child... ) But since this is happening people can still use interface.create() but they may create an struct that extends another struct and this middle struct might have a custom create method that does not take nothing. Since you are still reading this post even after that paragraph you passed the test that prevents users who don't understand what I am saying to reply. What happens is that now I can't use some child types for interface.create() and return 0 in that case, I have also decided that If we are forced to use allocate after "custom create with arguments" was declared next version is also going to return 0 in that case. If you are making a system and want to use the benefits of the interface constructor then, it would be a good idea to force users into not using "custom constructors with arguments" otherwise they may use them and break your usage of interface.create() ... And that's the reason I need to think of good syntax for interfaces so you say "don't allow arguments in custom constructors" A: JASS:interface X static method create takes nothing method yadda takes real x , real y returns real endinterface B: JASS:interface X (fixedconstructor) //??? method yadda takes real x , real y returns real endinterface C: JASS:interface Y rule fixedconstructor method yadda takes real x , real y returns real endinterface D: ??? I vote for A. Alternative ideas are welcome. |
| 09-10-2007, 06:53 PM | #2 |
| 09-10-2007, 07:33 PM | #3 |
| 09-10-2007, 07:51 PM | #4 |
| 09-10-2007, 08:35 PM | #5 |