callable virtual method

[Jean-Michel Pichavant]

Dave Angel wrote:
> Jean-Michel Pichavant wrote:
>> <div class="moz-text-flowed" style="font-family: -moz-fixed">Nigel 
>> Rantor wrote:
>>> Jean-Michel Pichavant wrote:
>>>>
>>>> Your solution will work, for sure. The problem is that it will dumb 
>>>> down the Base class interface, multiplying the number of methods by 
>>>> 2. This would not be an issue in many cases, in mine there's 
>>>> already too much meaningful methods in my class for me to add 
>>>> artificial ones.
>>>>
>>>> Thanks for the tip anyway.
>>>
>>> I suggest you reconsider.
>>>
>>> You asked a question and have been given a standard way of achieving 
>>> the desired outcome.
>>>
>>> It's common in OO to use a Template pattern like this.
>>>
>>> If you're not interested in finding out how loads of people have 
>>> already solved the problem then why ask?
>>>
>>> The methods that require overriding can be prefixed with an 
>>> underscore so that people get a hint that they are an implementation 
>>> detail rather than part of the public interface.
>>>
>>> I don't see your problem, other than a vague aesthetic unease.
>>>
>>> Regards,
>>>
>>>   n
>> I understand how refuting some obvious solution may look just stupid. 
>> You're right, I shouldn't have asked.
>>
>> By the way I'd like to know if I am I alone to find that
>>
>> class Stream:
>>    def start
>>    def stop
>>    def reset
>>
>> is better than
>>
>> class Stream:
>>    def start
>>    def _start
>>    def stop
>>    def _stop
>>    def reset
>>    def _reset
>>
>> (try to figure out with 20+ methods)
>> What you call aesthetic may sometimes fall into readability.
>>
>>
>> JM
>>
>>
>> </div>
>>
> Usually when one defines an abstract base class, one expects many 
> people will derive from it, as opposed to only one having to write 
> it.  So if the base must be "ugly" according to some definition, so be 
> it.  Aesthetics are quite subjective.
>
> Nigel's approach has another benefit not stated, which is to keep the 
> child class code simpler.  They avoid the need to call any base class 
> method to access the common logic.  The downside is it assumes that 
> the common logic will always be either at the beginning or always at 
> the end of the child classes implementation.  That's because the base 
> class has hardcoded where in its implementation to call the child 
> class method.
>
I think this is a severe issue.
You prevent the sub class from writing
def foo(self):
    pre()
    Base.foo(self)
    post()
> Anyway, without arguing for or against either approach, I'd point out 
> that you could have an extra formal parameter in the base method, 
> which is a private signal from the child class that this is the 
> internal call.  Missing such a formal parameter would then trigger the 
> "missing method in derived class" error message.  You'd check such a 
> parameter the same place as you're now checking the object's type.
>
> DaveA
>
>


talking about approaches:

1/
class Interface:
    def foo(self):
       if self.__class__.foo == Interface.foo:
          raise NotImplementedError

2/
class Interface:
    def foo(self):
       self._foo()

    def _foo(sef):
       raise NotImplementedError

Are they so different ? They both require about the same amount of extra 
characters, they're both readable. The second is a very classic OO 
layout, the first is more flexible for the sub classes and spare some 
method definition.

This thread may live again, I cannot say but I'd like to thanks all who 
gave me their valuable idea on the subject, I mean it. Please don't take 
my skepticism as a lack of consideration.

JM