There is a way to make a protected method callable from a derived class but overridable by making it FINAL.
Is there a way to do the opposite?
I.e. make a method overridable, but not callable by a derived class.
An example could be a protected abstract method that only the base class should call in a specific order or scenario.
The derived class is allowed or obliged to provide an implementation, but should never directly call the method.
It seems something like this is possible in c++ using "private virtual".
I was wondering if any construct in ABL could mimic this...
See https://stackoverflow.com/questions/414746/override-but-dont-call and https://stackoverflow.com/questions/29412477/java-method-only-callable-by-superclass
Sure, I gave the original problem another thought and in this case think I found a cleaner solution.
Nevertheless, I thought it was worth starting a discussion...
One other solution we thought off (but became redundant because of the refactoring) was to move the implementation of the method to another class (strategy pattern), and have that injected into the base class (composition!).
What a fun OO is! I use *private* methods by default, no inheritance so no subtype polymorphism & protected whatever. No ridiculous 'abstract' nonsense. Public methods when needed. I'm overall not a fan of unit tests when units mean methods (for a start on some not too stupid criticism read rbcs-us.com/.../Why-Most-Unit-Testing-is-Waste.pdf), but I suppose you're already addicted to those green images beside each method and want to tell your manager about those high coverage percentages while your architecture is-a disaster anyway. Never *** up your architecture for testing purposes!
I want to be able to ruthlessly refactor your overcomplicated code and moreover not be hindered by your unit tests. Testing behaviours is not that bad.
There are c+ devs (and here I mean one of the most intelligent devs of c++ itself) that can and do without oo .. www.stlport.org/.../StepanovUSA.html (danger, don't click on that link).
But I'm sure you love complexity (it makes one feel intelligent, eh ;-).
oh Jeez Marian, there are _so_ many things wrong about your reply ;) Maybe it's transference ? :)
@Stefan - I *love* complexity .. it means that there is still so much to learn, because I'm obviously still not perfect ..
If it is not obliged, a custom event should work for this case.
@jmls There is a lot to unlearn sometimes, and decomplect. Simplicity is hard enough.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague."
"Simplicity is prerequisite for reliability."
I don't want this thread to end up in another pro/con OO principles farce...
While I also try to favor composition over inheritance, even Bjarne Stroustrup mentions in the talk agent_008_nl recently referred to that inheritance still is an important tool in any OO developers toolbox either way...
Anyway, I'm rethinking the design of this particular piece of code.
It was based of an existing implementation, but might need some more refactoring to prevent the need for this *feature*...
Maybe you just don't need what you propose in your first mail. Maybe OO is possible without inheritance and subtype polymorphism. According to Stroustrup it is. And maybe you can program much more agile / simpler solutions without. I think it is that way (too much work to explain for now, watch f.e. the movie I postend earlier www.youtube.com/watch , this is from a spotify programmer and very well thought through).
I'm stuck myself with OO for the time being and want to make the best of it. That means a lot of disentangling / refactoring (for which I currently have a long during mandate). Without all complecting stuff life becomes easier.
Ask Progress for implementation of delegates. :)
You received this notification because you subscribed to the forum. To unsubscribe from only this thread,
post as spam/abuse.
Architect of the SmartComponent Library and WinKit
For those of us who are not OO experts, what would a delegate provide from an ABL perspective?
Jeff Ledbetter Product Architect | Roundtable Software
It's a construct that allows a class to literally delegate a work outside the class implementation without passing an object. This avoids dependency. It's functionally similar to callback construct.
METHOD CHAR MyInfo() . . .
classB.AskAnotherClassInfo(NEW DELEGATE(MyInfo)) // somewhere in class A
METHOD AskAnotherClassInfo(SomeMethod proxy)
var = proxy(). // will run class A's MyInfo
Here, class B has no reference dependency on class A.