TOPIC: Is it possible to redefine builtin Object methods?
#461
Is it possible to redefine builtin Object methods? 3 Years, 8 Months ago
Hi, if I create a test class and then I create an instance from this test class, then I can use all the Object builtin class methods. Does this mean that all the instances of any new class are implicitly derived from Object builtin class? Then, why cannot I redefine its methods? For example, if I define 'Myclass' as:

Code:

class {
TestMethod() {
return "test"
}
Size() {
return 12345
}
}



then, if I do:

Code:

obj = Myclass
obj.Size()



It returns 0, instead of 12345... Why?

If I cannot redefine Object methods and all new classes derive from Object, then it means that I cannot use anyone of these names (Object builtin class methods) for my new classes methods:

HasIf?, Project, Accum, HasNamed?, ProjectValues, Accum1, Intersect, Readonly?, Add, Iter, Reduce, AddUnique, Join, Remove, Assocs, JoinCSV, Replace, Back, Map, Reverse, Base, Map!, Reverse!, Base?, Max, Set_default, Copy, MaxWith, Set_readonly, Delete, Member?, Shuffle!, Difference, Members, Size, Empty?, MembersIf, Slice, Erase, Merge, Sort, Eval, MergeNew, Sort!, Filter, MergeUnion, Subset?, Find, Method?, Swap, FindIf, MethodClass, UniqueValues, Flatten, Min, Values, Front, MinWith, Zip, GetDefault, Partition, Has?, Partition!

It wouldn't be a minor restriction...

Post edited by: Mauro, at: 2006/12/04 18:21
 
 
Mauro
 
#465
Re:Is it possible to redefine builtin Object methods? 3 Years, 8 Months ago
Hello,

You are correct. You can not override built-in object methods in your class. Overriding these built-in methods could (and most likely would) cause problems where basic object functionality is assumed.

Some of the methods you listed are not built-in. They are defined in the Objects class which is used to extend the functionality of objects. The object methods that are defined in the Objects class can be overridden.
 
 
Jeff Ferguson
Suneido Software
 
#467
Re:Is it possible to redefine builtin Object metho 3 Years, 8 Months ago
Hi, thank you for the reply. I had not noticed that there is an Objects class in the stdlib. Therefore, the methods that cannot be redefined are:

Readonly?, Add, Iter, Join, Assocs, Reverse, Base, Reverse!, Base?, Set_default, Copy, Set_readonly, Delete, Member?, Members, Size, Erase, Sort, Eval, Sort!, Find, Method?, MethodClass, Values, Partition, Partition!

I think that this info should be on the User's manual, in the Language -> Classes -> Overview section.

P.S.: To me this is not a good design solution for a pure object-oriented language. I think that in a class I should be able to define all the methods I want. Some method names as Add, Copy, Delete, Size, Sort and Find are very common terms to use in a class, but in Suneido I cannot use them. :( For example: in Java, all objects derive from the Object base class. The Object class provides several default methods (clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait) but these methods can also be overriden.

Post edited by: Mauro, at: 2006/12/06 12:15
 
 
Mauro
 
#468
Re:Is it possible to redefine builtin Object metho 3 Years, 8 Months ago
Hello,

I agree with you. The manual should mention something about the methods that can or can not be overridden. At first I thought maybe we could just mention in the Objects documentation that the built-in methods can not be overridden. While this is true in most cases, I am aware of at least one method (Copy) that can be overridden. There may be others. If we specify the list of methods that can't be overridden then we have to always be maintaining the list in the documentation.

I'll have a look at adding something to the documentation. Suggestions are welcome.
 
 
Jeff Ferguson
Suneido Software
 
#480
Re:Is it possible to redefine builtin Object metho 3 Years, 8 Months ago
Then we have some built-in methods that cannot be overridden and some others that can be overridden... I think these informations should be definitely in the User's Manual. Near the 'builtin' info of some methods in the manual I think there should be an 'overridable' info too and a generic info on the fact that almost all builtin methods are not overridable.
 
 
Mauro
 
#481
Re:Is it possible to redefine builtin Object metho 3 Years, 8 Months ago
The main reason for not allowing overriding built-in methods is to help make code easier to read and understand, because you do not have to think about whether these basic methods have been redefined. Of course, this assumes you know which are the built-in methods ...

Another problem with redefinition is that you may not be aware of everything that is using a method. For example, you might re-define Size, but this may break Find because it uses Size.

Another minor reason, is that it is faster to execute the frequently used built-in methods because all the base classes do not have to be searched. (This could also be handled by caching method lookups.)

I agree that it is annoying when you can not use an obvious name like Size, but there are usually alternatives. It can also cause bugs if you use a built-in name and do not realize it is not working. (Of course, if you write tests for your code then you will catch this.)

Another issue is that it is not possible to make your own class that behaves exactly like a "normal" object, but that is implemented differently. e.g. a class that stores it's data in the database instead of in members.

re. Copy - it is possible to define Copy as a class method (because classes do not have a Copy method) but not for instances. For example:

Code:

c = class { Copy() { return 123 } }

c.Copy()
    => 123

x = new c
x.Copy()
    => c()



However, I would not recommend this.
 
 
andrew
 
#484
Re:Is it possible to redefine builtin Object metho 3 Years, 8 Months ago
Hi Andrew, I know that redefining builtin methods it's not a good thing because it can break many things in Suneido, but there are some method names that are very common terms, as Size, Add, Find, Sort, Copy, Delete, Erase.
The problem arises because you have only one data type for generic objects and class instances. I think a better solution would have been to separate the object data type as instance from the object data type as generic data container.
Another solution (to avoid the Object data type split-up), would have been gathering all builtin methods in a well known member. For example:

ob = Object()
ob.Builtin.Size() <-- all builtin methods would be called from the Builtin member
ob.Size() <-- this would be my method that doesn't break anything ;)

In this way I could redefine all the methods I want, because I don't have to handle the Builtin member (this would be the only 'not overridable' member).

What do you think of this solution?

Post edited by: Mauro, at: 2006/12/12 11:51
 
 
Mauro
 
#486
Re:Is it possible to redefine builtin Object metho 3 Years, 8 Months ago
I agree that it might be better to make general purpose "objects" more separate/independent from class instances. However, even with class instances I think it is good if there are basic methods that you can depend on (that can not be overridden).

But I am not convinced that it would be a good idea to make the built-in methods "harder" to access (via more complicated names) just to make it "easier" to override them. My assumption is that using built-in methods is very common and should therefore be as simple/easy as possible. Whereas overriding built-in methods would be less common/unusual and therefore does not need to be as simple/easy.

In general, constraints can seem limiting, but can end up beneficial. There are always trade-offs.
 
 
andrew
 
#488
Re:Is it possible to redefine builtin Object metho 3 Years, 8 Months ago
andrew wrote:
[...]But I am not convinced that it would be a good idea to make the built-in methods "harder" to access (via more complicated names) just to make it "easier" to override them. My assumption is that using built-in methods is very common and should therefore be as simple/easy as possible. Whereas overriding built-in methods would be less common/unusual and therefore does not need to be as simple/easy.I agree on this, but my point is that I don't want to override builtin methods... Simply, in an Object Oriented Language I would like to use every name I want for my class methods, especially very common names, as Size, Add, Delete, etc.

Maybe the best solution would be the Object/Instance split-up...


In general, constraints can seem limiting, but can end up beneficial. There are always trade-offs.
I agree on this too, but in a language that would want to be a Pure Object Oriented Language, some constraints appear to me a little too limiting.
Besides, I have the feeling that Suneido has been designed with flexibility in mind... Just see all the syntax alternatives that Suneido allows:

a = b + c
a = b + c;
ob = #("Vert", #("Field", text: "hello", name: "myfield"))
ob = #(Vert (Field text: hello name: myfield))
if (a < b) { ... }
if a < b { ... }
myObject[member]
myObject.member
myclass = class : BaseClass { ... }
myclass = BaseClass { ... }
...
...
and so on...

That is why, to me, the builtin method names limit appears a little strange in the Suneido language.

Of course, Suneido remains a very good development software for data-oriented applications with a very interesting language. But I think it would be nice if the language were a little more generic. ;)
 
 
Mauro