Return to Question

Simple object-oriented calculator

Simple object-oriented calculator - follow-up

Simple object-oriented calculator - part 3

Simple object-oriented calculator

Simple object-oriented calculator - follow-up

Simple object-oriented calculator - part 3

To those looking this question first I'm trying to find a correct OOP model I can use in JS. I initially found a very different solution from what's normally done and I received lots of help from some of the good guys here :) The links above tell the whole story.

• I was glad you edited and changed override method to use bind. I wasn't confortable with that _SuperiorChainer thing. I found it too complicated and very strange to use. With bind it got much better.
• Instead of creating 2 method one for normal classes and one for view classes (dev_prop and def_view_prop) I overriden it and reduced it's name. I think it got clear enough and pratical enough.
• I loved the idea of using def_view_proc instead of parsing the class. Much better.
• I loved this way of defining a property using descriptors with a smaller syntax. It remembered me the old Dephi times. I found Delphi properties definition very useful. I pushed descriptor.enumerable to the function tough, and created a defHidden method just in case.
• I've put function is_function(obj) { return obj instanceof Function }; inside of override function. It's only used there and as you recommended me we should avoid global context functions. If it's needed anywhere else I'll remove it from there and create an utility class or something.
• changed the name from inherit_from_to to extend. Small and equaly explicit.
• I loved the much cleaner code removing showOperators method and stuff. I'll definitively will use method descriptions more.

So what do you think  ? final ?

To those looking at this question for the first time, I'm trying to find a correct OOP model I can use in JS. I initially found a very different solution from what's normally done, and I received lots of help from some of the good guys here :) The links above tell the whole story.

• I was glad you edited and changed the override method to use bind. I wasn't confortable with that _SuperiorChainer thing. I found it too complicated and very strange to use. With bind, it got much better.
• Instead of creating two methods: one for normal classes, and one for view classes (dev_prop and def_view_prop), I overrode it and reduced it's name. I think it got clear and pratical enough.
• I loved the idea of using def_view_proc instead of parsing the class. Much better.
• I loved the way of defining a property using descriptors with smaller syntax. It reminded me the old Dephi times. I found Delphi properties definition very useful. I pushed descriptor.enumerable to the function tough, and created a defHidden method just in case.
• I've put function is_function(obj) { return obj instanceof Function }; inside of the overwritten function. It's only used there and as you recommended to me, we should avoid global context functions. If it's needed anywhere else I'll remove it from there and create an utility class or something.
• I changed the name from inherit_from_to to extend. Small and equally explicit.
• I loved the much cleaner code, removing showOperators method and stuff. I'll definitely will use method descriptions more.

So what do you think? Any final comments?

• I was glad you edited and changed override method to use bind. I wasn't confortable with that _SuperiorChainer thing. I found it too complicated and very strange to use. With bind it got much better.
• Instead of creating 2 method one for normal classes and one for view classes (dev_prop and def_view_prop) I overriden it and reduced it's name. I think it got clear enough and pratical enough.
• I loved the idea of using def_proc instead of parsing the class. Much better.
• I loved this way of defining a property using descriptors with a smaller syntax. It remembered me the old Dephi times. I found Delphi properties definition very useful. I pushed descriptor.enumerable to the function tough, and created a defHidden method just in case.
• I've put function is_function(obj) { return obj instanceof Function }; inside of override function. It's only used there and as you recommended me we should avoid global context functions. If it's needed anywhere else I'll remove it from there and create an utility class or something.
• changed the name from inherit_from_to to extend. Small and equaly explicit.
• I loved the much cleaner code removing showOperators method and stuff. I'll definitively will use method descriptions more.

JSFiddle

• I was glad you edited and changed override method to use bind. I wasn't confortable with that _SuperiorChainer thing. I found it too complicated and very strange to use. With bind it got much better.
• Instead of creating 2 method one for normal classes and one for view classes (dev_prop and def_view_prop) I overriden it and reduced it's name. I think it got clear enough and pratical enough.
• I loved the idea of using def_view_proc instead of parsing the class. Much better.
• I loved this way of defining a property using descriptors with a smaller syntax. It remembered me the old Dephi times. I found Delphi properties definition very useful. I pushed descriptor.enumerable to the function tough, and created a defHidden method just in case.
• I've put function is_function(obj) { return obj instanceof Function }; inside of override function. It's only used there and as you recommended me we should avoid global context functions. If it's needed anywhere else I'll remove it from there and create an utility class or something.
• changed the name from inherit_from_to to extend. Small and equaly explicit.
• I loved the much cleaner code removing showOperators method and stuff. I'll definitively will use method descriptions more.