Cobra Forums

What's wrong with this code?



I get the following compiler error (translated from Spanish):

Simple.Clone(): "couldn't find an appropriate member to override"

If this is not the proper way to copy/clone in Cobra, then what is it? Maybe we could add it to the How-to section, as it is quite a common thing to do...

Regards,
Manuel

[Chuck: this is (another) long post. Make it into a ticket if you don't have time for it now; maybe you can make another ticket with my other operator overloading cue suggestion. I'm aware neither of them is a priority right now]

On a related note, I was thinking that maybe we could consider something along the lines of "cue clone" which forced the class to implement ICloneable, and defaulted to memberwiseClone:



In case deep copy was required, we could allow it like this (the "is deep" syntax is the first that popped to my mind, there could better options):







Of course, the user could provide her own cloning implementation:




I've used Object as return type to follow the C# style, but maybe in Cobra covariance could be achieved (i.e., return Simple despite the fact that the base interface returns Object). This way we would avoid the ugly cast:



Overall, I suspect this "cue clone" feature could help portability between back-ends.

Regards,
Manuel

jonathandavid wrote:What's wrong with this code?

class Simple
    implements ICloneable
    
    def clone as Object is override
        return Simple()
        
    def main is shared
        simple = Simple()
        simple.clone

I get the following compiler error (translated from Spanish):

Simple.Clone(): "couldn't find an appropriate member to override"

"override" is for when a base class has the same method. In this case, you are implementing a method for the first time. No such method *definition* exists in an interface, only a declaration of the method *interface*. This is evidenced by the fact that if you didn't implement .clone you would get a compilation error because it was not defined.

This is true in C# and VB as well.

Regarding your ideas for "cue clone":

-- Yes, "clone" is a candidate for a "cue"

-- For dealing with the silly "Object return type" that plagues various static languages, I was planning a special type "same". I've already reserved the keyword which is described in Source\KeywordSpecs.cobra as:

'same (r) | type: The type indicating the same type as the current instance which will always be the same as the enclosing type or a descendant thereof.'

-- "cue is deep" is unlikely because getting deep clones/copies is hard (maybe impossible?) to do correctly by automation. Consider an Employee class that has a reference to its Department. A naive "deep cue" would end of cloning the entire department and all of its employees. If employee objects had any kind of reference to Customer objects (say the last one they gave tech support to) then a bunch of customers would come for the ride.

Then there are issues with vars vs. properties. A read/write property could have non-var storage (for example, it could read/write the contents of a file). And a var may or may not be covered by a property.

At this point, an automatic deep clone is a potential minefield of issues.

I believe Smalltalk stubs out a .deepCopy method vs. .shallowCopy method so programmers can make it clear what they are asking for and have some expectation. But the correct override of .deepCopy is still done manually.

-- Operator overloads already have tickets (consumption and declaration).

-- Otherwise, I haven't ticketed cues yet. But if you want to ticket "cue clone" feel free!

Thanks for the help. I come from a C++ background so I'm not that familiar with these .net stuff. Would if we too much ask that the compiler generates a message along the lines of:

"Hint: If you're trying to implement the clone method of ICloneable, you must remove the "is override" modifier."

That would help people who come to Cobra from non-.NET lenguages like C++.

Chuck wrote:-- For dealing with the silly "Object return type" that plagues various static languages, I was planning a special type "same". I've already reserved the keyword which is described in Source\KeywordSpecs.cobra as:

'same (r) | type: The type indicating the same type as the current instance which will always be the same as the enclosing type or a descendant thereof.'

That would be great. May I suggest "Same" with a capital "S" so that it is more apparent that we are talking about a class. Would this allow me to write:

??

Chuck wrote:At this point, an automatic deep clone is a potential minefield of issues.

I understand. I see there is no such thing in the .net framework, so you might be right in suggesting that we forget about it.

Chuck wrote:-- Operator overloads already have tickets (consumption and declaration).

Ok. I'm not sure how tickets work though. If I have some random ideas regarding operator overloading, can I edit the ticket and add them there?

Chuck wrote:Otherwise, I haven't ticketed cues yet. But if you want to ticket "cue clone" feel free!

Good. I have some cue-related ideas, I might add some tickets for them.

BTW, to help me get more fluent with Cobra I've written a little class for Rational numbers. I think it might be of interest for other people, do you think I could post it here in the forum? Or maybe in the wiki, or in the samples? My idea is that it will also serve as an interesting test for the operator overloading cues once they're functional.

-- I'm okay with the hint as long as it's for any interface method, not just ICloneable. You can make a ticket for it.

-- Regarding Same, that looks like an actual class name to me like Object, String, Customer, etc. "same" is lowercase in the same fashion as "dynamic", "int", "base", "this", etc.

-- You can do want you want right now, although less compact:
.getType is a method of System.Object that returns the type of the current instance (whether class or struct). And Cobra lets you instantiate it by calling it with parens.

We still need a portable version since .NET is .getType and JVM is .class. *sigh*

-- We could potentially support "same()" since it is a keyword.

-- Regarding random ideas, they are best discussed here. Then if we come to a consensus, add that to the ticket. And often paste the link of the forum discussion in the ticket in case someone wants to see the original bloody details. That's not a hard rule however. We sometimes *do* discuss things in tickets. I can't say I have clear guidelines at this point.

-- I added tickets for all the cues today.

-- Regarding how tickets work, they are done through a Trac instance which is a web application with wiki, tickets, milestones and Subversion browsing. The user authentication is linked to the discussion forum user table, but you do have to login again. Use your same username and password.

-- You can add comments to tickets. The comments use the same markup language as the wiki pages. I check the list of updated tickets daily so I'll see the comments within 24 hours.

-- I would post samples on the forums first for people to look at. You should be able to use the "Upload attachment" tab below.

-- I can be picky about official samples and how-to's so don't be surprised if I ask for tweaks or even major changes. But don't be shy about sharing code in the forums either. Any old code can be pasted here for sharing or feedback at any time.

HTH